OLD SCRIPT DETECTED
“Changing the spec means my work was worthless”
Try this response:
“The new spec changed the target, not my effort.”SEE THE PRACTICE
Build a response for this thought—and one move to prove it.
THE THOUGHT
“Changing the spec means my work was worthless”
YOUR RECORDED RESPONSE
“The new spec changed the target, not my effort.”
ONE PRIVATE MOVE
Open a recent spec, ticket, or notes file and highlight one sentence, diagram, or assumption that was useful even though the direction changed. Add a one-word label beside it: 'reused' or 'learned.'
When the brief moves
The margin note lands
You are halfway through a tidy implementation when the spec changes in a comment thread, a fresh ticket, or a sentence in a stand-up recap. The old plan is still open on one screen. Your cursor pauses. Before you even read the details, the thought arrives: Changing the spec means my work was worthless. The room is quiet, but your stomach acts like something has been revoked.
You start defending the old version
After that, you stop treating the new requirement as information and start treating it as a verdict. You keep the obsolete branch around longer than it needs to exist. You avoid trimming the dead bits because deleting them feels like admitting the hours were nothing. The result is ordinary and costly: cluttered notes, delayed cleanup, and a strange loyalty to code that no longer matches reality.
The receipt is the rewrite log
Open the diff, the ticket history, or your own notes and look for the place where the change became useful. Then mark one line, block, or small decision from the old spec as 'reused,' 'saved for later,' or 'not needed.' If you can name even one piece that still helped the project converge, the thought was overreaching. The work was not worthless; it was part of getting to the version that mattered.
TRACE · 01/04
How this script runs you
- A spec update feels less like clarification and more like someone crossed out your effort with a pen.
- You keep old code, old notes, or old assumptions alive because deleting them feels like erasing proof that you worked.
- You count your value by how much of the first draft survives, even when the real job is adapting to a better direction.
SOURCE_LOCATED · 02/04
The hidden rule underneath
The Obsolescence Compiler
If the plan changes, the earlier version must have been pointless, and I should protect it so the time I spent still counts as something.
FORGING_REPLACEMENT · 03/04
Replacement lines (record these)
- The new spec changed the target, not my effort.
- I can discard a draft without discarding the work that produced it.
- A revised requirement means we found a better fit, not that the first pass was fake.
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
“Changing the spec means my work was worthless”
I say
“The new spec changed the target, not my effort.”
Then I do one thing
Open a recent spec, ticket, or notes file and highlight one sentence, diagram, or assumption that was useful even though the direction changed. Add a one-word label beside it: 'reused' or 'learned.'
STATUS: READY_TO_INSTALL
Wipe this thought4 minutes. Your voice. Free.
The wipe protocol
- Write the thought exactly as it plays: "Changing the spec means my work was worthless". 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
Why does a simple requirement change feel personal?
Because this thought turns revision into a verdict. The mind stops at 'different' and translates it into 'wasted.' That makes a normal adjustment feel like a judgment on your effort instead of a routine part of getting the work aligned.
What if most of the first version really was thrown away?
Even then, 'thrown away' is not the same as 'worthless.' Drafts, partial implementations, and abandoned assumptions often show what doesn't fit faster than a perfect guess would have. The useful part may be the decision it made easier.
How is this different from being annoyed that the goal changed?
Annoyance says the change is inconvenient. This thought says the earlier work erased your value. The difference matters: one lets you edit and move on, while the other pushes you to defend the old spec as if it were proof of you.
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