A few years ago, a team I know spent six weeks building a custom notification delivery system. Queues, retry logic, templating engine, the works. Something like 4,000 lines of thoughtful, well-tested code. Three months after launch, they ripped it out and replaced it with a third-party service that cost $200 a month. The homegrown version had solved problems the product didn’t actually have, and created maintenance burden the team couldn’t afford. The engineer who eventually made the call to delete it and buy a replacement wrote almost nothing. She spent a week evaluating options, made a recommendation, and the whole migration took two days. Most engineering managers would struggle to write her up as a high performer in that quarter.
That tension is what this article is about.
Why We Measure What We Can Count
Lines of code is a bad metric. Everyone in software engineering knows this. It’s been known since at least 1986, when Fred Brooks wrote about it in The Mythical Man-Month. And yet, it persists. Not always explicitly, but in the ambient way teams evaluate contribution. Who’s shipping features? Who’s got a big green commit graph? Who’s always busy?
The reason is simple: code is visible and countable. The things that actually generate engineering value, avoiding unnecessary complexity, recognizing when a problem is already solved, designing systems that don’t require heroic maintenance, are largely invisible. You can’t see the system that didn’t get built. You can’t measure the incident that didn’t happen because someone pushed back on a bad architecture decision in a design review.
This creates a structural incentive problem. Engineers who ship a lot of code look productive. Engineers who prevent unnecessary code from being written look like they’re not doing much. One of those groups is often more valuable than the other, and it’s not always the first one.
The Compounding Cost of Code That Shouldn’t Exist
Every line of code is a liability before it’s an asset. This is not a controversial position if you’ve maintained a large codebase for more than a few years. Code has to be read, understood, tested, updated when dependencies change, debugged when it breaks, and eventually deleted or replaced. The cost doesn’t end at merge.
This is why the best engineers I’ve seen at senior and staff levels spend a surprising amount of time on what looks like overhead: asking whether something needs to be built at all, identifying existing internal tools that already solve 80% of the problem, pushing back on requirements that will create downstream complexity without proportional user value. They’re not being obstructionist. They’re doing math that most organizations don’t have a good way to account for.
Consider how technical debt actually accumulates in practice. It rarely comes from one catastrophic architectural mistake. It comes from hundreds of small decisions where someone chose to write code instead of challenge the requirement, chose to add a special case instead of questioning the underlying model, chose to build instead of buy. Each individual decision looks fine in isolation. Together they produce the codebases where a simple feature change takes three weeks and requires touching fourteen files.
What Senior Engineers Are Actually Paid For
There’s a reason engineering compensation tends to compress at the junior and mid levels but spread dramatically at senior and above. It’s not primarily about technical skill, though that matters. It’s about judgment, and judgment in software engineering is largely the ability to correctly assess what not to do.
A junior engineer’s value is roughly proportional to their throughput. They’re executing well-scoped tasks, learning the codebase, filling in capacity. The system they’re working in is mostly set up by other people. This is fine and appropriate.
A senior engineer’s value is something different. Their code contribution might actually be lower in volume than a productive mid-level engineer, and that’s not a warning sign, it’s often a signal that they’re doing the right work. They’re in architecture discussions shaping what gets built. They’re writing design documents that prevent wrong turns. They’re the person who reads a pull request and asks why this is being added at all before they ask whether the implementation is correct. That question, asked at the right moment, can save weeks of work.
Staff and principal engineers take this further. The engineers I’ve seen at those levels who were genuinely exceptional spent more time in documents, conversations, and reviews than in an editor. Their output was organizational, not individual. They made everyone around them slightly smarter about the problem space.
The Build-vs-Buy Failure Mode
One of the clearest ways this plays out is in build-versus-buy decisions, and the engineering culture in many startups has a strong gravitational pull toward building.
Some of this is rational. There are real cases where building custom infrastructure creates durable competitive advantage, where the off-the-shelf options are genuinely inadequate, where vendor lock-in risk is high enough to justify the investment. But many build decisions happen for reasons that have nothing to do with any of that. Building is more interesting than buying. It feels like real engineering. It creates visible output.
The engineer who looks at an authentication requirement and says “we should use an existing identity provider” is doing something harder than the engineer who builds a custom auth system. They’re resisting the pull of an interesting technical problem in favor of a boring correct answer. The boring correct answer is almost always better for the business. It’s also harder to notice and reward.
This connects directly to why deleting a feature is harder than building one. The asymmetry isn’t just psychological. The incentives really do point toward creation and away from restraint.
The Metrics That Actually Predict Value
If lines of code and commit frequency are the wrong signals, what are better proxies for engineering impact?
A few that hold up in practice: how often does this person’s code need to be revisited or patched shortly after shipping? Do their systems require ongoing firefighting, or do they run quietly? When they review other people’s work, do those reviews catch real problems or just stylistic preferences? Are the systems they design easier or harder to change six months later? Do other engineers seek them out when they’re stuck?
None of these are easy to measure in a quarterly review. That’s partly why the metrics don’t get used. But they’re not completely unmeasurable. Production-only bugs tell you something about whether someone is thinking about correctness beyond the happy path. System stability over time tells you something about whether the underlying design was sound. These signals exist; organizations just have to care enough to look for them.
The harder problem is cultural. Organizations that reward visible output will get engineers who optimize for visible output. If a high-judgment engineer watches a colleague get promoted for shipping a large feature that was mostly unnecessary complexity, they get a clear message about what’s valued. The best engineers are not immune to incentives.
When This Goes Wrong in the Other Direction
It’s worth being direct about something: this argument can be badly misapplied.
The engineer who ships nothing and chalks it up to “preventing unnecessary complexity” is not the engineer I’m describing. There’s a real failure mode where the language of technical judgment becomes cover for low output that isn’t actually strategic. Saying no to everything isn’t judgment; it’s obstruction. Spending six weeks in architecture discussions without producing anything is not the same as producing fewer lines of code with higher impact.
The distinction matters. The engineer who writes less code and is worth more is someone who writes less code because they made a correct call that saved the organization from something expensive. They still ship. Their systems still work. The value they’re creating is real; it’s just not all in the diff.
The other thing that needs to be said: this argument applies at scale, but not at founding. An early startup where the engineers are trying to figure out if they can build something at all needs throughput and momentum. The bias toward doing and building exists for a reason in that context. The calculus shifts when you have a codebase and a product and users who depend on the system staying reliable.
What This Means
For individual engineers: the skill of asking whether something should be built is as important as the skill of building it. Learn to develop and express that judgment clearly. If you’re in an environment where restraint is invisible and output is everything, that’s worth factoring into your decisions about where to work.
For engineering managers: your compensation and promotion criteria telegraph your values more clearly than any principle document. If the engineers who prevent expensive mistakes are being treated the same as the engineers who create expensive mistakes by shipping fast, your system is mis-calibrated. The correction isn’t complicated, but it requires actually looking for the value that doesn’t show up in commit graphs.
For organizations at scale: the transition from startup to sustained operation is partly a transition in what engineering excellence looks like. Early, you need builders. Later, you need builders who also know what not to build. Companies that don’t make this shift end up with codebases and teams that require more and more resources to move at the same speed, not because the engineers got worse, but because the incentives never adapted.
