How Am I Dealing With My Ever-Improving Debugging Techniques

How much time do you spend in debugging? Well, I know that the question is bit vague and the answer would vary. After spending close to 15 years in Computer Programming, I still can't say confidently how much time I really spend in debugging things. There could be multiple factors that influence it and make it uncertain to answer:

• Do you follow Test Driven Development(TDD) and your test cases get updated as you write new features?
• Have you got good code coverage?
• What's the Complexity of the issue in hand?
• Do you have adequate tooling system to help with?
• What are your test strategies?
• ... and few more that may be specific to your team and environment.

While there are many other factors to consider to time-box your debugging for finding fix, there is one very important consideration to make. Debugging is a Skill and it can be improved.

First, Accepting the Fact

Yes, right. We, the developers are the primary bug creators and it is perfectly fine to be like that. With that, we are also responsible to 'debug' the code to make it bugs free(as much as possible!).In rest of the article, I will be explaining what I have been doing to improve my Debugging Techniques. You might see something in common.

🐞 Seeing the Big Picture

Fix for a bug in one component may have the potential to break something else in other components. Hence having a clear idea on the big picture helps great way. Understanding of how the different components talk to each other, dependencies, data exchange etc are key factors to understand before attempting a bug fix. A good debugging technique is to take these into account and proceed.

🐞 Debugging other's code

When we talk about improving the debugging skill, it would be a much better polish if we debug a code not written by us. Believe me, it is a pain but at the same time, teaches many lessons.

🐞 Discussing and Looking from other Angles

Let's take these two cases:

1. You have been debugging for a while but still not sure where and how the fix should be.
2. You have just found a fix after debugging a code written by a peer.

I have experienced that, discussing the approach with a peer helps accelerating lots better. Often we get a different ways to look into things. Your peer would have solved similar issues already.

🐞 Making use of right tools, right ways

Even when you have got the right techniques and skill to debug issues, the lack of right tool to assist may slow down your progress. To give an example, instead of putting console log at the suspicious point, it is better to use a visual debugger tool, if available. Point to note, availability of a a great tool is also not enough if the right Tricks and ways are not clearly known to use it. An example [could be this one](//blog.greenroots.info/devtools-my-favorite-tips-and-tricks-cjw4ddagw000uqns1loyfr2x1) .

🐞 Go in, Come back but Don't Give Up!

Many a time debugging is deep. It needs time, energy, patience and attitude. There will be time where one will feel helpless, like reaching end of the tunnel. This is the time to come back, see things from the beginning. Don't give up. Compare steps between different approaches, try finding the gaps.

🐞 Logging well and Taking Notes

It is a good practice to enable appropriate logs while debugging. Additional logs from various components and modules helps tracking things. At the same time, you got to make sure, appropriate logs are there in the code. If not, please add and improve. Take a good note of your debugging steps. This will help you in triaging issues in similar areas in future.

🐞 Take a Break!

Tired of debugging and not reaching anywhere? Take a good Cofee Break. Breaks increase productivity and creativity. They say, “Aha moments” came more often to those who took breaks!

Conclusion

To conclude, these are my learning and experiences to improve the debugging skill. I am certain, there will be many more different and effective ways. Feel free to comment what you have found effective for you and your team. I would like to finish this article by mentioning a great read by David J. Agans called, . Read at leisure. Here is a great poster from the website of the author:

Credit

The cover image of this post uses a Icons made by from Hope you enjoyed reading this article, See you next time. Please follow me @