OLD SCRIPT DETECTED
“I'm not maintaining it, I'm just enabling it by not rewriting”
Try this response:
“A guard clause closes a ticket. It doesn't cast a vote on the whole file.”SEE THE PRACTICE
Build a response for this thought—and one move to prove it.
THE THOUGHT
“I'm not maintaining it, I'm just enabling it by not rewriting”
YOUR RECORDED RESPONSE
“A guard clause closes a ticket. It doesn't cast a vote on the whole file.”
ONE PRIVATE MOVE
Pick one patch you've made to old code and write two lines: what the ticket asked for, and what a full rewrite would have required. Keep it for yourself.
The Patch That Feels Like A Cover-Up
- 01 / The Function You Wrap Instead Of Replace
A null pointer crash traces back to a function with no tests, three responsibilities, and a name that doesn't match what it does anymore. Fixing the crash takes four lines: a guard clause before the bad call. You write them, then stare at the rest of the function, because leaving it standing feels like you just voted for it to stay.
- 02 / Calling It Enabling So It Feels Like A Decision
The thought arrives as a verdict: I'm not maintaining it, I'm just enabling it by not rewriting. So the guard clause turns into a comment explaining why a rewrite is overdue, then a Slack message flagging the whole module for later, then a mental tally of every patch you've applied without tearing the thing out. Naming it enabling gives you the feeling of having taken a stance, which is relief, but the stance never leaves your head, so the function ships unguarded against nothing but your own reread, and the next crash finds the same shape waiting.
- 03 / The Line Between The Patch And The Verdict
The interrupt is the moment right after the fix works, when your attention wants to jump from what the ticket needed to what the whole file deserves. Notice that jump and ask one question: did this crash require a rewrite, or four lines and a guard clause? If the ticket is closed, the verdict about the file can wait for a ticket that's actually about the file.
TRACE · 01/04
How this script runs you
- You add a comment above a working patch explaining that the real fix would be a rewrite, on tickets that never asked for one.
- Applying a small fix to old code leaves you drafting a mental case for why you're not responsible for its condition.
- You keep an informal tally of how many patches you've made to a file as evidence you should have rewritten it by now.
SOURCE_LOCATED · 02/04
The hidden rule underneath
The Legacy Inheritance Script
If I touch a flawed system without overhauling it, my patch is proof I chose to let the flaw continue, so every fix that isn't a rewrite counts against me.
FORGING_REPLACEMENT · 03/04
Replacement lines (record these)
- A guard clause closes a ticket. It doesn't cast a vote on the whole file.
- Patching what's broken today isn't the same as endorsing how it was built.
- The rewrite question and the crash question are different tickets.
Generated per person in the app — these are the flavor, not your script. Yours is built from your exact words.
INSTALL · 04/04
The protocol, on one card
When I think
“I'm not maintaining it, I'm just enabling it by not rewriting”
I say
“A guard clause closes a ticket. It doesn't cast a vote on the whole file.”
Then I do one thing
Pick one patch you've made to old code and write two lines: what the ticket asked for, and what a full rewrite would have required. Keep it for yourself.
STATUS: READY_TO_INSTALL
Wipe this thought4 minutes. Your voice. Free.
The wipe protocol
- Write the thought exactly as it plays: "I'm not maintaining it, I'm just enabling it by not rewriting". Word for word — the wipe targets the sentence, not the vibe.
- Trace the rule and the avoided action. What does this thought conveniently excuse you from doing?
- Record the replacement lines below in your own voice. Speak like you mean it — no recording, no install.
- Run the loop: play it every morning and night, log one proof action a day for 7 days.
Straight answers
If I keep patching the same file every few weeks, doesn't that prove a rewrite is actually needed?
Repeated patches to one file are useful signal for a scoping conversation about that file. What they don't prove is that each individual patch was wrong to make, or that you personally are responsible for the file not having been rewritten yet.
How is writing a guard clause different from choosing to let bad code stay in production?
A guard clause responds to a specific crash with a specific input. Leaving code unrewritten is a much larger decision involving scope, priority, and often people above your ticket queue. Treating the small fix as equivalent to the large decision is what makes the patch feel heavier than it is.
Should I stop mentioning that a rewrite would help, even when it's true?
No, flagging it once where it's visible to whoever prioritizes work is useful. The pattern to watch for is repeating that flag inside every unrelated patch as a way of pre-emptively distancing yourself from code you're actively required to touch.
Related old scripts
Related self-checks
Related science
Researchers to explore
Related mechanisms
The research behind this script
- Postmortem Culture: Learning from Failure — Google SRE, Google SRE Book, 2016
- Invisible Labor in Open Source Software Ecosystems — Champion et al., arXiv, 2024
- Stack Overflow 2025 Developer Survey: Trust in AI at an All-Time Low — Stack Overflow, 2025
- A Mosaic of Perspectives: Understanding Ownership in Software Engineering — arXiv, 2025