Why My Cleanest Code Came After I Deleted 40% of It

I didn’t become a better developer by writing more code. I became one by finally having the courage to delete it.

Created on Copilot

I still remember the PR comment that did it.

Not a long rant. Not an angry essay. Just one line from a senior engineer I respected

“This works. But why is it so complicated?”

That question annoyed me more than a straight-up rejection.

Because the code did work. All tests passed. Edge cases handled. Configs flexible. Abstractions everywhere.

And yet… something felt off.

So I did something that felt illegal as a software engineer.

I started deleting code. A lot of it.

By the end, almost 40% was gone.

And what remained was the cleanest, calmest, most readable code I had written in years.

This article is about that moment — and the uncomfortable lessons that followed.

The Lie We’re All Taught: More Code = More Skill

Let’s be honest.

Most of us learned to equate volume with value.

• More abstractions = smarter
• More layers = scalable
• More flexibility = future-proof
• More code = more “engineering”

It feels productive. It looks impressive in PRs. It makes us feel like real developers.

But here’s the uncomfortable truth I learned the hard way

Complexity is often just insecurity wearing a hoodie.

We don’t over-engineer because the system needs it. We over-engineer because we do.

We’re trying to

• Prove we know patterns
• Anticipate imaginary futures
• Impress reviewers
• Protect ourselves from “what if”

And the code pays the price.

When “Clean” Code Is Actually Just Polite Chaos

Before deleting anything, I had what many would call “clean code”

• Small functions
• Descriptive names
• Multiple interfaces
• Dependency injection everywhere
• Config-driven behaviour

On paper? Beautiful.

In reality?

• You needed 6 files open to understand one feature
• Logic jumped across layers for no reason
• Debugging felt like detective work
• New devs were scared to touch it

It was clean in isolation. Messy in experience.

That’s when it clicked

Clean code isn’t about how it looks. It’s about how it feels to work with.

The Moment I Started Deleting

I asked myself one brutal question

“If I were new to this codebase, what would confuse me first?”

Then I deleted whatever caused that confusion.

No mercy.

• Unused abstractions → gone
• Config options used once → inlined
• Helper functions called twice → merged
• “Just in case” logic → deleted
• Layers that only forwarded calls → removed

Every delete felt wrong at first. Then… freeing.

The code got shorter. The intent got louder. The behavior got clearer.

Nothing broke.

That was terrifying.

Reality Check: Code Is a Liability, Not an Asset

This is the mental shift that changed everything for me.

We treat code like an asset. But in real life?

Every line of code is a liability.

It has to be

• Read
• Understood
• Tested
• Maintained
• Debugged
• Refactored
• Explained in standups

The best code isn’t the most clever. It’s the least you can get away with.

As Rich Hickey famously said

“Simple is better than easy.”

Deleting code is one of the highest-leverage engineering moves you can make.

The 5 Rules I Now Follow Ruthlessly

1. If You Can’t Explain It in One Breath, It’s Too Complex

If a function needs a diagram or a paragraph to explain, it’s doing too much.

Split behaviour — not for elegance — but for clarity.

2. Don’t Abstract Until the Duplication Hurts

Two similar pieces of code are not a pattern. They’re an observation.

Wait until the pain is real. Not theoretical.

3. Readability Beats Reusability (Most of the Time)

Reusable code that no one understands isn’t reusable.

Write for the next human. Not the hypothetical future.

4. Configuration Is Not Free

Every config option is a decision someone must understand.

If it only ever has one value — hardcode it.

5. If Deleting It Doesn’t Break Anything, It Wasn’t Needed

This is the scariest test. And the most honest one.

A Small Example (That Says Everything)

Before

function processUser(user, options) {
  if (!options) options = getDefaultOptions();
  return userProcessorFactory(options)
    .withValidation()
    .withLogging()
    .process(user);
}

After deleting “cleverness”

function processUser(user) {
  validateUser(user);
  logUserAction(user);
  return saveUser(user);
}

Same behavior. Half the cognitive load. Zero factory gymnastics.

Which one would you rather debug at 3pm on a Tuesday?

Exactly.

Why This Made Me a Better Engineer (Not a Lazy One)

Deleting code doesn’t mean you care less.

It means

• You respect future maintainers
• You value clarity over ego
• You optimize for understanding, not applause
• You know complexity has a cost

The best engineers I’ve worked with don’t write more code.

They write less, and make it obvious.

The Quiet Confidence of Simple Code

Here’s the weird part.

After deleting that 40%, no one praised me for “smart architecture”.

Instead, I got comments like

• “This is easy to follow”
• “Nice, this makes sense”
• “Thanks, I can work with this”

That’s real respect.

Not from cleverness. From restraint.

Finally,

Next time you feel proud of a large PR, pause.

Ask yourself

• What could I delete?
• What am I keeping just to feel safe?
• What would confuse someone new?

Then try removing 10%.

If nothing breaks… remove more.

You might just write the best code of your career by pressing Delete.

If this hit a nerve, clap. If you disagree, argue with me in the comments. If it helped, share it with that teammate who loves “clever” abstractions a little too much.

And maybe save this for the next time your code feels… heavier than it should.