Bug Fixing in Software: The Inversion Method

This is a cross-post from my blog on Digital Mapmaking. Check it out for more content!

See https://www.youtube.com/watch?v=bM3rK_fqY6k for the video version of this post.

Today, I was working on the Native Land site, trying to set up a conversion from the old plugin I built (WP Mapbox GL JS) to the new one (Mapster WP Maps). This has been a difficult, multi-step process because of the complex nature of the posts, the importance of retaining all the data, and the intricacies of both plugins and geographic data in general.

However, the bug today was annoying. I could use a lot of expletives, because I still haven’t figured it out, so it’s still frustrating me. Basically, for some unknown reason, every time I am doing a wp_insert_post, it’s inserting the post twice — despite nothing being in a loop, and getting everything down to the most basic replication of the issue. Eventually, after a couple hours, I had to call it quits and return to it tomorrow.

I’ve been reading a lot lately about mental models and ways of approaching problems. Charlie Munger is a famous proponent of “inversion” — that is, tackling the problem from the other angle by asking something like “what’s the stupidest thing I could do right now?”, or, “what would definitely make this situation worse?” and then not doing that.

I thought today, we could apply that to bug fixing. Most of the time, when I’m fixing bugs, I’m looking for solutions — searching StackOverflow posts, testing new things, reducing code to simplify and isolate the error. I am strongly focused on “what’s the most likely way to solve this problem”. So — how could inversion help?

Phrasing the Issue

Instead of “How do I solve this bug?”, I’m going to ask “What are the stupidest things I could do when trying to fix a bug?”

It’s actually a bit tough to think this way. Because bug fixing is an idiosyncratic, almost magical thing at times, many things you think would be a bad idea sometimes work. Like, refreshing the page a dozen times — it’s stupid, but it might actually reveal something after all. So we’re not necessarily trying to state things that would never work — but rather, things that are stupid to do. We want to get to the solution as fast as possible and avoid dumb behaviour.

So what’s stupid when it comes to bug fixing?

• Punching the computer or a nearby object (getting angry and emotional)
• Getting continually stuck in a narrowing tunnel vision
• Not recognizing when it’s time to work on isolating the issue vs trying to make small changes to fix it
• Doing the exact same thing repeatedly without a good reason (ie, refreshing the page over and over without any changes)
• Not looking up related terminology on Stack Overflow, Github issues, documentation
• Working on it for multiple hours straight without a serious break
• If a junior developer, not asking for help or a second opinion

This is a short list, but I think this covers some of the key points. So which of these did I do today?

• I became emotional and angry
• I did the same thing repeatedly without a good reason — which only made me angrier as I continued confirming the seemingly irrational error
• Got stuck in tunnel vision — didn’t recognize when I should move to isolating the error over trying to fix it
• Using inversion, I can see clearly that I made stupid mistakes that probably cost me time, energy, emotional fatigue, and, most of all, joy, in trying to fix my bug.

Why Do I Do Stupid Things?

Asking myself why I do stupid things is a great question. It’s not that I don’t know things are stupid when I do them — when I’m getting angry about a coding issue, I’m perfectly aware on some level that it’s not going to help, and that it’s moreover quite ridiculous to get emotional about it. So why do I do it?

One reason is that, in some ways, I may have convinced myself that this is just the process for bug fixing. Because I’ve fixed very complex bugs after becoming emotional and angry before, I’ve associated this feeling as part of the necessary process in fixing these kinds of issues. So when it happens, rather than thinking “Oh, this isn’t helping”, I think, “OK, let’s do this.”

So, habit. Habit and a belief that this actually helps, when that’s just not correct. Just because I get to the end of the journey eventually doesn’t mean that the complicated, difficult twisting road that I took was the most efficient or most enjoyable one to take.

And, I have a sneaking suspicion that the most efficient road is probably also the most enjoyable one. So why not act less dumb and see if it’s also more fun that way?

So, next time…

From here on out, I’m not going to do it perfectly, but maybe I can do it a little less idiotically. So next time I’m facing a bug, I won’t try to do it better, but just less badly. When I notice the emotional feeling, I can:

• Realize it’s time to take a break for 5 minutes
• Reflect on whether or not I am tunnel visioning
• Reflect on the least dumb way to continue tackling the problem

I hope this reflection has helped you a bit! I hope it helps me, too.