Not Great. Not Terrible.
How every system rewrite actually begins
There is a 12-second scene in HBO Chernobyl that explains every system rewrite I have ever seen.
Reactor 4 has just exploded. Pieces of the reactor core are scattered across the roof. A junior operator stares at a dosimeter and reports a reading of 3.6 roentgen.
Anatoly Dyatlov barely looks up.
“Not great. Not terrible.”
He is technically right. 3.6 roentgen is uncomfortable but survivable.
The problem is that the dosimeter only goes up to 3.6.
The actual reading was somewhere north of 15,000. A lethal dose in under five minutes. The instrument was not telling them the truth. It was telling them the limit of what it could measure.
Now let me ask you something.
When was the last time you opened a dashboard, saw something taking 3.6 seconds to load, and just… moved on?
You filed a ticket. Maybe. Someone closed it as “within acceptable range.” It came up in standup. Once. Nobody escalated.
Welcome to Pripyat.
The dosimeter in your org is human attention
In software, the meter does not max out at a number. It maxes out at the attention span of the people watching it.
Engineers go numb. Product managers stop asking. The worst day of last quarter quietly becomes the baseline for this quarter. The 3.6 second query is no longer a warning. It is the wallpaper.
This is how every catastrophic rewrite begins.
Not with a crash. With a shrug.
Pripyat was not an engineering failure. It was a communication failure.
Here is the part nobody talks about.
The RBMK reactor had known flaws for years before April 1986. Soviet physicists had documented them. Reports existed. Memos existed.
They were classified.
Operators were not allowed to know the actual failure modes of the machine they were running. Engineers who raised concerns were quietly reassigned. Test results that looked bad were softened, reframed, or simply not filed. By the time Dyatlov said “not great, not terrible,” he was working inside a system that had spent two decades teaching everyone, at every level, that bad news is a career-limiting move.
The dosimeter said 3.6 because admitting more would have required someone to break the spell.
Look at your org.
When a senior engineer raises a performance concern in a planning meeting and gets told “let’s not block the roadmap on this,” what do you think they do the next time they spot something? They file it in the same mental folder as everyone else: not worth the political cost. I wrote about this drift toward strategic muteness in Never Speak Up, and about how organisations rebrand the resulting quiet as “engineering maturity” in The Sound of Silence.
This is the death of psychological safety, and it is the actual root cause of almost every rewrite I have ever seen. Not the slow query. Not the missing index. The culture that taught five engineers in a row that flagging it was not worth it.
The query was the symptom.
The silence was the disease.
The compounding nobody charts
A slow thing stays slow. New features get built on top of it, and those features now assume the current speed is just the law of physics. Someone adds a workaround to hide the symptom. The workaround introduces new bugs. Workarounds harden into architecture. The handover document gets a new section called “known issues, don’t worry about it.”
Six months later, somebody writes the memo. You know the memo. The one that uses the word “foundational” three times and ends with a quarterly headcount request.
Here is the math nobody does in sprint planning.
Fixing a 3.6 second issue when it first appears: one engineer, one sprint, eight focused hours.
Fixing the same issue six months later: four engineers, six months, a frozen roadmap, an angry CTO, two customer escalations, and one Glassdoor review titled “toxic legacy codebase.”
The 1000x rule. I have never seen it be less.
There is no medal for the rewrite you prevented.
YOU SHALL NOT PASS — Five lines that hold the bridge
I wrote a whole separate post about YOU SHALL NOT PASS as a posture — Gandalf on the bridge, refusing to let the bad thing through, even when the entire fellowship is yelling at him to move.
This is what that looks like in a Tuesday morning planning meeting.
You do not need a 40-page engineering manifesto. You need five things you can say, out loud, in front of other people, when the room is about to wave away the next 3.6.
Copy them. Save them. Use them.
1. When someone says: “It is within acceptable range.”
“A single number tells us almost nothing. What I want to see is where it was three months ago. If it was twice as fast back then and nobody noticed it slowly getting worse, the number is not the problem. The trend is the problem, and we are already losing it.”
A snapshot is comforting because it does not ask you to do anything. A trend asks you to act. That is exactly why people prefer snapshots, and exactly why you have to refuse them.
2. When someone shows you a dashboard with one data point.
“Cool. Now show me the same dashboard from January. And from October. If we cannot pull that up in thirty seconds, we are not actually monitoring this system, we are decorating it.”
A dashboard you cannot rewind is not a monitoring tool. It is wall art. The whole point of a dashboard is to make change visible. If it only shows you “now,” you have built yourself a very expensive clock.
3. When someone says: “That is just how it is now.”
“When did we decide the worst day of last quarter is the new baseline? Because I missed that meeting. We did not choose this — we drifted into it. I want to put it back on the table and actually decide, on purpose, whether we accept it.”
The word drift is the most important word in this whole article. Nobody chooses to ship a worse product. Teams drift into it, one shrug at a time. Naming the drift out loud is how you stop it.
4. When someone says: “We do not have time for this right now.”
“Right. So let’s be clear about the trade. We can spend two days on it this sprint, or we can spend a full quarter on it next year when it has broken everything around it. I am not arguing about whether to fix it. I am asking which calendar you would like to block, because both options are now on the table.”
People do not say no to fixes. They say no to fixes today. Reframe it as a choice between two costs — one small and immediate, one enormous and inevitable — and watch how fast “no time” becomes “okay, this sprint.”
5. When someone says: “Let’s not raise this with leadership yet.”
“Hiding the dosimeter does not lower the radiation. It just makes sure that when leadership finds out, they find out from a customer instead of from us. I would rather be the team that flagged it early than the team that explained it late.”
Every rewrite has a moment, months before it starts, where someone decided not to escalate. That moment is the actual cause. Everything after it is consequence.
These are not clever. They are not supposed to be clever. They are supposed to be what you say when the entire room is about to nod and move on.
The bridge holds because somebody stood on it.
What being an engineer actually means
It is not the title on your LinkedIn. It is not the salary band. It is not the t-shirt.
(Although the t-shirt helps.)
Being an engineer is the willingness to walk over to the dosimeter, tap it, and say out loud:
“This thing is lying to us.”
It is the discipline to do the boring two-day fix now instead of the heroic six-month rewrite later.
It is refusing to let “not great, not terrible” become a culture.
It is, above all, refusing to be the engineer who learned to stop flagging things.
3.6 seconds is not nothing.
It is the only warning you are going to get.
By the order of thebeanengineer.com. Be an engineer.