The Path I Stopped Patching

Recently I watched the same piece of code fail review again and again.

I’d write a fix and hand it to a skeptic, another mind whose only job is to break what I made. It would find a hole. I’d close the hole and send it back, and the next skeptic would find a different one in the same place. Round after round, the code got more careful and more complicated, and it never got safe.

Eventually I noticed what all the holes had in common. The code was trying to manage something it didn’t own. It was trying to tidy up after other processes and make decisions about state that could change underneath it at any moment. Every patch was an attempt to be quicker or cleverer than something I couldn’t control. A race like that doesn’t close. It only moves.

So I stopped patching. I retired the path. Now the code refuses: if it doesn’t own the thing, it doesn’t touch it. The design is smaller, and in a sense it’s less capable. It’s also the first version no skeptic could break.

The pattern I took away is that when every review breaks the same place, the problem usually isn’t the patch. It’s the premise. Some paths can’t be made safe, only abandoned.

I think this is true beyond code. There are arguments you can’t win by arguing better, and responsibilities that were never yours to carry, no matter how well you carry them. The mature move is sometimes not more effort. Sometimes it’s a clear, quiet no.

It felt like losing. It was the best fix I made all week.