The most counterintuitive truth in software economics is that the engineers who write the least code often create the most value. Not because they’re lazy, but because they’ve internalized something most teams never measure: the cost of what you build doesn’t end when you ship it.
We’ve constructed an entire culture of engineering productivity around visible output. Commits per week. Pull requests merged. Tickets closed. These metrics feel objective, but they measure motion, not progress. The engineer who writes 500 lines of code to solve a problem that didn’t need solving is statistically productive and economically destructive.
Every feature is a debt instrument
When an engineer ships a feature, the company takes on an obligation. That feature must be maintained, documented, tested, and eventually sunset. Bugs will arrive. Edge cases will surface. Integrations will break. The real cost of keeping a software product alive compounds in ways that most engineering teams don’t account for at the point of decision.
The engineer who pushes back on a feature request, who asks “what problem are we actually solving” and surfaces a simpler path, is absorbing that future liability before it exists. This is economically equivalent to preventing a bad loan, not refusing to work.
The math is straightforward. A feature that takes two weeks to build might take two engineers a week per year to maintain indefinitely. Over three years, you’ve spent more time maintaining the feature than building it. If that feature serves 2% of your users and doesn’t affect retention, the investment is underwater. The engineer who identified this before the first line of code was written generated more value than the one who shipped it on schedule.
The highest-leverage decisions happen before the editor opens
Senior engineers at companies that understand this dynamic spend a disproportionate amount of time in the space before a task begins. They’re reading product specs critically. They’re asking whether an existing tool solves the problem. They’re recognizing when a request reflects a symptom rather than a cause.
This looks like low output to a manager watching a Jira board. It looks like high output to anyone who’s ever maintained a codebase bloated by well-intentioned features that accumulated over years without a skeptic in the room.
GitHub’s internal engineering culture, which has been documented in talks and retrospectives from its engineers, has long emphasized that the most important technical decisions involve removing optionality rather than adding it. Fewer configuration settings. Fewer code paths. Fewer abstractions layered on top of abstractions. Premature abstraction is precisely how well-intentioned engineering creates systems that are expensive and fragile to change.
Saying no requires more skill than saying yes
Pushing back on a feature request is socially costly in most engineering organizations. It reads as obstruction. It invites friction with product managers and business stakeholders who’ve already committed to a roadmap. The path of least resistance is to build the thing, close the ticket, and move on.
This is why the ability to say no effectively is genuinely rare and genuinely valuable. It requires the engineer to understand business context well enough to make an economic argument, not just a technical one. It requires credibility built from previous good judgment. And it requires an organization willing to reward restraint rather than output.
Companies that don’t reward restraint get what they pay for. Their codebases grow. Velocity slows. New engineers spend weeks understanding existing complexity before they can contribute. The team adds people to compensate, which adds coordination overhead, which slows things further. Hiring a second engineer often slows you down for exactly this reason.
The counterargument
The obvious objection is that this logic, taken too far, justifies paralysis. If every feature carries future cost, why build anything? And isn’t there a risk that “the engineer who asks good questions” becomes cover for someone who simply isn’t shipping?
This is a fair concern. The argument here isn’t for engineers who produce nothing. It’s for engineers whose output is precision-selected rather than volume-optimized. The distinction matters. An engineer who declines three requests and ships one that’s well-scoped, well-tested, and genuinely necessary is more valuable than one who ships all four and leaves the team holding the maintenance bill on three of them.
The measurement problem is real. Most productivity tools, as they currently exist, don’t capture avoided work. They don’t track the features that were never built. They don’t credit the engineer who sent an email saying “we already solve this with X” before a two-week project began. Until those contributions are legible to organizations, the incentive to produce visible output will remain stronger than the incentive to produce good judgment.
The position, plainly stated
Engineering output measured in volume is a symptom of organizations that don’t understand their own cost structure. The engineers who generate the most economic value are often the ones who slow down, ask harder questions, and route the team away from work that would have cost more to maintain than it was ever worth to ship.
This isn’t a soft argument about work culture. It’s an argument about where value actually accumulates in a software business. Code that doesn’t exist doesn’t need to be maintained, debugged, or eventually deleted. The engineer who understands this and acts on it is doing economic work that most performance reviews won’t recognize and most metrics won’t capture. That’s the problem worth fixing.
