A number came up in a meeting this morning that I haven’t been able to put down. Our product has roughly 200 features. Customers actively use about 20% of them.

Nobody in the room flinched. Everyone has seen some version of this before, usually phrased as the 80/20 rule, or the long tail, or “we should really do an audit someday and remove features”. We nodded, wrote it down, and moved on to the next slide. But the number kept rattling around in my head for the rest of the day, because it quietly implies something uncomfortable: most of what we built, we didn’t need to build, or it was just to one client’s need.

The joke

Later, on Slack, a colleague had set his title to “0.1x Software Engineer.” I asked what it meant. He replied:

-5 LOC / day

If you’ve spent time in tech you’ve heard of the mythical 10x engineer, the person who supposedly ships ten times more than everyone else. A 0.1x engineer is the inversion of that. And “minus five lines of code per day” takes it one step further. His average daily contribution to the codebase is negative. He deletes more than he writes.

It’s a self-deprecating joke. It’s also, I think, accidentally one of the more honest descriptions of senior engineering I’ve come across.

Why deleting is the job

Put the two things side by side. We have 200 features and use 160 of them. We also have a running joke that the best metric for a developer is how much code they remove. Those aren’t unrelated. They’re the same observation told twice.

Every feature we ship is not an asset that sits quietly on a shelf. It’s a standing liability. It has to be maintained, kept compatible, tested, documented, explained to new hires, and supported when it breaks at 2am. A feature that 5% of customers touch still costs the full price of existing. Multiply that by a few hundred and you get a codebase where most of the weight is doing no work.

In that world, the person writing -5 LOC a day isn’t slacking. They’re paying down the interest on everything the rest of us shipped in a hurry. Removing a dead feature, collapsing two half-built ones into a single good one, talking the team out of the flag nobody will ever flip. None of that shows up as output. On a dashboard that counts lines, it looks like the person did nothing. On the actual health of the system, it’s some of the highest-leverage work available.

The metric is the trap

This is why “lines of code” became a punchline in the first place. The moment you reward volume, you get volume: more features, more flags, more clever abstractions nobody asked for, more surface area for the next bug. You optimize the number and degrade the thing the number was supposed to represent.

The 20% usage figure is what that trap looks like after a few years of compounding. Not because anyone was lazy, but because everyone was productive in exactly the way we kept measuring.

What I’m taking from it

I don’t have a tidy framework to offer, and I’m suspicious of anyone who does. But the number changed how I want to spend my own time. The most valuable thing I can do this quarter probably isn’t in the 200. It’s somewhere in the unused 640, waiting to be turned off so the parts people actually rely on can get faster, simpler, and harder to break.

So I’ve made my peace with being a 0.1x engineer on a good week. If the codebase ends the year smaller and the product ends it more used, that’s a trade I’ll take every time.

My colleague, for the record, is shooting for -10x. Deleting bugs while writing features. I told him that was just the senior-engineer tax: every line you don’t write is a line nobody has to debug in prod.