Ultimate debugging techniques

25.01.20192 Min Read — In Tips

Ever had a code issue with some kind of unexplainable, mysterious or mystic behavior? The one that keeps you at your desk for hours and gives you headaches? I sure have!

Throughout my (humble 😀) experience, I've seen or seen used several debugging methods (not sorted by order or effectiveness):

  • Trying to understand where the issue lies using logging/breakpoints and executing your code many times
  • Searching for a solution on StackOverflow, GitHub, Spectrum and other websites
  • Explaining your issue to a coworker
  • Explaining your issue to someone non-technical (family, friend, dog...)
  • Explaining your issue to an inanimate object, also known as rubber duck debugging

Each of these techniques has its own merits, but I'd like to share some secret debugging techniques that I've mastered over the years.

Sleep debugging

It is 1AM. What should have been an easy instant feature is taking more than 2 hours. Why won't this code fucking work?

I personally found that, once I find myself in this situation, the best solution is to simply go to bed. Staring at your code for too long makes you oblivious to the obvious, and the exhaustion accumulated from your workday doesn't help either. What looks like giving up to someone new to the art of sleep debugging is actually one of the most skillful debugging method in action. Sleep refreshes your mind and forces you to take a step back. Often, I even realize that the code I was trying to make work was unneeded or solving the wrong problem.

Lazy debugging

Sleep is my preferred solution, but if it’s only 10AM or your workplace is sleep shaming people for taking naps, taking a break can also be beneficial. The definition of break is important here: staying at your desk browsing Twitter is not a break. Taking a walk outside is. If you work from home (or if your company allows it), I recommend taking your dog for a walk.

Half comment debugging

This technique is very simple. First, you have to be in the mindset of knowing nothing about your code and avoid any bias such as "This one line must be the culprit!" or "I won't even take a look at this code, it's totally unrelated to my issue!". Let’s say you have a function that produces a runtime exception, but you cannot tell which part of the function is problematic.

  • Step one: comment out half of the function code.
  • Step two: is the problem still there? If yes, then the issue lies in the half you haven't commented. If not, then it is in the code you commented.
  • Repeat from step one with the problematic half.

(For a more thrilling experience, make sure the buggy code is not versioned yet and replace commenting by deleting)

This technique sounds silly, but it has actually helped me many times. More than the algorithmic aspect of it, I think the take-away here is that sometimes, the least suspicious code is the culprit. Applying this technique helps make actually makes you unbiased towards your code. This principle is also known as dichotomy. It's used in the git bisect command, a useful command for unbiased debugging.

You may have used these techniques subconsciously, but I found that being aware of them and naming them helps. Hope this small blog post convinced you to go to sleep or delete half of your code!