I think I spend more time debugging code than writing code, designing software architecture, trying to reproduce bugs and even going to meetings! Debugging is the biggest time consumer we have as developers.
As time goes by, I keep learning new tricks that make my debugging more effective. I’ve gathered in this post 7 debugging techniques that I learned relatively late into my career and I consider advanced (though sometimes something advanced for some is trivial for others). Enjoy and I hope you learn something new!
In my previous company, we experienced a reoccurring nightmare. It went something like this:
New critical bug arrived from QA:
Program suddenly crashed. Reproduces 1 / 10 times. Reproduce steps – unclear.
The development team, after realizing they are unable to reproduce the bug on their development machine would claim the bug doesn’t reproduce, moving the ticket back to QA.
In return, the QA team reproduced the bug, moving the ticket back to dev.
Then, the development team would claim another layer of the code caused the bug, moving the ticket to a second development team maintaining that code.
The second development team, with spite, would find an obscure line of code in the log file proving the bug is actually not in their layer of code, moving the ticket to the original dev team.
This would go on until either the development team succeeded in moving the bug to backlog or, in rare cases and by sheer luck, the development team was able to solve the bug.
In our defense, all the coders who originally built the system were long gone, the application was huge and complicated.
I guess not much of an excuse but eventually we learned some tricks to help us solve those pesky crash bugs.
Well, some developers learned. Others kept claiming the bug doesn’t reproduce 🙂
Introducing our bag of tricks: