Fixing bugs is a huge part of a developer’s job, but not many think or read about the actual process of solving a bug. We sort of go at it intuitively, trusting our own self-developed process. Some of us tend to think of bug solving as the 2nd class citizen in programming. Not our real job, which is writing code, crafting new features and discovering new technologies. It’s just something we do in between real programming, right?

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).

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.