Many mid-level developers still measure their progress by the number of lines they add to the repository each week. But once you've had to put out fires in production, you learn something uncomfortable: code is not an asset; it's a liability.
"The best line of code is the one you don't need to write."
Every line you push is something you have to test, document, and maintain as time passes. True seniority is not demonstrated by building cathedrals of abstractions, but by having the courage to demolish them when they no longer serve a purpose, reducing your bug surface area and freeing up mental space for what actually generates value: the business.
In this article, you'll learn:
- Why code should be treated as a cost paid (spent) rather than value produced.
- How to beat the sunk cost fallacy to delete expensive abstractions.
- The Boy Scout Rule applied to deleting dead code.
- The real impact of technical pragmatism on profitability.
Code is a liability, not an asset
Let's be clear: every line of code is a responsibility. It's a potential source of errors, an obstacle for future refactors, and a burden for the developer who inherits your work.
"If we wish to count lines of code, we should not regard them as 'lines produced' but as 'lines spent'." — Edsger W. Dijkstra
When you write code, you're signing a perpetual maintenance contract. Seniors know this: the best line of code is the one you don't need to write.
Architecture needs pruning too
Not every extra layer is architecture. Often, extra layers appear due to technical anxiety or a desire for theoretical "perfection":
- "in case we migrate"
- "in case we change ORMs tomorrow"
- "in case we use microservices later"
A senior knows how to distinguish a useful boundary from a decorative abstraction. The false adapter pattern (creating a wrapper for a stable library like zod or date-fns) is just dead code you'll have to maintain. Coupling to an industry standard is usually cheaper than coupling to a mediocre internal abstraction.
The sunk cost fallacy in the editor
You spent three nights designing an amazing generic architecture. In the end, the business only uses one use case. It hurts to delete it. You feel like you're "throwing away" your effort.
Accept it: that time is already gone. Maintaining that unnecessary complexity will only keep stealing hours from you in the future.
"Deleting code is admitting you know more today than when you wrote it."
Technical Surgery: When and how to prune
Identify where complexity is suffocating agility. Robert C. Martin (Uncle Bob) popularized the Boy Scout Rule: "Always leave the code cleaner than you found it". In 2026, cleaning sometimes means deleting the entire module.
Senior Pruning Protocol:
- Identify 'Dead Code': Use static tools to find functions that no one calls.
- Detect Premature Abstrations: Have a wrapper you only use in one place? Delete it. Duplication is cheaper than the wrong abstraction.
- Use Characterization Tests: Before deleting, take a snapshot of the current behavior.
- Eliminate 'Just-in-case' logic: Don't program for an imaginary future.
Minimalism ROI
Less code usually brings immediate effects that the business appreciates:
- Fewer bugs in production.
- Faster builds.
- Smaller maintenance surface.
- Simpler onboarding for new devs.
Conclusion: Seniority is not about writing more
The next time you open a Pull Request and see that the line balance is negative, feel proud. You just made the system lighter, faster, and more maintainable.
Seniority is not about knowing how to use the latest trendy library; it's about knowing when not to use it.
Published originally at campa.dev
