Halfway though reading a book on debugging, I realized that I had read it before. It was a good book. So I completed it for a second time. There were a lot of good stories and examples.The book was written in 2002. However the rules it presented were timeless. The author was actually a hardware/electronics dude. But he nailed the software debugging process down well.
The goal of the advice in the book is to help you find out what is wrong with a system quickly. If you fix your commercial software first, you get a competitive advantage. That translates to more money for your company. So you had better listen up.
When you figure problems out fast, you get to go home quicker too. I know this all too well. If I do not solve problems, I am there to midnight, and I have to return on Saturday morning.
It is difficult to find debuggers who follow the rules in this book. That means if you do learn and use these rules, you will be valuable. Let's first define some terms. Troubleshooting is trying to find out what is broken. Debugging is finding out why. This book is about debugging.
Let's get on with it. The first rule is "understand the system". There are eight more rules. I will be sharing some of these in future posts. Until them, happy hunting.
