So you have a bug report with some information. It may not be complete and you may not understand all of it. However, chances are, when you read it, an idea of where the problem lies will immediately jump into your head. There is an excellent (and very popular) book by Malcolm Gladwell called Blink. While it covers a lot of ground, the primary focus is on how the brain processes things subconsciously, which in some cases is good and productive, and in others is bad and even dangerous. The problem is knowing when to trust that instantaneous gut reaction. In the case of the bug report, that initial gut reaction is often invaluable, but it can also lead you astray. I follow a simple procedure to try to weed out misleading reactions:

1. Make a note of what the initial thought about the bug is ("it sounds like an SQL error").
2. Run that idea through a mini-gauntlet of reasons to throw it out (these will probably sound familiar):
• Is this a plausible theory?
• Is this a probable theory?
• Am I just trying to confirm something I already believe like blaming a faulty or poorly understood component?
3. If it fails any of these tests, keep the theory around in the tracker (more on the bug tracker later), but start with more data collection.
4. If it passes the tests, begin with that theory as a going assumption and look at the code for an obvious mistake (if available) or create test cases that would match the theory, rather than collect more data.

It is surprising how often this process allows me to bypass an extended debugging session. It is also surprising how often I've talked myself out of that initial idea and wasted a lot of time before coming back around to it.

Tomorrow: When the Blink Fails