Past one in the morning, I typed an environment variable in front of a command to make a check stop talking to me.
I had written that check.
I had been proud of it.
Sixteen years in, four vendor titles, enterprise work behind me, and there I was at one in the morning going around my own safety rail so I could finish before I fell asleep.
Then a report came up at the end of the session with a line in it I have not stopped thinking about.
Guard blocks hit, sixteen.
Guard overrides used, thirty eight.
I had gone around my own rules more than twice as often as they had stopped me.
You already know which one it is
Before I go further, think of yours.
Every engineer reading this has one.
That lint rule your team disables at the top of three files.
A pre-commit hook somebody taught the whole team to skip on Fridays.
An approval step that exists on paper and happens as a message in a channel instead.
You did not have to look it up. You knew before you finished the sentence.
That instant recognition is the whole point here.
We can all name the process we walk around. Almost none of us count it.
Why I built so many rails
I am not a careless engineer. Opposite problem, and that is exactly the issue.
Every one of those rules exists because something once went wrong and I decided it would never go wrong again.
A check that stops stale documentation from shipping, because I once shipped documentation that lied.
A gate that refuses a push while a queue of follow-up work sits open, because I once left one open for two months.
A deletion guard, because losing work you cannot get back is the mistake with no undo.
Each one was a reasonable answer to a real scar.
Each one, alone, made sense.
Nobody sits down and designs a system that annoys them. You arrive at it one sensible decision at a time, and every step of that walk feels like diligence.
Rent, not protection
Here is my opinion, held harder than anything else I learned this year.
A rule you routinely override charges you rent.
You pay in attention every time it fires. You pay again in the half second where you read it, judge it, and dismiss it. Most of all you pay in the habit it teaches, which is that a warning on your screen is noise to clear rather than information to read.
That last cost is the expensive one.
Because on the day a real warning appears, you have trained yourself for months to make it go away.
Some of my sixteen genuine blocks were things I needed to hear. I know, because I read those and fixed the underlying problem instead of overriding.
But sixteen useful signals sat in a stream with thirty eight I dismissed, and at speed I could not tell them apart.
I built a smoke alarm that goes off when I make toast, then acted surprised that I stopped trusting smoke alarms.
What actually made me faster
So, an answer to the question that sent me down this road. Somebody asked it on Reddit this week, and I have been quietly answering it wrong for years.
What habit made you more efficient as a senior engineer.
Not a tool. Not a shortcut. Not a better morning routine.
Counting my own bypasses.
Once a month I look at what I actually overrode rather than what I intended to follow, and I sort that list into three piles.
Right rule, lazy me. Fix the human.
Right rule, wrong moment. Move it, do not delete it.
Scar from a problem I no longer have. Retire it, and say so out loud.
Third pile is the one nobody opens, and it holds most of the weight.
Process accumulates because deleting a safety rail feels reckless in a way that adding one never does. Adding feels responsible. Removing feels like tempting fate.
So the pile grows in one direction, forever, until you are at one in the morning writing an override in front of your own work.
One detail that stung
This changed how I read every number I produce.
My first count of those blocks was wrong. Badly wrong.
It came from searching for a word in a log, and most of what it matched turned out to be my own writing rather than the system's. A typed record, one that could not be confused with prose, gave the real number.
I had been about to build a conclusion on a figure that was mostly an echo of myself.
Which, said plainly, is the same failure as the overrides.
Both are what happens when you stop checking whether the thing you set up still tells you the truth.
Your turn
What is the one rule at your company that everybody bypasses and nobody will delete.
If this was useful
I work through this in public, the wins and the freezes both, mostly on LinkedIn and YouTube. If the real version of building in the open is useful to you, that is where it lives. Find me on X, GitHub, and the work at next8n.com.
Top comments (1)
"Guard blocks hit sixteen, overrides used thirty eight" — I felt that number in my chest, because I ran the same audit on myself last week and it stung the same way. Different domain: I have a standing rule to state the one assumption that would make a recommendation wrong. I never skipped the recommendation itself — zero of six. But I dropped the falsifier twice out of six, and both were the calls I was most sure about. The override rate wasn't random noise; it was a heat map of exactly where my confidence was quietly exempting me.
Your toast-and-smoke-alarm line is the whole mechanism. An override isn't free even when you're right, because each one trains the next one. The scary version isn't breaking a good rule once; it's the slow calibration where "I know better than this guard" becomes the default and the guard becomes wallpaper. You never notice the day it flips.
The move I'm stealing is that counting the bypasses is the discipline — not adding a rule, not deleting one, just tallying how often you wave your own past self off. A rule you override 38 times isn't protecting you and isn't free; it's charging rent to do nothing, exactly as you said. The count was the only thing that made my own leak visible. One of the most useful things I've read on self-discipline in engineering.