I have written a lot of code. Hundreds of thousands of lines across dozens of projects over twenty years. Some of it was clever. Some of it was elegant. Some of it solved hard problems in interesting ways.
The best code I ever wrote was none of that. The best code I ever wrote was the code I deleted.
A function that turned out to be unnecessary. A feature that nobody used. An abstraction that added complexity without adding value. A clever solution to a problem we did not actually have. Each deletion made the codebase better in a way that no addition could match.
Subtraction is underrated. The industry celebrates building. Nobody gets promoted for removing things. But removing the right things is often more valuable than adding the right things.
Every line of code is a liability. It has to be maintained. It has to be understood. It has to be tested. It has bugs you have not found yet. It will break in ways you have not anticipated. It adds cognitive load for everyone who touches the codebase. When you delete code, you eliminate liability. The deleted code cannot break. It does not need maintenance. It does not confuse new developers. It does not have bugs because it does not exist. The ideal codebase is the smallest possible codebase that solves the problem. Every line should earn its place. Every abstraction should justify its existence. Everything else should be deleted.
Some of the best work I have done was identifying features that could be removed. The admin panel that nobody logged into. The export function that nobody used. The settings page with options nobody changed. Removing these features was not just deleting code. It was deleting support burden. It was deleting edge cases. It was deleting the cognitive overhead of maintaining features that served no purpose. Product teams are afraid to remove features because removal feels like regression. It is not. Removing unused features is progress. You are making the product simpler and the codebase smaller and the maintenance burden lighter. That is improvement.
Junior developers under-abstract. They write the same code multiple times and do not notice the pattern. This is a real problem. Senior developers over-abstract. They see patterns everywhere and build abstractions for things that only happen twice. They create frameworks for problems that do not repeat. They generalise prematurely because generalisation feels like engineering. I have done this. I have built beautiful abstractions that handled every possible case, only to discover that only one case actually occurred. The abstraction was dead weight. Deleting it and writing the simple, specific code was an improvement. The best abstractions emerge from repetition. If you have not written the same thing three times, you do not need an abstraction. Write the simple thing. Wait for the pattern to prove itself. Then abstract if you must.
Clever code is a trap. You write something elegant and you are proud of it and you want to keep it because it demonstrates your skill. But clever code has costs. Clever code is hard to understand. Other developers have to stop and figure out what it does. That takes time. Time is expensive. Clever code is hard to modify. When requirements change, the clever solution often needs to be rewritten entirely because it was optimised for the old requirements. Clever code is hard to debug. When something goes wrong, the clever parts are usually where something went wrong. Simplicity is predictable. Cleverness is not. I have deleted code that I was proud of because pride is not a business reason. The clever solution worked but the simple solution would work too, and the simple solution would be cheaper to maintain. Delete the clever. Keep the simple.
Deletion requires confidence. You have to believe that the code is not needed. You have to trust that removing it will not break something. You have to resist the urge to keep it just in case. This is hard. Code represents effort. Someone wrote it. Maybe you wrote it. Deleting it feels like disrespecting that effort. It feels wasteful. But the effort is a sunk cost. It is gone whether you keep the code or not. The only question is whether the code adds value now. If it does not, delete it. The effort is already spent. Do not let that ghost haunt your codebase.
Look at your analytics. What features are not being used? What pages have no traffic? What buttons never get clicked? Look at your tests. What code paths are only exercised by tests, never by real usage? Look at your dependencies. What libraries are you importing for one function? What capabilities are you maintaining but never using? Look at your abstractions. What patterns only occur once? What flexibility are you preserving for futures that never arrived? There is always code to delete. Every codebase has dead weight. Finding it and removing it is some of the most valuable work you can do.
The best code I ever wrote was the code I deleted. Go delete some of yours.