She joined the team and spent her first two weeks reading code.
Not writing code. Reading it. Understanding it. Asking questions that made people uncomfortable, like "What does this do?" and "Does anyone use this?"
Then she started deleting things.
Not small things. Entire modules. Features that had been in the product for years. Code that people had spent months building.
The first reaction was panic. Someone had mass deleted code. This was surely a mistake. But the tests still passed. The product still worked. Users didn't notice.
It turned out that most of what she deleted wasn't being used. Some of it had never been used. Some of it had been used once, years ago, and then forgotten. Some of it was half-finished experiments that nobody had the heart to remove.
The codebase got smaller. Builds got faster. New engineers stopped asking about mysterious folders that nobody could explain.
This was the most valuable thing anyone did that quarter.
We don't celebrate deletion. We celebrate creation. Lines of code added, features shipped, systems built. Deletion feels like failure — an admission that something shouldn't have existed in the first place.
But code has a carrying cost. Every line is something that might break, something that needs to be understood, something that slows down everyone who comes after. The more code you have, the harder everything becomes.
Junior engineers add code. Senior engineers remove it. This is an oversimplification, but it's not entirely wrong.
The hard part isn't the deletion itself. It's having the confidence to delete. Knowing that something isn't needed requires understanding the whole system. It requires talking to people, reading logs, tracing dependencies. It requires being willing to be wrong.
Most people aren't willing to be wrong. So they leave the code alone, just in case. And the codebase grows, and grows, and eventually nobody understands it anymore.
She left after a year. The codebase was half the size it had been when she arrived. The team was faster. The product was simpler.
Nobody gave her an award for it. There's no metric for "code removed" in most performance reviews. But everyone who worked with her remembered what she did.
Sometimes the most important work is making things smaller.