It turned out to be an extremely good whim. Despite some minor issues, this book is an extremely readable introduction to how to approach debugging, with a fair bit of specific advice. It’s structured as a series of chapters about a fictional team. Each chapter is bracketed by discussion of a specific real-world bug that caused a lot of very visible trouble. Inside each chapter, the fictional team struggles to figure out a problem that turns out to be caused by similar forces. The discussion focuses on their thought patterns and realizations. The writing is nicely specific without having to include a lot of source code. Symptoms and behaviors are the main focus.

Although the title specifies embedded debugging, most of the techniques in this book can (and should!) be applied to any sort of debugging. The value in this book isn’t in the specific situations it describes, but in the approach to diagnosis and problem-solving it teaches. That said, all of the situations in this book use relatively small software systems. A book on debugging larger systems would be a good next read. The closest match I can think of is Working Effectively With Legacy Code, but that has a development focus, not a debugging focus. (I recommend it in its own right, but it’s not an obvious follow-up for this book.)

Although Why is the Phone on Fire? is generally a good resource, there were some problems with its writing. The members of the fictional team behave in racially stereotyped ways. The writing style was occasionally pedantic — I could sometimes interpret this as the old hands on the team being patronizing to the newbie, but that’s problematic too. I think these problems are overshadowed by the positive qualities of the book, but potential readers should be aware of them going in.

Overall, it’s a very good book in an underserved market niche. I’m going to buy a copy for lending purposes.