I usually encounter two classes of bugs on a regular basis. The first is of the form “I think I know where this is” which won’t take long to find. The steps are pretty easy: Figure out how to reproduce it. Set a couple of breakpoints. Add some caveman debugging. Find the problem and fix it. These are my favorite kind of bugs because they’re over and done with quickly, I can get a quick hit of that “you done did good” glow from making a software system better, and then move on to some more interesting problem.

You can find Part 1 of this series here This has happened to everyone. A colleague walks into your space, erases your white board and starts scribbling on it. They say, “Hey, I’ve got this problem, and I wanted to know if you could help me with it,” followed by five minutes of boxes and circles and arrows. And then comes, “Oh yeah, I see the problem! Thanks!” They walk out, and you haven’t even said a word.

You can find Part 2 of this series here Im told Im a pretty good debugger. Friends come to me to help solve software problems. And occasionally it works. But what is a good debugger? What is debugging? Making software run better? Reducing the entropy of the universe? We all know what “Debugging” is because we all do it, but it’s still an interesting question. You could think of debugging in the same way as adding new features to software – you’re just taking this program from one state to another, like it’s a great big state machine.