Differential Diagnosis is an excellent approach to debugging. Seeing debugging in the wild before, I've seen two, maybe three different approaches to debugging:<p>1) Magical thinking: This is the fear that the computer system has suddenly changed its mind and decided to stop working. The approach here is typically to try some cargo-cult knowledge on how to fix the system without knowing what's wrong, and then just start hitting random things, and see if they come back.<p>2) Panic / Fixation: These kinds of developers usually get into a state where they are in a panic over what's wrong and fixate on one component of the system where they believe the failure to be. This is slightly more productive than the earlier, but not changing your assessment based on the new information gained is also counterproductive.<p>3) DDX: This is very much the Sherlock / House type of debugging. It tends to require a lot of wide-shallow knowledge, as opposed to in depth knowledge of the system. Typically, you work backwards from the symptoms, and essentially do a binary search based on the widest type of problem sets to the narrowest.<p>DDX in-fact is very difficult for most people to do under stress. Nelson from Stripe wrote a post on keeping a notebook to store wide information, and enable caching b-tree searches. This is a very good approach.