You open up your email, swipe through some work messages, and notice a classic email about a bug.

RuntimeError: Your app is terrible
app/controller/page:17 - what is
config/route/blah:24 - this I
bin/app:4 - can't even

It looks… strange. The error message and the stack trace look only vaguely familiar.

You would be forgiven for being annoyed or even anxious at that moment.

But that bug and its siblings are actually your best buddies. And that’s not just in an “always see the bright side of life” kind of forceful mental gymnastics way – there are visceral reasons to believe this.

“There are so many reasons to reject this claim, though!” Yeah, there are, let’s explore some of them.

An easy one is the interruptive nature of bugs. They come of their own accord, like a rude party guest. They spit in the punch bowl, break your lamp, and then grumpily sit down in the middle of dance floor. You have to drop what you are doing to even deal with their general… situation.

Of course, if you have a week or two of work planned, work that is new and requires your careful attention, the last thing you would want is a bug.

Or is that interruption that you don’t want, not the bugs themselves? Interruption, of course, has many hidden costs. But if you setup your tools and processes to not interrupt but rather to buffer notifications so that you address them at a predictable schedule, would this reason to the reject the claim still stand?

But hey, there’s another reason to reject the claim right? Even if you buffer bugs, there’s just too damn many of them! And that’s only the ones we can notice at all. What about emergent requirements in the experience we didn’t figure out ahead of time?

Of course, if you have a queue of bugs that only seems to grow, bugs are the last thing you’d celebrate.

Or is that resource constraints that have you down? I don’t think many of us enjoy to do lists that only ever grow, they’re disheartening. And due to change-of-ownership, requirement changes, or just code/tests that didn’t anticipate every edge case, we may often have more work than we can realistically complete.

However, there are many useful things we’ve learned about tackling busy work queues. Like picking a constrained and more available medium, If-Then planning, and daily prioritization techniques.

And there are many ways to tackle requirement uncertainty. It’s not perfect, but with more iterations, better tools, and clearer communication, we can get pretty far.

But hey, this is not even getting at the absolute worst part about bugs. They can cost our customers and ourselves dearly! They can destroy lives at their worst!

Of course we wouldn’t cherish bugs when they can cause so much destruction.

Or is it th– no, actually, this a valid concern, haha. Bugs can cost you, they can hurt you and others a lot.

But, the world is not a one-shot game. You’re not dealt just one hand. The collective “us” learns from past mistakes, in many cases. On an individual level, massive failure can be immensely educational and rewarding. On a meta-civilizational level, it can hammer away fragility in institutions. Battle scars and so on. Hey, it’s not perfect, but it’s not all negative!

Also, nothing’s stopping you from finding bugs before the universe finds them! Looking at the simulation and testing of open source database projects can be a good source of tester-envy – it’s amazing how far you can practically go to simulate problems ahead of time. Problems like duplicate packets, power supply failures, etc.

~

Bugs are more than just “not all bad,” though, they’re friendly.

First, bugs are puzzles. That’s really it. They have vague clues about the root cause, and a trail made up of information traces and causal effects on the surrounding world. And they reward even pure discovery, let alone mastering a fix!

Imagine the exact moment you last figured out a bug. When I remember a couple of examples from last week, I remember smiling wide and saying “Oh!” It’s quite satisfying.

Not all of us enjoy puzzles, yes. They are costly to think through, they take time and attention. But still, I imagine a large fraction of us can appreciate difficult things that eventually gift us with an emotional reward. Delayed gratification.

Another great thing about bugs is that they exercise so many interesting parts of our brains. To figure out bugs, you need to develop and exercise code archaeology, simulation, and debugging skills, among others. Like git blame, git bisect, using a web debugging proxy, or querying access logs.

But beyond that, bugs exercise our probabilistic decision making skills. For example, if only one area in your web app deals with user uploads of CSV files, indications that a new bug is related to importing increase the probable blame you should place on that area of the web app (even before fully identifying the bug’s source). You can also approach a root-cause-finding by cutting out probable causes quickly, ideally halving the hypothesis space each time. It sometimes helps to query a few histograms of event-counts, to get a sense for what function calls happen most frequently, and under which contexts.

When you notice a bug, you often have a background notion about various situations under which it is likely or not likely to occur. If you don’t already have one, after resolving some bugs, you also develop a notion of which parts of the app are riskier. There is a feedback loop of increasing intrinsic familiarity with a system, a familiarity which helps you pick out how to write better tests, how to build better meta-tools, and how to cut down discovery-and-development-time.

There’s just… so much open area to refine this art of investigation! And you’re basically building intellectual wealth by exercising this art. Wealth that lets you buy deeper insights into building future features and entire projects better.

And beyond that, they force us to exercise healthy skepticism. There’s a level of accountability that bugs hold us to, a level of feedback the rest of the intellectual starves for. Can you imagine getting drip by drip feedback from the universe as a, gasp, academic scientist in today’s world? We’re blessed with annotated results of experiments we didn’t even know were running.

Bugs are even useful for on-boarding, I think. What better way to really know a codebase than to figure out why it didn’t behave like it should? You not only have to bootstrap the project and understand how it behaves, you have to understand how it should behave, and then how to wrest control over it so you can unpack or simulate the problem to really understand it. It’s tougher than a small (less meaningful) feature, and it’s more satisfying to ease others’ pain as your first task.

People want to help people, freaking let them!

One reason to be skeptical is that if you don’t pick the right level of a bug, you’re just asking people to spin their wheels for several days (hopefully never weeks!) But with some curation of the bugs with people more familiar, bug queues can be handy on-boarding tools.

Anyway, friends don’t want you to stagnate, they want to build you up, to see you grow. Bugs are not people, but I’d invite them to my parties. Maybe I’ll cover up the punch bowl and set them up to not piss off everyone else. But I’d listen to what they have to say.