What is debugging, really? 🤔

I remember where I was sitting in the college media lab I managed when my mentor Nathan Wagoner asked me how we could quantify the skill of debugging. We talked about it a while, but never reached a satisfactory answer. It felt like the definition was on the tip of our tongues but eluded us.

I’ve thought about it many times since.

On Tuesday, my dojo’s manager told me she’d lost voice (only) from outgoing (only) landline calls. Also, the credit card machine said ‘connected’ and ‘processing’ but didn’t. Were the problems even connected? Did I have any ideas? I’m no network technician! But when she told me a second phone had the same problem, I found the modem and reset it. Problem solved. She looked at me like I’d levitated. “I knew if I just told you all the things I’d noticed, you’d probably figure it out.” Huh.

I do this to humans, too.

When I’m moderating a community, I can re-read a conversation and pick out the moment someone said something that didn’t land the way they intended, when even the participants didn’t notice. When I sit in team standup, I can pick out discordant notes in the stories engineers are telling about their work and see the problem they’re about to hit.  When someone brings me a challenge that lies in the ether between teams, I can tell you exactly how to fix it without bottlenecking either side.

I wondered if it was an unknowable, innate quality. 🧐

This week, a friend sent me a video about expertise that names the 4 conditions necessary for it: Lots of reps, clear & fast feedback, non-random environment, and not getting comfortable. Real expertise isn’t magic or some higher plane of thought, it’s just really advanced pattern recognition from seeing variations on a thing a million times.

Was I doing all of this for “debugging”? I think so, yeah. But what the hell is “debugging,” really? What was I actually practicing that created this feeling like I had some kind of innate magic I couldn’t explain. And as these thoughts spun around my head this morning, a few phrases spilled from my brain, and finally formed the sentence:

“Evaluating the complexity of a workflow for its failure modes.”

It is the practice of getting a product feature request and breaking it down carefully. Of understanding how big this code refactor will be. Of feeling how painful that requirement will be within the constraints of our system. Of understanding why this meeting format isn’t meeting our needs. Of planning well for a trip, an event, a talk, or a difficult conversation. Of mustering patience to listen intently for all the information, of pulling on every thread in the right order, and of not give up at “good enough”.

I ran my first meeting & planned an event when I was 12, so that’s 30 years of reps.

Now… how do I put that on my resume? 😂