If you’re like every other developer out there, you spend a fair amount of your time debugging code rather than writing code. However, it’s amazing that despite so much of our time being spent in debugging, a lot of us never really do it in a systematic way. Each of us debug stuff on our own way as bugs present themselves – and a lot of the time, we end up wasting too much time on what could otherwise be a quick fix.
Following is a list of techniques that John Sonmenz recommends in his book The Complete Software Developer’s Career Guide which I’ve found to be useful in debugging time and again. And I believe everyone should follow this process. Pro tip: Don’t open your debugger right away.
- Reproduce the bug first – there is no “bug fixing” without the bug.
- Think about what might be causing this – don’t just start with the code yet. Form a hypothesis. Make assumptions.
- Write unit tests to verify your assumption. This not only helps you test your assumption – but also allows you to catch if this bug would occur again in future.
- If unit tests are not helping, re-visit your assumption. It is often possible that our first assumption is not where the issue is. Think again.
- If you are out of assumptions, then finally open your debugger. If you know where to look, debugger will be helpful at this stage. But otherwise – be aware of losing track of time in debugger – you may end up spending hours without moving ahead.
- If nothing helps, then “divide-and-conquer”. Divide the problem domain by half until you’ve reached the source of the bug. This always helps.
You can read more about these steps in John’s blog post too.