1. 16
  1.  

  2. 16

    These commandments are best described by Agans in his book Debugging, which is probably the best book on debugging out there. Agans’ rules are below and are available in a sample on the site for the book. The ones that also appear in this post are marked.

    • Understand the system
    • Make it fail (*)
    • Quit thinking and look
    • Divide and conquer (*)
    • Change one thing at a time (*)
    • Keep an audit trail (*)
    • Check the plug (*)
    • Get a fresh view (*)
    • If you didn’t fix it, it ain’t fixed
    1. 7

      These commandments are best described by Agans in his book Debugging, which is probably the best book on debugging out there.

      I like that review of it some random dude wrote.

      1. 6

        I came here to post this same list - this is a great book :) It’s important to combine “understand the system” and “if you didn’t fix it, it ain’t fixed” in such a way as to really understand that if you don’t know why the issue happened, it is going to come back again. This is a type of information that humans are so terrible at acquiring, and are probably wired in such a way that we benefit from blinding ourselves to it, because it’s an example of an information hazard that causes us harm by simply acquiring true information which inconveniences us further. At some point, debugging is an act of self-harm due to the impact of acquiring hazardous information that imposes additional responsibilities on us or our team or tarnishes reputations etc…

        1. 3

          Yes indeed, but they are common sense. Working in mechanical automation, we were doing the same… I even had to go through certification. and the first things was to check the plug…

          1. 2

            I now buy copies of this book just to lend to junior engineers.