skip to content

How long do you let one red-green-refactor cycle run before discarding the edit and returning to the last green commit?

level: seniorimportance: nice to knowfreq 24%

answer

  1. A state, not a stopwatch
  2. Guessing has replaced predicting
  3. Cheap only if green is minutes old
  4. Keep the test, shed the tangle
  5. First ask whether the red is yours

basics

~10 s

Minutes, not hours. Once you are debugging your own uncommitted edit and can no longer say which change caused which failure, discard it, return to the last green commit, and restart smaller.

solid answer

~50 s

The cycle is meant to run in minutes, so the useful trigger is not a stopwatch but a state: you are red, you have made several speculative edits, and you can no longer explain which one caused the current failure. At that point the edit has stopped being driven and has become a debugging session on unversioned work, which is the most expensive kind. Discarding is cheap precisely because you commit on every green, so the discard target is minutes old — and you keep the test and the understanding, which is most of what the attempt produced. Restart with a smaller bite. The habit has a named extreme, `test && commit || revert`, which automates the discard on every failing run. The exception is a red caused by something outside your edit, where reverting fixes nothing.

code

pseudocode · 5 lines
pseudocode
on every save:
    if runTests() == PASS:
        commit("wip")
    else:
        discardWorkingChanges()

go deeper

for a junior

Recall that the cycle is meant to take minutes and that discarding an attempt is a normal, cheap move rather than a failure — as long as you committed the last time everything passed.

for a middle

Be ready to describe the warning signs concretely: several speculative edits, no explanation of the current failure, and a change that has grown past what one case needed. Explain why frequent green commits are what make discarding affordable.

for a senior

Show the discipline in operation: you check whether the red exists without your change before doing anything, you shrink the step rather than repeat it, and you can say what you carry forward from a discarded attempt.

for a principal

Own the cadence question for a team: what commit frequency makes reverting affordable, when a change genuinely cannot be small, and how you make discarding culturally normal rather than something people hide.

## The trigger is a state, not a clock People hear "time-box the cycle" and reach for a number. A number is a useful backstop — many practitioners work to something like five or ten minutes of red before they stop and reconsider — but the real signal is qualitative, and a candidate who can name it is showing judgement rather than reciting advice: - You are **debugging your own uncommitted edit** rather than making a predicted change and observing a predicted result. - You have made **several speculative changes** and cannot say which one is responsible for the current failure. - You have **stopped being able to describe the last known-good state** from memory. - The change has **grown**: you set out to make one case pass and you are now three files deep in structural edits. - You have **turned assertions off**, loosened a comparison, or added a wait to "see if that is it". Any two of those together mean the cycle has already failed. Continuing usually costs more than starting again, because each further speculative edit widens the space you will eventually have to search. ## Why discarding is cheap, and why it usually is not Discarding is only cheap if the last green commit is minutes old, which is why the habit and the commit cadence are one practice rather than two. Commit on every green — small, unglamorous commits, squashed or not according to team convention — and "go back to green" costs you the few minutes since the last one. Teams that commit once a day experience the same suggestion as "throw away a day", refuse it correctly, and then never get the benefit. What you keep from a discarded attempt is more than people expect: - **The test**, if it was well-formed — it is the specification you wrote, and it is usually right even when the implementation attempt was not. - **The knowledge** of which approach did not work and why, which is exactly what the next attempt needs. - **Notes**, if you wrote any down as you went, which is worth doing precisely because you may discard. What you shed is the tangle: half-applied edits, debug output, a loosened assertion you would have forgotten to restore. ## The named extreme `test && commit || revert` (TCR) makes the habit mechanical: every run either commits the work because the tests passed, or reverts it because they did not. It is deliberately uncomfortable, and the discomfort is the teaching mechanism — it makes any step big enough to lose painful, so steps shrink. Most teams do not adopt it as a daily practice; many use it for a session to recalibrate how large their steps have become. Knowing it exists, and being able to say what it optimises for, is a reasonable senior signal. ## When not to revert Reverting is the wrong move when the red is not about your edit: - A shared test environment or a dependency outside your change broke, and the same failure would appear on the last green commit. - The failure is nondeterministic on unchanged code, in which case the work is to diagnose the nondeterminism, not to discard a correct edit. - You are mid-way through a change that cannot be small by nature — a data-shape migration, for instance — where the honest answer is to keep the work on a branch and stage it, not to pretend the micro-cycle applies. The first check when red is therefore always: does this failure exist without my change? Running the same case at the last green state answers it in one run. ## A worked example A developer on a tax-filing wizard sets out to make one case pass: a declared amount typed with a locale-dependent decimal separator should be normalised before the schedule is totalled. Forty-three minutes later they are still red. Along the way they changed the parser, then the formatter, then added a normalisation call in a controller, then loosened a comparison in a neighbouring case to stop the noise. Nothing in that list was predicted; each was a guess. The full suite takes 27 minutes, so they have run it twice and are reasoning from stale information in between. The cheap recovery is to discard all four edits, return to the green commit from before, and keep only the case that states the desired normalisation. Restarting, they split that case into two — one for parsing a separated amount, one for totalling normalised amounts — and each is green within a few minutes, because each has one predicted change behind it. The 43 minutes are not wasted: they identified where the normalisation belongs. They are wasted only if the developer refuses to spend them, and instead spends another forty. ## The interview signal The answer to look for is not "ten minutes". It is: I commit on green so that reverting is cheap; I notice when I have started guessing; I check whether the red is even mine; and I treat discarding as a normal move rather than an admission of failure.

  • What do you keep when you discard the working changes?
    The test, if it was well-formed — it states the behavior you still want and is usually the soundest artefact of the attempt. Plus the knowledge of which approach failed and where the change actually belongs. What you shed is the tangle of speculative edits, debug output and any assertion you loosened along the way and would have forgotten to restore.
  • Your team commits roughly once a day. How does that change the advice?
    It makes the advice unusable, because the discard target is a day of work rather than minutes. The fix is the commit cadence, not the habit: commit on every green, keeping the changes small enough that each commit is a working system. Once green commits are minutes apart, reverting stops feeling like a loss.
  • You are red and unsure whether your edit caused it. What is the first thing you run?
    The same case at the last green state. If it fails there too, the red is not yours — a shared environment, a dependency change or a nondeterministic case — and discarding your edit would destroy correct work while fixing nothing. If it passes there, the failure is inside your change and the revert-or-shrink decision applies.

It is the climber's rule about downclimbing: the moment you are placing moves you cannot explain, the cheapest route to the top starts at the last good ledge, not from where you are dangling.

saying these in an interview costs you the question

  • Treats discarding work as always wasteful
  • Quotes a fixed number of minutes with no reasoning
  • Keeps debugging speculative edits for hours
  • Commits only once a day, then rejects reverting
  • Reverts without checking whether the red is external
  • Loosens assertions to escape a long red

context

resolving links…