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”.

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. 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.

Resilience Note

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'

Use static tools to find functions that no one calls. If it's not used, it's out.

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. Ensure the output is the same with 200 fewer lines.

Eliminate 'Just-in-case' logic

If you're handling errors that physically cannot happen today, simplify it. Don't program for an imaginary future.

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:

Refactor
ts
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:

g CO₂
Hugo Campañoli
Written by

Hugo Campañoli

Software Architect & Web Performance Specialist. I build high-velocity digital ecosystems that dominate search engines and delight users. Leading content engineering from Itapúa.