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:
- You have been debugging for a while but still not sure where and how the fix should be.
- 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 .
🐞 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 learnings 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, Debugging: The 9 Indispensable Rules for Finding Even the Most Elusive Software and Hardware Problems. 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 Freepik from www.flaticon.com
Hope you enjoyed reading this article, See you next time.
Top comments (0)