1. 42
  1.  

  2. 13

    I’ve found two things helpful when debugging. The first is keep the scientific method in mind—form a hypothesis, test, repeat as necessary. The second is this quote from Sherlock Holmes: “When you have eliminated the impossible, whatever remains, however improbable, must be the truth.”

    1. 6

      Also: Always start under the assumption that the bug is in your code. This was super helpful when I was just starting out with programming. I can’t count the number of times that I yelled “there’s a bug in the CPU!” when writing assembly code at uni, which is of course preposterous (well, not really, but the chances that a greenhorn runs into such bugs in simple code is vanishingly small).

      1. 5

        In cases where I spent more than a few days debugging, the cause was always an implicit assumption I made (e.g. ‘this piece of code is so simple that the bug is probably not here’ – but weird things can happen if you use a library you’re not completely familar with, or overloaded operators, or languages that concatenate strings when you forget a comma between them…). So at some point, you need to start realizing the implicit assumptions you’ve made.

      2. 3

        Another useful approach: always validate your assumptions. The number of times things like:

        • There’s no way this is dns related, wait it was one dns server doing dumb stuff, or even one wrong nameserver
        • Double check simple things first, any full filesytems? memory? you sure?
        • etc….

        I’ve helped a ton of people having problems debugging something and in about 2 minutes sometimes managed to debug their problem by just asking if they’ve validated the basics first.