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.

Last week I walked through finding and fixing My Favorite Bug. Observant readers may have noticed a multi-step process outlined by some <H3> tags. Get the Attitude, Do Corrective Maintenance, and so on. What was that? It’s called the Universal Troubleshooting Process. The UTP was invented and copyrighted by Steve Litt in the 90’s. Prior to doing software, Steve used to fix stereo equipment, like when people would bring in tube amps that didn’t work any more.

At the end of last year’s storytelling session, I mentioned that my favorite story is “Two programmers fixing a show-stopper bug over 24 hours, with the fix being a two-character change in the source code that resulted in a two-bit change in the compiled program.” Here it is. The Problem It’s a Wednesday afternoon in 2006. I was just about to call it day when I get a call from the mothership.

I love stories. I love telling stories, and I love listening to stories. I learn from stories. I believe that we, as a programming community, don’t tell enough personal stories around the (virtual) campfire. Some may think it heresy, some may think “well duh”, but I believe that the programming profession is still really primitive. At the level of stone knives and bear skins. I air quote around the “engineer” part of Software Engineer.

I’ve talked about stochastic profiling in the past, such as the fairly recent Rock Heads. It’s something I mention when I talk about debugging or performance tuning at various conferences. Interestingly enough, I had a need for it last night because I had stumbled into an often-reported, difficult-to-reproduce problem and wasn’t in a situation to hook up Instruments. What is stochastic profiling? It’s fancy made-up name (but aren’t all names made up?

So. That Winning the Clash of the Coders Thing (with Krendler). Kind of nice being able to flex mental muscles over a 72-hour sleep-deprived Dr Pepper-infused period of time, performing acts of violence upon the Objective-C runtime, UIApplication, and the layer stack. It was a blast being able to use all my platform knowledge with the express purpose of subverting it. I was chatting with one of my Ranch cohorts the other day ages ago.