It's a book about debugging, about troubleshooting. It has some good advice and some fun anecdotes. As I write this, it's been a few weeks since I read it, and the anecdotes have all leaked out of my head. Still, some parts stayed with me. As a technical writer, my heart was appropriately warmed to see the advice, "When all else fails, read the instructions." But the advice is sound.
When you design something, remember that you'll need to debug it. If you can modularize it, that will help you to predictably repro, isolate, and diagnose problems.
Design in a way to "export" information you'll want when debugging.
Trust measurement and observation further than guesses.
If you write a bug report that just says "it's broken," you're not helping. (If you chase a problem only to figure out that it's in a part of the system you don't understand, not all is lost: a skilled debugger can write a good bug report.)
When you ask for help, "Report symptoms, not theories. The reason you went to someone else for fresh insight is that your theories aren't getting you anywhere."