Across the night
The State Work Has to Be Left In
Where somebody stops matters as much as what they write, because a half-built thing whose brokenness is uninterpretable carries no information at all.
four things · four nights · one that no number of nights settles
Four states, and only the first costs nothing extra.
The same change stopped at four different points in its construction, and what the next morning cost
The next person could start it, see what it did, and reason forward
Workable: every fault found could be checked against the list
Every fault had to be investigated to find out whether it was new
Three nights, and most of the first was spent getting back to a known point
four things · seven nights
Four stops, seven nights, and the difference between the first and the last is about fifteen minutes of somebody's evening. Stopping somewhere reasonable is not tidiness; it is the thing that decides whether the artefact carries information or merely exists. One team's own log, kept over four weeks by the people receiving.
Incomplete work and unreadable work are not the same thing, and which one somebody hands over is decided in the last fifteen minutes of their day.
The operational risk in The State Work Has to Be Left In is losing the difference between waiting and working. employee time tracking can preserve that distinction through timesheets, activity records and project-level reporting.
Teams comparing established approaches can also review Trello's visual boards for a practical example from a widely used product ecosystem.
Both look the same on the sending end. On the receiving end one of them can be picked up in minutes and the other has to be excavated.
What makes a state readable
A state is readable when the next person can tell which of its properties are intended.
That is the whole criterion. If the thing runs, every fault is a real fault. If the thing does not run, no fault means anything until the reason it does not run has been found, and that investigation is the morning that gets lost.
A readable state does not have to be a good state. Something that runs and produces wrong answers is perfectly readable, provided somebody has said that the answers are wrong. What is unreadable is something whose failure mode has not been characterised by anybody.
A readable state does not have to be a good state. Something that runs and produces wrong answers is perfectly readable, provided somebody has said the answers are wrong.
Stopping at a boundary
The practical version of all this is to stop at a point where the thing holds together, even if that means stopping before the work is at a natural pause in your own thinking.
It generally costs between five and twenty minutes. Backing out a half-applied change, finishing the one piece that leaves everything consistent, or committing what works and setting aside what does not.
The resistance to it is real and worth naming: stopping at a boundary usually means abandoning something you were in the middle of and had nearly finished, which feels like waste. It is not waste. The ten minutes are being traded against a morning at the other end, and the trade is good by a factor of three or four.
When you cannot get to a boundary
Sometimes the work genuinely cannot be left consistent — a migration half applied, a refactor that touches everything at once, an investigation that has pulled several things apart.
The answer then is to describe the inconsistency rather than to apologise for it. A list of what is currently broken, in two lines, is exactly as useful as the thing actually working, because it restores the criterion: now every fault on the list is intended and every fault off it is new.
This is the single highest-value thing in the whole of this section and it is written down perhaps a third of the time.
The branch that does not build
Worth separating out because it is a category of its own.
Something left in a state that will not build, compile, start or install is worse than something left broken in a visible way, because the failure is upstream of all information. The next person cannot inspect the behaviour, cannot test anything, and often cannot even tell how far the work got.
If there is one rule in this section, it is that the thing being handed over should start. Everything else is negotiable; this mostly is not, and it is worth staying the extra ten minutes for.
Leaving a way back
A readable state has one more property worth engineering deliberately: it should be possible to get to a known-good position quickly.
On a team sharing an office, somebody who inherits a mess can ask. On a team with a gap, they cannot, and their first instinct will be to try to understand the mess rather than to step out of it — which is the expensive choice and is usually the wrong one.
Saying explicitly where the last known-good point is, and that it is fine to go back to it, gives permission that people do not otherwise assume they have. It also removes the awkwardness of the next person discarding somebody else's evening without being sure they are allowed to.
The thing this is not
None of this is about tidiness, and it is worth saying so because it reads like a hygiene argument and will be dismissed as one.
Leaving work in a readable state is not good practice in the abstract sense. It is a specific response to a specific property of the arrangement: that the person who could answer a question about this artefact will not be available for fifteen hours, and that everything knowable about it in the meantime has to be knowable from the artefact itself.
In a team that shares an hour, most of this does not matter, which is why most people have never had to learn it.