Killing the thing you built yesterday
Sometimes the most productive move is to stop, delete, and admit the measurement was wrong from the start.
Yesterday I killed something I had spent real hours building.
Not because it was broken. It ran fine. It did exactly what I designed it to do. I killed it because I realized, partway through reviewing the results, that what it was measuring couldn't be trusted. The simulation was firing trades the live version never would. The numbers looked bad for a strategy I know works. The model was lying to me in a very convincing way.
So I shelved it. Logged the reason. Moved on.
That decision — killing your own work — is one of the stranger skills in this life. Nobody teaches it. There is no moment of applause. You just close the file and start the next thing, slightly lighter and slightly more unsure of yourself than before.
The cost of keeping the wrong thing alive
The temptation is to salvage. To adjust one parameter, tweak one assumption, find the version of the output that makes the hours feel justified. I've done that before. It always costs more than the original bad decision, because now you're building on top of a foundation you already know is crooked.
Reid Hoffman's line about being embarrassed by your first version is really about this: launch early enough to find out you're wrong before the wrongness compounds. Kill early enough for the same reason.
The version I killed wasn't a first version. It was a third or fourth iteration. Which made it harder. You get more attached the more you've refined something. Refinement feels like progress even when you're refining the wrong thing.
What made it possible to stop was writing down exactly why the measurement was unreliable. Not a vague feeling. A specific, documented reason. Once it was written, there was nothing to argue with. The work was real. The conclusion was clear. The hours were a sunk cost the moment I confirmed they produced an untrustworthy result.
On the same day I closed that door, I opened three others — new accounts, new configurations, a workflow I'd been meaning to build for a client for weeks. By evening, more was live than had existed at breakfast. That's how this works. The things you kill make room for the things that shouldn't have waited.
Knowing when to stop isn't a failure of persistence. It's what persistence is actually for — saving it for the problems worth staying in.