This book was valuable but pretty basic. Someone without a lot of debugging experience could learn a lot of useful tips and ways of thinking about debugging. One key lesson is that the purpose of debugging is to find the cause of an issue, not to fix the bug. If you fix a bug without understanding what caused it, then you've failed at debugging. For the more experienced debugger, there will only be one or two useful things. That said, it's a quick enough read to be worth reading for those one or two things.

I really like the idea of applying a root cause analysis to every bug. This goes beyond figuring out why the code caused the particular issue and into analyzing why the code got that way in the first place. Is there a systematic problem with the code? Is the code health in the relevant module so bad that bugs are easy to let in? Was the code developed under rushed conditions? Debugging is an opportunity not just to improve code, but to improve your overall development process.

There was also a good section on digging yourself out of a quality hole in a system with too many issues. The two high level techniques are keep things from getting worse and tackle the problematic areas of the code, but putting this sort of quality focus in the context of debugging really helps to broaden the picture.

The final chapter on anti-patterns, made me cringe with recognition several times. In particular, priority inflation (only high priority bugs are addressed, so all bugs are given high priority), firefighting (the team is so busy doing that they never step back and analyze how to make things better), and no code ownership (no one feels responsibility for a particular module, and so bugs in it don't get fixed). These anti-patterns all have solutions, but there is no silver bullet. Much of it comes back to discipline and prioritization.

All-in-all, this book is worth the few hours it takes to read. ( )