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.
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”.
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. This mindset clashes with the “feature factory” culture, but if you’re the one answering for the system on a Sunday afternoon, you value simplicity over the “beauty” of a complex architecture.
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.
As someone who has to manage their “Chair-Time” with surgical precision, I learned that I can’t afford to maintain useless code. If something doesn’t serve the mission, it gets deleted. Time is the scarcest resource; don’t waste it maintaining monuments to the technical ego.
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. Every time you touch that area, you’ll have to remember how that abstraction worked just to avoid breaking cases that will never exist.
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.
Here is the protocol to identify what’s time to take out with the scissors:
Senior Pruning Protocol
Identify 'Dead Code'
Detect Premature Abstrations
Use Characterization Tests
Eliminate 'Just-in-case' logic
Real-world example: Simplifying validations#
Sometimes the best refactor is replacing 50 lines of manual logic with a standard tool. As we saw in my post on Astro 6 and SEO Enterprise, data validation is key to system integrity.
Look at this change:
function validateUser(data: any) {
if (!data.email || typeof data.email !== 'string') return false;
if (!data.age || data.age < 18) return false;
if (data.role && !['admin', 'user'].includes(data.role)) return false;
// ... 20 more lines of manual ifs
return true;
}const UserSchema = z.object({
email: z.string().email(),
age: z.number().min(18),
role: z.enum(['admin', 'user']).optional()
});
const validateUser = (data: any) => UserSchema.safeParse(data).success;Minimalism ROI and the cost of reading#
Uncle Bob also points out that we spend ten times more time reading code than writing it. If your codebase is bloated, you’re multiplying the cost of every future feature by ten. Less code usually brings immediate effects:
- Fewer bugs in production.
- Faster builds.
- Smaller maintenance surface.
- Simpler onboarding for new devs.
- More speed to deliver real changes.
Deleting code is also an ethical decision. Every CPU cycle we save by eliminating unnecessary JS contributes to sustainability. As discussed in my post on Green Web in Itapúa, efficiency is a form of respect.
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. It’s about having the judgment to delete what no longer serves and understanding that elegance is not in what you can add, but in what you can no longer take away.
Accept it: deleting is evolving.
Need to recover your team's speed?
Specialty: Architecture & Refactoring Consulting
I help you:
