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."
• An ounce of patience is worth a pound of brains