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. And there’s a tinge of judgement. 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 that you don’t want, not the bugs themselves? Interruption, of course, . But if you setup your 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? interruption has many hidden costs tools 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 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. resource constraints However, there are many about tackling busy work queues. Like picking a constrained and more available medium, If-Then planning, and daily prioritization techniques. useful things we’ve learned 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 cost you, they can hurt you and others a lot. can 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 ! Looking at the simulation and , for example, can be a good source of tester-envy — it’s amazing how far you can practically go to simulate problems ahead of time, or to systematically root them out by using . finding bugs before the universe finds them testing of open source database projects formal methods ~ 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 , , using a web debugging proxy, or querying access logs. git blame git bisect 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 features and entire projects better. future 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 world for. Can you imagine getting drip by drip feedback from the universe as a, , academic scientist in today’s world? We’re blessed with of experiments we didn’t even know were running. starves gasp annotated results Bugs are even useful for on-boarding, I think. What better way to 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 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 as your first task. really should ease others’ pain 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. originally published on kilotau.com
