Debugging

I think that sometimes people will find a single word to describe a set of activities they are doing and then use that word unendingly. This has caused me to be sick of the words simulation and debugging. It's a really bad pair of words for an electrical engineer to be tired of. If used when describing a specific action and switched up with some synonyms they're fine but if you are looking at some circuits for several months and you use the word simulation every time you talk about working on them it gets super repetitive (notice how I used three different words to describe it instead of 1?!?! - yes I know that none of this applies to anyone that reads this, but I had to say it).

Warning - if you are not an engineer the rest of this post is probably pretty boring (even more so than usual).

Well, now that I've stated my distaste for the word, time to discuss a book titled Debugging by David J. Agans. After coming up with my own rule for debugging I decided to see what others had to say about it (also worked out well because I got the book in time to use some of it on the tester stuff I was working on in KS). The book discusses 9 rules for debugging. There were a few rules that have caused me to watch how I work, such as when you talk to someone to get a fresh opinion, don't tell them your theory or it ruins the point - I am sometimes guilty of doing that. Also if you didn't fix it, it ain't fixed - the point of this rule is once you think you've fixed it, make it fail again and show that your fix by itself actually gets it working again, which is a step I often skip. But mostly it is nice to see some rules of debugging spelled out so that when I work I can identify which rule I am applying and feel more confident about what I am doing, or see that I am not following one and rethink my strategy. Also when I don't feel like carefully changing one thing at a time or keeping an audit trail or learning about the system (reading the manual) or one of the other slow, boring parts of debugging (especially when it is late and the sounds of the test floor are getting on my nerves), thinking back to the rules is useful.

The book also has some interesting examples since the guy went to MIT and has worked on a number of interesting projects including working on pong and creating the mode where it plays against itself as a way of having the game run so that he could observe intermittent issues.

I would claim that my drop your assumptions rule is a combination of two of his rules, check the plug (basically, check your assumptions) and quit thinking and look (rather than thinking up theories, go make some observations and run some tests - especially when you are about to make the claim "that can't happen").

I was a bit skeptical at first that the book would be mostly obvious and that reading about something that is often considered a skill wouldn't be that helpful, but if you do a lot of debugging I would actually recommend it.