Knowing when to start again

The specific failure that costs the most time

It is wrong. You correct it. It is wrong in the same way. You correct it more forcefully. It apologises and produces a third version with the same flaw.

Twenty minutes have gone. Twenty more will go, because the mechanism that produced the first two answers is still in place and has now been reinforced twice.

The rule: wrong twice in the same way means start over. Not correct harder. Start over.

Why arguing does not work

Everything in the conversation shapes what comes next. That is the entire mechanism: the response is conditioned on the whole exchange, including the two wrong answers and your two corrections.

So a conversation that has gone wrong is not neutral ground you are steering from. It is a context that now contains three statements of the wrong approach and a couple of hedged retractions, and the next answer is generated in the presence of all of it. The wrong framing has more textual weight than your correction does.

The practical consequence is that a fresh start with better framing is cheaper than the third correction, almost always, and it does not feel that way, which is why people keep making the third correction.

Restarting well

A restart is not repeating yourself. It is asking the better question you can now ask, because the failed attempt taught you something.

Carry four things forward:

1. The constraint you discovered. “This must not add a dependency.” “The Invoice.total() signature is public and cannot change.”
2. The file you forgot to include. Usually the actual cause. The thing it kept getting wrong was defined somewhere it could not see.
3. The approach that is ruled out, and why. “Do not use the retry decorator; this endpoint is not idempotent.”
4. A smaller scope. If the whole task failed twice, ask for the first third of it.

Write convert(amount: Decimal, from_ccy: str, to_ccy: str, at: datetime)
-> Decimal in billing/fx.py. Rates come from RateProvider (attached).
No new dependencies. Do not change any other file. On a missing rate,
raise RateUnavailable — do not return None and do not fall back to 1.0.
If you think another file needs to change, stop and say so.

Everything learned from the failed attempt is in those five lines, and they took forty seconds to write.

The sunk cost, named

People persist because the first two attempts were so close. Ninety per cent right, one stubborn detail wrong. Abandoning that feels like discarding value.

There is no value to discard. The conversation is not an asset; the code either works or it does not, and a nearly-working answer that has resisted two corrections is evidence about the framing rather than about the distance remaining. The closeness is exactly what makes the trap work.

A hard time-box helps more than resolve: ten minutes, or two corrections, whichever comes first. Then stop, close it, and write the better request. Making it a rule removes it from the domain of judgement, which is useful because judgement is the thing that is compromised at minute nineteen.

When to stop entirely rather than restart

Sometimes the third attempt is not the answer either, and the signal is worth recognising.

If you cannot write a clear request, the problem is not the tooling. It is that you do not yet know what you want, and no amount of rephrasing will fix that. Go and find out: read the code, ask the person who requested it, run something, draw the data model.

And occasionally the honest answer is that this task is not one to delegate. Twenty minutes of failure is decent evidence that the work is judgement-heavy, and judgement-heavy work is the category to do yourself. In that case the twenty minutes were not wasted: they told you something about the task that you did not know at the start.

The wider version of the rule

This is a specific case of something older. Any loop where you are correcting rather than converging is a loop to exit.

The same applies to a debugging session that has produced four theories and no reproduction, a design discussion in its second hour, and a merge conflict you have resolved twice. Stop, go back to the last known-good state, and re-approach with what you now know. The instinct to push on because you are nearly there is the most reliably expensive instinct in software.