Image by Tommaso Nervegna
Technical

Becoming an Unusually Effective Debugger

Recently, I was perusing the tech blagosphere when I came across a post called Unusually Effective Debugging, by Carlos Bueno. In this writeup, Carlos teaches us his philosophy for debugging code. It’s a great read, and concise, so you should definitely read it for yourself. But for our purposes, I’ll give a quick summary. Basically, Carlos argues that debugging is not about iteratively devising and testing potential causes of the problem. While this process works for the simplest pieces of code, for even a moderately complex system it quickly becomes unrealistic. There are just too many things that could be wrong. Instead, Carlos recommends that we visualize all the possible causes of the problem and then work to define tests that eliminate whole sections at once. In his words:

It’s about imagining a huge multidimensional search space of possibilities and looking for ways to eliminate half or whole dimensions, recursively, until you’ve isolated the fault.

I thought this made a lot of sense, so I sent the article out to our software team here at Mindtribe. But the software team had something to say. Specifically, Jerry chimed in with this wisdom:

While I agree with the advice, it isn’t going to be actionable for most people. Want some specific advice that will rapidly improve your debugging abilities? When you see a problem – 1. Don’t start “debugging” by messing with your code until it works. 2. Don’t start by googling. 3. Don’t start by launching the debugger. Don’t do anything but think. Form at least three hypotheses that explain the symptom you’re seeing: two plausible and one off-the-wall. Then, do the simplest, smallest thing possible that could prove or disprove your hypothesis (whether it’s a print statement, setting a single breakpoint, rereading the datasheet, etc.) and repeat until you genuinely run out of ideas. Then, ask a coworker. When you’ve both run out of ideas, then you can resort to brute force tactics. Why do all this? Because the point isn’t to fix the bug. It’s to ensure you’re gaining experience and building up a solid mental model of your codebase. When you brute force a solution, you’re doing neither and you’re not becoming a better developer.

It’s important to note that Jerry isn’t disagreeing with Carlos. Rather, Jerry wants to give developers trying to implement advice like Carlos’s a more tangible starting point. In Jerry’s words:

I’ve found that telling a junior engineer to ‘structure experiments such that they eliminate large swaths of the potential problem space’ isn’t as immediately actionable as ‘don’t you dare touch that debugger until you’ve thought about the problem.’

So there you have it – an actionable path to rapidly becoming an unusually effective debugger. Go forth, and code.