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:
Did you ever feel like Visual Studio is rebuilding projects every single time, even when there were no changes to the code?
We can build, change nothing, build again and there we go… VS is starting a build instead of saying all my projects are up to date.
Also, there’s that nagging feeling that even when we do change something, VS is building way more projects that it needs.
Like most things I do in life, frustration led me to look further into this matter.
Recently I was dealing with a couple of bugs in C# regarding timeout behavior. The solutions were pretty interesting so I decided to share them.
A long time ago, on my first programming job I had a design problem that I couldn’t solve.
This problem haunted me. The reason was that it seemed so simple, and yet I couldn’t find a good solution for it.
Eventually I did a huge refactor, but instead of solving it correctly I simply changed one problem to another.
Recently, years later, in a different company, I came up with that great solution I was after.
So besides telling you I’m thinking about code from years ago way too much, I want to share with you my exciting great solution. Continue reading