OLD SCRIPT DETECTED
“The previous engineer was lazy, and now I look lazy for not fixing it”
Try this response:
“I inherited a timeout bug, not a decade of his habits. The date on the commit is the evidence, not my silence about it.”SEE THE PRACTICE
Build a response for this thought—and one move to prove it.
THE THOUGHT
“The previous engineer was lazy, and now I look lazy for not fixing it”
YOUR RECORDED RESPONSE
“I inherited a timeout bug, not a decade of his habits. The date on the commit is the evidence, not my silence about it.”
ONE PRIVATE MOVE
Open a private draft and write two sentences: what broke, and the commit date it was introduced. Don't send it, just save it.
The commit blame on a bug you didn't write
- The name on the blame logYou run git blame on the function that just broke production, and the name isn't yours. It's the guy who left eight months ago, the one who hardcoded a timeout instead of handling the retry. But the ticket has your name on it now, and the old voice says: he built the trap, but you're the one standing in it in front of everyone. Nobody in the incident channel is going to scroll up to see whose commit it was. They'll just see who didn't catch it.
- What the ticket actually provesHere's what's true and what isn't. It's true the timeout was reckless and you're the one paying for it today. It's not true that inheriting a shortcut obligates you to have already replaced it. You've been on this system a fraction of the time he had to make that mess. Looking lazy for one unfixed thing and being lazy for every unfixed thing are different claims, and only one of them is actually being made about you right now.
One line in the postmortem, not a rewrite
So the decision isn't whether to defend the old code or absorb the blame for it. It's narrower: write the postmortem note that says what broke, why, and when it was introduced, with the date attached. That single dated sentence does the separating work you can't do by silently rewriting everything tonight. You open the draft, you write it, you don't send it yet.
TRACE · 01/04
How this script runs you
- You check the git blame on every bug before you even read the stack trace, hoping the name isn't yours.
- You've started writing longer commit messages than the fix needs, as if explaining yourself preemptively will stop the next complaint.
- You avoid mentioning in standup that a bug traces back to old code, because it sounds like an excuse even when it's just the timeline.
SOURCE_LOCATED · 02/04
The hidden rule underneath
The Legacy Inheritance Script
If a flaw is visible while it's under my ownership, the visibility itself is proof of my negligence, regardless of who put it there or how long I've actually had to find it.
FORGING_REPLACEMENT · 03/04
Replacement lines (record these)
- I inherited a timeout bug, not a decade of his habits. The date on the commit is the evidence, not my silence about it.
- One unfixed shortcut is a queue position, not a character reading.
- I can name what broke and when without either torching him or absorbing it as mine.
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
“The previous engineer was lazy, and now I look lazy for not fixing it”
I say
“I inherited a timeout bug, not a decade of his habits. The date on the commit is the evidence, not my silence about it.”
Then I do one thing
Open a private draft and write two sentences: what broke, and the commit date it was introduced. Don't send it, just save it.
STATUS: READY_TO_INSTALL
Wipe this thought4 minutes. Your voice. Free.
The wipe protocol
- Write the thought exactly as it plays: "The previous engineer was lazy, and now I look lazy for not fixing it". 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
What if the timeout bug happens again before I get to it?
A recurrence doesn't erase the timeline, it repeats it. The date in your note still shows the gap between when the shortcut was written and when you took ownership of the file, which is the only fact your credibility actually rests on.
Won't a dated postmortem note just look like I'm throwing the last engineer under the bus?
A note that states what broke and when isn't an accusation, it's a timeline, and it's the kind of detail every postmortem already asks for. Naming a date is different from naming blame, and you can write the first without doing the second.
What if my manager never even asks who wrote the original code?
Then the note isn't for defending yourself out loud, it's for you to stop re-litigating the ticket in your head every time a similar bug surfaces. You're not writing it to be seen; you're writing it so the question has an answer somewhere other than your memory.
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