You come back from a thirty minute meeting, open your editor, and look at a diff you wrote an hour ago. It makes sense line by line. What you can’t remember is where it was going. Which test was failing? What were you about to try? Why is that function half renamed?
That gap has a cost, and it is bigger than it feels.
What the research says
Chris Parnin studied this directly. In an analysis of 10,000 recorded programming sessions from 86 developers, he found that it typically took 10 to 15 minutes to start editing code again after an interruption. When the interruption landed in the middle of editing a method, developers were back at work within a minute only about one time in ten.
The reason is not laziness. While you work, you hold a small model of the problem in your head: the state of the code, what you already ruled out, the next step. An interruption doesn’t pause that model. It clears it. Coming back means rebuilding it from whatever clues you left behind, and most of us leave very few.
Five habits that make coming back faster
1. Write one line for your future self before you stop
Before you step away, write a single sentence: what you were doing and what comes next. “Retry works, now testing the replay case, expect the signature check to fail.” Put it where you will see it first: a comment at the cursor, a scratch file, the top of your notes.
It takes ten seconds and saves most of the rebuild.
2. Stop where the next step is obvious
Writers have an old trick: stop for the day in the middle of a sentence you know how to finish. The same works for code. If you have to stop, stop with a failing test you understand or a function you know how to write. Starting again is easy when the first move is clear.
3. Commit small, and say why
Your git history is the most reliable record of what you did, but only if it says something. “wip” and “fix” tell future you nothing. “Add backoff to webhook retries; replay case still fails” tells you exactly where you are.
git log --oneline -5Five lines like that are often all you need to pick up the thread.
4. Read what your coding agent did
If you work with Claude Code or Codex, the session history is a detailed log of what was tried, what failed and where it stopped. Skim the last few turns before you start. It is faster than rediscovering the same dead ends.
5. Keep one notes file per branch
A short NOTES.md for the branch you are on, with what you are trying and what you already ruled out, turns a long interruption into a two minute read. Delete it when the branch merges.
The pattern behind all five
Each habit does the same thing: it moves the model out of your head and into a place you can read later. The better the trail, the shorter the rebuild.
An interruption doesn’t pause your work. It clears your working memory. Leave a trail.
Where Stuart fits
We built Stuart partly for this moment. When you come back, you can ask it “Where was I?” and it reads your recent commits, your Claude Code and Codex sessions and your notes on your Mac, then tells you, with a source for every sentence. It is not a replacement for the habits above. It is what reads the trail for you when you didn’t have time to leave a good one.
