I’m not going to take credit for the story, nor would I claim a perfect analogy. But here goes.

Imagine you’re in a room with ten screaming babies. As all of them are screaming at the top of their lungs, you start feeding them one by one. You’re done with one, and there are nine screaming babies left. Some time passes and you’re done with another one, and there are eight screaming babies left. Some time passes and you’re done with another one, and there are seven screaming babies left. And it doesn’t feel like you’re making any kind of progress because as long as there is at least one baby screaming, you can’t get any peace.

That’s how it can feel to be a programmer on any reasonably sized project. Where screaming babies are bugs in your incoming queue. They never stop demanding your attention, and they never stop screaming at you. Unless you make peace.

If there’s one axiom of software development that I hold inviolable, it’s that there will always be bugs. You can surround yourself with a bunch of processes, or do extensive code reviews and endless testing rounds. But the bugs will always be there. If anybody tells you that their code doesn’t have bugs, just shrug and walk away. They have no idea what they’re talking about.

Make peace with the simple fact that the code you’re shipping today has bugs.

Some bugs are scary. You need to tackle them. Some bugs, on the other hand, are these little tiny things that simply don’t matter. The problem with most (probably all but I haven’t tried them all) bug trackers is that the scary bugs in your queue look exactly the same as the tiny bugs. Most of the time the only difference is going to be in the single digit in the priority column. Or maybe the scary bugs will have light red background across the entire row. Or maybe the tiny bugs will use lighter text color. But they probably won’t.

And so you stare at your queue and you feel that you just can’t win. No matter how much effort you throw at that queue, as long as you’re not at zero bugs, they are screaming at you. And every time you fix a bug, you touch your code base. That’s another bug that you’ve just added. And every time you fix a bug, you get assigned a couple more.

Make peace that not all bugs are created equal.

Zero Bug Bounce is a fiction that some people invented to make peace for themselves and to create an illusion that they are in control. So at some point in the cycle everybody looks at the pages upon pages of bugs in your project queue, frowns and then mass-migrates a bunch of bugs to the next release. And to the next one. And to the next one. And at some point some bugs have been bumped out so many times that you might as well ask yourself some very simple questions. Do those bugs matter? Do they deserve to be in the queue at all?

Make peace that not all bugs are actually bugs.

Sometimes a feature that you’ve added to your product just doesn’t work out. It doesn’t get the traction you’ve expected. Or it’s not playing well with some other features that you’ve added afterwards. Or you’re not even sure how much traction it’s getting because you forgot to add logging, and there’s nobody on the team who actually cares about this feature after the guy who did it left the team and you’re in the middle of the big redesign of the entire app and why should you even be bothered spending extra time on that feature. Phew, that was a bit too specific.

And of course there will always be somebody who used that feature. And now that you’ve taken that toy away from them, they are screaming at the top of their lungs. And you cave in and bring that feature back. Well, in theory at least. But it’s been redesigned to fit into the new visual language of the platform. And now somebody else is screaming at you because you’ve changed things. All they want is just a teeny tiny switch in the settings that leaves things they way they used to be. Sure, they want new features, as long as they look exactly like the old features. But that’s a topic for another day.

Make peace that your work is never done. That if you want your work to be seen, you have to ship. Make peace that the work you ship will have bugs. Take pride in things that work. Develop a sense to know scary bugs from fluff. And develop a thick skin to ignore the screaming.