How to NOT debug your programs

When working on software, bugs are something that any developer will inevitably come across. As a result, it is critical that the methods of finding and fixing bugs should be well understood and implemented. However, there are a few wrong ways of going about it, which either defeats the purpose of debugging or makes it take more time than it should have required in the first place. Here are a few ways of how to NOT debug code:

Not paying attention to the logs

Any software that is being used in production should have a system of recording and reporting logs of the events going on within it. Even though all the information might be daunting to look at, that’s usually the first thing to examine when something is acting up within your deployment.

Changing multiple things at once

Oftentimes, it is necessary to be able to fix a bug as quickly as possible. A common mistake in those scenarios is that the developer will change multiple things at once to test whether the said set of changes “fixes” the bug. However, this is counterproductive. It is crucial that you come up with a plan of potential changes to make, only make changes to one thing at a time, examine the behaviour of the system with that change and repeat the process.

Not keeping an audit trail

Related to the above notion of changing things, it is also necessary to keep a log of the changes made, the expected state of the system and the actual state the system ended up in. In addition, it is also important to have a written record of the problem and the solution that was eventually implemented so that any new developer can be aware of the bug and not end up introducing a new (related) bug to the system themselves.

Not using the proper tools for debugging

An actual debugger might require some setup steps, but it helps you visualise execution flow and the variables in real time. Setting up an automated test suite to reproduce the bugs that are intermittent or happening once in a while can also help speed up the process of debugging. Another thing we tend to forget is our version control system, we can effectively go back in time and examine exactly what introduced the bug.

Not taking a break

This is something probably every developer has been guilty of at some point. It is tiring to stare at logs, code and stack traces for extended periods of time. Taking a small break and coming back with a refreshed mind helps out more than we often give it credit for. Efficient debugging requires a systematic and analytical approach, which when followed will end up saving time in the long run. At Sazim we are encouraged to get help from colleagues, having a second opinion always helps.

Not seeking help

In my current company we have a “1 hour time-box” rule, where we time-box a task that might take a while to 1 hour max. If we cannot get it done or we haven’t made any progress whatsoever within that time-frame, we are encouraged to reach out to our colleagues. A lot of the times, the colleague may reach out to doesn’t even have to provide an input on the matter. Just explaining the problem out loud often does the job and you immediately realize the approach you should’ve taken. If you’re unable to reach out to someone, a rubber duck (or something similar) can help you out quite nicely, although I am not suggesting that inanimate objects can replace human interactions.

Efficient debugging requires a systematic and analytical approach, which when followed will end up saving time in the long run. Hopefully these tips is of use to the readers in reducing the amount of time they require to debug their next bug.