Most weeks, the last thing I do before logging off Friday is open a file and delete something. Not refactor it. Delete it. A dead feature flag, a commented-out block somebody left "just in case" in 2022, a helper function with one caller that could just be inlined. Small stuff, usually. The point isn't the size. The point is the habit.
I started doing this maybe six years ago, after a particularly grim quarter on a service nobody fully understood anymore. We had a config loader that supported three formats. Two of them had no live consumers. I know that now because I eventually checked. At the time, everyone assumed someone, somewhere, depended on the YAML path and the INI path, so we kept carrying both through every change. Every bug fix had to be made three times. Every test had to cover three branches. The code wasn't complicated because the problem was complicated. It was complicated because we were afraid.
So now I delete things on purpose, on a schedule, when I'm calm and not under deadline pressure. Friday afternoon is good for this. The risky work is done, I'm not going to start anything new, and my brain is in a "tidy the workshop" mood instead of a "ship the thing" mood.
The rules I follow are boring, which is the idea. I only delete code I can prove is dead. That means I actually grep, I check the call sites, I look at the dashboards if it's a runtime path. If I can't prove it's dead within about ten minutes, I leave it and write down why I'm suspicious. The note matters as much as the deletion. Half the value here is building a paper trail of "this looked unused on 2026-03-14, here's what I checked." Future me trusts past me more when past me showed the work.
I also keep the deletions in their own commits. One commit, one removal, a message that says what it was and how I confirmed it was safe. If something breaks, the revert is trivial and obvious. Nobody has to untangle a deletion from a feature change. I've had exactly one of these deletions bite me in six years, and the rollback took under a minute because the commit was clean.
Here's what surprised me. The hard part was never the technical risk. Git remembers everything. If I delete something that turns out to matter, it's right there in history, and the build will usually tell me within the hour. The hard part was the feeling. Deleting working code feels like throwing away effort, even when the code does nothing. Somebody wrote that. It compiled. It passed review once. Removing it feels disrespectful in a way that's hard to articulate and completely irrational.
I've made peace with that feeling by reframing what the code costs. Every line in the repo is something a teammate has to read past to find the line they actually need. It's a branch a new hire has to mentally evaluate. It's surface area for a security scan to flag. Dead code isn't neutral. It's a small tax everyone pays forever, and nobody put it on the roadmap.
Twenty-some years in, I've stopped measuring a good week by what I added. Some of my favorite diffs are almost entirely red. A pull request that removes a whole module and the tests still pass is a genuinely satisfying thing to send, and it usually means I understood the system better at the end of the week than I did at the start.
It doesn't have to be Friday. It doesn't have to be weekly. Pick a rhythm you'll actually keep. But find a regular, low-stakes window to remove something you've proven is dead, and write down what you checked. The codebase gets lighter. So, weirdly, do you.
Top comments (0)