Engineers get rewarded for adding — features shipped, lines written, pull requests merged. So they add. But here's the counterintuitive truth experienced engineers eventually learn: every line of code is a liability, not an asset. Code has to be maintained, debugged, secured, and understood — forever. The most valuable code is frequently the code you didn't write.
This reframes the whole job. Here's why deleting beats adding, and why the best engineers write less code, not more.
Code is a liability, not an asset. Every line must be maintained, debugged, and secured — so the best code is often no code.
The reframe:
The best engineers solve problems with the least code, not the most.
The intuitive view is that code is an asset — you build it, you own it, it has value. But code's value lies in the problems it solves, not in its existence, and meanwhile every line carries ongoing cost. Code must be maintained as requirements change, debugged when it breaks, secured against new threats, and understood by everyone who touches it later. That cost never ends; it's a perpetual liability on the books.
This is why "more code" is rarely the win it feels like. Each line you add is something that can break, a surface that can be attacked, a thing the next engineer has to comprehend. The codebase that does the same job with half the code is better — easier to maintain, harder to break, simpler to secure. Recognizing code as a liability rather than an asset flips the instinct to add: the goal becomes solving the problem with as little code as possible, because every line you avoid writing is a liability you never take on.
Once you see code as a liability, a powerful question emerges before any build: do we need to write this at all? Often the best solution involves no new code:
| Instead of building… | Consider… |
|---|---|
| A new feature from scratch | Reusing what already exists |
| A complex custom solution | A simpler approach with less code |
| Yet another abstraction | Removing one |
| The feature at all | Whether it's even needed |
Reuse, simplification, and not building are frequently superior to writing something new, precisely because they avoid taking on new liability. The best engineers reach for "can we solve this without new code?" before reaching for the keyboard. This connects directly to the build-vs-buy decision: often the wisest engineering choice is to not build at all, sidestepping the entire maintenance burden. The code you don't write is the code you never have to maintain, debug, or secure.
If code is a liability, then removing it is genuinely valuable work — yet it's chronically undervalued because it doesn't look like production. A pull request that deletes a thousand lines while preserving behavior is a real improvement: less to maintain, fewer places for bugs to hide, a smaller attack surface, a more understandable system. Deleting code reduces liability, which is exactly the goal.
The cultural problem is that engineers are rewarded for adding and rarely for removing, so deletion gets neglected even though it's often the highest-value thing you can do. Treating code as a liability corrects this: a day spent removing unneeded code, collapsing duplication, or simplifying an over-engineered abstraction is a day well spent, not a day without output. The best engineers are as comfortable deleting as adding — sometimes more so — because they understand that a smaller, simpler codebase is a stronger one. Deleting isn't a failure to produce; it's producing the most valuable thing of all: less liability.
The deepest implication is about measurement. Lines of code is a terrible metric because it measures output (liability produced) rather than outcomes (problems solved). An engineer who solves a problem in 50 lines did better work than one who took 500, yet a lines-written metric rewards the worse engineer. Optimizing for output actively encourages the wrong behavior — more code, more liability, worse systems.
What matters is outcomes: problems solved, value delivered, systems kept simple and reliable. The best engineers measure themselves by what they accomplish, not how much they wrote — and frequently accomplish more with less code. This is the same vanity-metrics trap applied to engineering: impressive-looking output (lines, PRs, features) is not the same as real value (problems solved, simplicity maintained). Judge by outcomes, and the incentive to write more code for its own sake disappears — replaced by the goal of solving problems with the least code possible.
Q: How can code be a liability when it's what we build? Because code's value is in the problems it solves, not its existence — and every line carries perpetual cost: maintenance as requirements change, debugging when it breaks, securing against threats, and comprehension by everyone who touches it. That cost never ends. A codebase doing the same job with less code is better — easier to maintain, harder to break, simpler to secure. Seeing code as a liability flips the instinct to add and pushes you to solve problems with as little code as possible.
Q: Is deleting code really valuable if it doesn't add features? Yes — if code is a liability, removing it reduces liability, which is real improvement: less to maintain, fewer places for bugs, a smaller attack surface, a more understandable system. A PR that deletes a thousand lines while preserving behavior is genuinely valuable. Deletion is undervalued only because engineers are rewarded for adding, not removing. The best engineers are as comfortable deleting as adding, because they know a smaller, simpler codebase is a stronger one.
Q: Why is lines of code a bad metric? Because it measures output — liability produced — rather than outcomes — problems solved. An engineer who solves a problem in 50 lines did better work than one who took 500, yet a lines-written metric rewards the worse one and encourages more code, more liability, and worse systems. The right measure is outcomes: value delivered and systems kept simple and reliable. Judge by what's accomplished, not how much was written, and the incentive to write code for its own sake disappears.
The best code is often no code. Every line is a liability — something to maintain, debug, secure, and understand forever — not an asset whose value comes from existing. Once you see code that way, the instinct to add flips: the goal becomes solving problems with the least code possible.
That means asking whether you need to build at all (reuse and simplification beat new code), treating deletion as the valuable work it genuinely is, and measuring outcomes rather than output, since lines of code rewards exactly the wrong behavior. The best engineers solve problems with the least code, not the most — because the code you don't write is the liability you never carry.
No following, no network, no luck. Just an unglamorous system I ran for eighteen months. Here's exactly what I did.
I went from 200 to 11,000 subscribers without hiring anyone. AI didn't write my newsletter — it did everything around it.
I chased big, audacious goals for years and burned out every time. Then I built my whole life around wins so small they felt like cheating.
Comments
Sign in to join the conversation
No comments yet. Be the first to share your thoughts!