The Best Code Is the Code You Did Not Have to Write

The Counter-Intuitive Optimization

Engineers are evaluated, rewarded, and promoted largely based on what they build. Pull requests merged. Features shipped. Services deployed. The incentive structure creates a strong association between "doing good work" and "writing code." This is mostly harmless and sometimes actively wrong.

The code you write has a cost that persists long after you've moved on to the next ticket: it has to be tested when it changes, debugged when it fails, understood by every developer who reads it, and maintained when dependencies shift. These costs are real and ongoing. The best possible outcome for any problem is solving it without incurring these costs at all.

This is not an argument for laziness. It is an argument for treating "no code" as a serious design option that gets evaluated first.

The Categories of Not Writing Code

Using what already exists: Before building a solution, audit what the codebase already provides. The most common form of unnecessary code is re-implementing something that already exists elsewhere in the project, in a dependency, or in the standard library. This sounds obvious and is surprisingly common. New engineers often don't know what the codebase provides. Senior engineers sometimes forget, or discount existing solutions because building feels more satisfying.

Buying instead of building: A third-party service or library that solves your problem is not a compromise — it's a trade of money or dependency risk for engineering time and ongoing maintenance cost. This calculation often favors the third-party option significantly. Building your own authentication system, payment processing, PDF generation, or email delivery is rarely the right choice. These are solved problems with mature solutions; the only thing custom code adds is surface area for bugs and maintenance burden.

Changing the requirement: Sometimes a requirement can be modified in a way that is acceptable to the product and eliminates a significant implementation. This requires asking questions instead of accepting requirements as fixed. "What if we made this weekly instead of real-time? What if users could opt in instead of opting out? What if we used a simpler approximation instead of an exact calculation?" Engineers who treat requirements as constraints to optimize against find these openings. Engineers who treat them as specifications to implement do not.

Deleting code that isn't needed: Unused features, deprecated endpoints still being maintained, dead code paths that haven't been triggered in a year — these are negative assets. They consume test suite time, cognitive load, and potential maintenance. Deleting code is one of the highest-leverage activities in a mature codebase and is systematically undervalued.

The Opportunity Cost of Every Line

Jeff Atwood's formulation is still useful: the best code is no code at all. Every line you write is a potential source of bugs, a maintenance burden, a cognitive tax on every reader. This doesn't mean don't write code. It means ask whether the code is necessary before writing it.

The question to ask before implementing anything: is there a way to solve this problem that doesn't require me to write and maintain new code? If yes, explore it. If no, proceed.

When This Principle Gets Misapplied

The failure mode is using "avoid writing code" as cover for cutting corners on things that genuinely need to be built. A proper authentication system, error handling that actually recovers from failures, data validation at API boundaries — these cannot be skipped. Skipping them produces a different category of problem: not unnecessary complexity, but missing correctness.

The principle applies to scope, not to quality. Don't write more than you need. But what you do write, write well.

The Practical Takeaway

Before starting any new feature or service, spend fifteen minutes asking: what is the minimum surface area of code that could solve this problem? Are there parts of this that an existing library, service, or simpler design could handle? Is there a modified version of the requirement that requires significantly less code and is still acceptable? The answer will sometimes be "no, we need to build it" — and that's fine. But the habit of asking prevents the slow accumulation of code that didn't need to exist.