Debugging like a detective
Debugging, the true joker to our batman. Just like superheroes, programmers have their super-villains and they can be pretty lethal, even though we always triumph. From creating our own problems by writing scripts with errors in its syntax (Iron Man and Ultron) to messing with things we do not understand, and suddenly getting a load of explosions in our code environment. We are tasked daily with fixing errors and making modifications to code which may lead to more errors. But the story shouldn’t be much different if you fixing a logical, compilation or run-time error.
Identify your environment
The environment where a battle is fought can make all the difference for the hero. If you are working in an environment you do not understand or have little understanding about it is a good idea to understand the inner workings of that environment before attempting to fix your code otherwise you might end up breaking it. “You don’t need to know how to make it to break it, but you need to know how to make it, to change it”.
Your detective room would be the coding environment you are working and this is where all your hunches will be tested in real-time.
Understand the story
Whatever bugs you get in your application is nothing more than a deviation from the original stated behaviour of your application. Your crime scene is nothing more than the application you are working on. Tracing all the required behaviour of the application step by step can make a whole load of difference to finding exactly where your bug is hiding. Start from the entry into the application and work your way into the corners of the application, identifying every suspicious of point of errors.
Probe your Suspects
A huge part of your investigation would involve finding out when and where the application started behaving abnormally, just before the culprit committed the crime. At this point, you need to ensure your suspects are telling the truth i.e. giving you the right values. You can probe them by console logging the values or displaying the values on screen or command line depending on what works best for you. You need to be sure that the behaviour of your variables and functions are as defined either in the specifications or documentation. Any deviations should be recorded and probed because they could be your culprit.
Draw a Map
Have a board or table which helps identify all your suspects (possible bugs) and helps to tell where you are at in your investigation. Always revisiting your crime scene can reveal a different story each time and although your hunches might be wrong in the beginning but with constant revisits to the crime scene you will get closer to identifying the culprit and mapping the results of the investigation will prevent you from running around in circles.
Get an assistant
Sometimes bugs can be well hidden, they could be hiding in plain sight and because you have searching for way too long, you just might find it difficult to pinpoint where exactly the bug is hiding.
Hence comes, robin the sidekick to the number investigator. Bringing in someone else into the investigation doesn’t make you less capable of solving the problem it just means you value time and the input of others. If the bug is taking way too long to detect, then getting a fresh pair of eyes can help by providing new perspective to how the problem is being approached.
“When you look long into an abyss, the abyss looks into you.”
The debugging process is not much different from how detectives solve crime and the procedures they take. That’s why you must be systematic, logical and organized when debugging. Remember the joy of the hunt always comes at the end.
