2026-168

Over my time in the software engineering industry, one of the most common unspoken expectations I have observed among software engineers is that one is obligated to produce code. If you challenge this, there is some sort of visceral bewilderment, like, "what are you insinuating," or, "what did you hire me for?"

Yes, we need to produce code to build things. However sometimes what a project needs is for someone to delete code. Or even for someone to just maintain the code, such as when a project has shipped but the core maintainers have left for whatever reason. All engineers that I have met, and myself in my own personal experience, have been caught off guard when--if--they have this realization.

But why? That's what this blog post is about.

In this field, whether someone learned programming in school or was self-taught, the reason is because they wanted to (or were forced to) build something. Not maintain something. Not delete something. Their teacher said, "the project for this next two weeks is to build a compressor," or some other mechanism implementable in code. This makes sense. First you learn the theory and then you build it yourself for experience. But have you ever heard a professor say, here is a 300k line project. Can you preserve its behavior but simplify its implementation? Or, here is a project that meets all customer requirements. Over the next two weeks, we'll reveal real bugs to you in the form of simulatd user feedback, and you need to fix them. Or maybe the student needs to upgrade a fundamental dependency, and the next version has breaking changes.

Boring! Nobody will pay US college prices for that. And no self-taught programmer started by finding a complicated, existing project they liked and thinking, wow, can't wait to maintain this thing. No, it's, can't wait to make my mark on the world by building something.

We bring the next generation up with the incorrect expectation that software engineering is the art of emitting code in all circumstances. As anecdotal proof, how many people do you know would call a project with no changes over the last few years "dead," even if people used it all the time, because said people don't know what stable code is? Sir, that is a JSON parser, and there is just nothing more we can add to that project to parse JSON harder, better, faster, stronger.

If you're building your own thing, go ham. Take something from empty text file to product. That's awesome. The trouble comes particularly in industry, where sometimes the project is in exactly the state it needs to be in, but instead of letting it rest in that state and fulfill its requirements, we are compelled to disturb it, in the form of scratching that itch, that I must build, I must grow, I must extend something. That is why I exist here. And in doing so I feel a sense of purpose and fulfillment, stimulation, meaning.

No, the thing you must come to terms with in these periodic circumstances is that you get paid to show up and use your technical expertise to prevent the thing from growing or changing needlessly.

Alas, as we all know, most companies do not incentivize letting things be. The job description you applied for required 10 years of experience in that one language in addition to mastery of peripheral tools and skills, because you are expected to build someone's technological vision of the future described in a couple sentences in English. And who knows, if the implementation is Byzantine enough, you may even get to inject your own quarantined vision and mutate endlessly behind its interfaces.

Less facetiously, imagine sitting in front of your computer as a software engineer, and your boss walks by. You're just sitting there, maybe casually browsing the web. A couple hours later she walks by again. You're still sitting there, maybe now looking at your phone after peeking at your inbox to see if you had any new alerts mailed to you. The product is working, making money even. Things are stable and good. But neither you nor your boss feels good about--nay, can justify to your boss's boss--your behavior that day.

Or maybe you wanted that promotion. How can you quantify how much professional nothing you did, even if it was the right thing to do regarding (not) evolving the codebase, to make a case why you deserve a promotion? You can't, to most bosses in this field. But everyone understands the (often-manufactured) problem of some system that suffered for some reason, and you showed up and banged all this stuff out, and now that suffering is gone, and suffering being gone is good, right? No, it wasn't customer suffering. No...we weren't suffering either. Okay, I was suffering, because the honest best thing was to have done nothing at all, but then I feel like I'm wasting my life, and it didn't serve me!

Outcomes follow incentives. But to steelman the situation, selling the reality is hard. Which job would you apply for, the one that needs engineers to constantly be building, or the one that says you'll build when required but will otherwise maintain the result of someone else's productivity and honestly probably won't be promoted from Software Maintainer to Senior Software Maintainer?

There are companies out there that need a lot of things built, even big companies, and in these places people will find themselves building all the time. But most people are not prepared (themselves, nor by others) for what awaits them in many companies today.

This unpreparedness has a very unfortunate side effect, which is that it causes people to revel in complexity because mutating something gives the illusion of productivity, and then this gets reified, and people start to think that this is what software engineering is all about. And if you threaten this, attached people feel it the same as you threatening them.

Another unfortunate side effect is that a lot of the software products you use produced by companies that incentivize their engineers to be busy changing code will likely eventually get worse over time.

Complexity is natural when you don't know how to do something. But complexity does not need to be forever. See images of "SpaceX Raptor engine evolution" for this point in an image.

If you felt like this post described the situation around you, I encourage you to make a change in your environment. There are lots of meaningful things that are waiting for us to just build them, but many things being built right now are meaningless in the long run. Remember that you ultimately pay with your time.