The Best Code I Ever Wrote Was the Code I Deleted

Last week I opened a pull request with 1,900 lines removed and 40 lines added. My reviewer left one comment: “Are you sure?”

I wasn’t. I clicked merge anyway.

Nothing broke. The app got faster, the build time dropped, and I felt better than I had after any feature I shipped this year. That’s when I understood something that no tutorial says out loud: every line of code you write is a line someone has to read, test, and maintain. The best code is the code that doesn’t need to exist.

We are taught to add, never to remove

Look at how we learn. Every course, every project, every portfolio is about building something new. Nobody gives you a certificate for removing a feature.

So we grow code like we grow a pile of clothes on a chair. It keeps getting bigger, and we keep saying we will sort it out later. Then one day you can’t find anything, and you are scared to pull a single shirt out in case the whole pile falls.

Dead code is not harmless

I used to think unused code was just sitting there, doing nothing. That’s wrong. Dead code still has a cost.

It shows up in search results when you look for something real. It makes new people ask, “Is this still used?” and then waste an afternoon finding out. It breaks when you update a library, and you spend time fixing something that nobody even calls.

Code you don’t use is not free. It charges rent every single day, and you pay it with attention.

“But what if we need it later?”

This is the sentence that keeps every dead function alive. I said it many times myself.

Here is the truth: you already have a backup. It’s called git. Everything you delete is still in the history, with the date, the author, and the message. You don’t need to keep old code in the file just in case. Commented-out blocks are not a safety net. They are just noise with good intentions.

And if you really do need it in six months, you will probably write something better anyway, because by then you know more.

Features nobody asked for

Some of the code I removed was a feature I was very proud of. It took me two weeks. I checked the logs: three people had used it, and two of them were me testing it.

That hurt a little. But it taught me to ask a question before I build anything: what happens if I don’t build this? If the answer is “nothing much,” I have just saved myself two weeks.

Now it matters even more

These days, code is easy to produce. You can ask an AI tool for a function and get fifty lines in a few seconds. That’s great, but it also means the pile on the chair grows ten times faster.

Writing code was never the hard part. Understanding it was. When code costs nothing to create, the real skill becomes deciding what to keep, what to simplify, and what to remove. Someone has to read all of that, and it might be you, on a bad day.

How to delete without fear

• Delete in small steps, not in one giant change that nobody can review.
• Run your tests before and after. If you have no tests, check the logs to see whether anything is actually called.
• Write a clear commit message that says what you removed and why, so anyone can find it later.
• Ask someone else to look. A second pair of eyes is cheap.

So, are you sure?

My reviewer’s question stayed with me longer than the pull request did. “Are you sure?” is a good question to ask before adding code too, not only before removing it.

Do we need this? Will anyone use it? Can it be simpler? Most of the time, the honest answer is the smaller one.

So this week, open your project and look for one thing that nobody uses. One function, one file, one old feature. Delete it, run the tests, and merge.

I was sure this time. I hope you will be too.