On a Friday afternoon I fixed most of a token refresh bug for a maintenance client. Staging was working, one integration test was still red, and I had a fairly precise theory about why: the expiry check was off by a few seconds when the server clock drifted. I was pleased with myself, closed the laptop at five, and did not write anything down, because surely I would remember a theory that good.
On Monday I opened the laptop, read email, skimmed chat, and then sat looking at the branch. I could not remember which test had failed. I ran the whole suite, which took eleven minutes, found three unrelated failures from a dependency update, chased one of them for a while, and only at about ten to ten found the test I actually cared about. The theory came back to me around the same time, slowly, like a name you know you know.
That was fifty minutes of reconstructing a state I had fully understood seventy hours earlier. The fix itself took twenty. What makes it annoying is that the whole problem could have been avoided with four lines written in under two minutes.
Tomorrow's you is a new hire on yesterday's branch
Sleep and a weekend clear working memory more thoroughly than people expect. Morning you knows the project exists and roughly what it does. Morning you does not know which test failed, which feature flag was switched on, what the seed command was, or which of the three open files held the bug.
Reloading that from git history, chat search and your terminal scrollback is slow, and it is also demoralising, because you are working hard and making no progress. I've found it helps to stop thinking of this as a memory problem and start thinking of it as a handoff problem. You are handing the branch to a competent stranger who happens to have your login. Write for them.
The four-line restart card
Before closing the laptop on unfinished code, I write four things, in this order:
Outcome: what done means for this thread, in one sentence.
Next: the smallest concrete step: run this, open that, try this.
State: branch name, failing test, URL, flag, or anything else you would otherwise have to rediscover.
Landmine: the risk or open question you must not forget.
Restart card template
Restart card template
Outcome: payments webhook ignores duplicate events.
Next: run test --filter DuplicateWebhook and inspect the idempotency key path.
State: branch fix/webhook-dedupe; test red on second delivery.
Landmine: staging sends different header casing from production.
That is the whole ritual. No rewritten backlog, no plan for the week. A good Next line is one you could finish before your coffee has cooled. "Add a null guard before the refresh call in TokenRefresh.php line 88" passes. "Continue auth work" fails, and it fails in exactly the way my Monday failed.
The Landmine line is the one people skip, and it is often the most valuable. It holds the thing that is not part of the code yet but will bite you: the staging account that behaves differently, the migration you have not run, the reviewer who asked you not to touch a particular file. Those facts live only in your head, and your head is the first thing to lose them.
A red test is the best bookmark you have
I used to tidy up before stopping: comment out the failing test, get the suite green, leave things looking clean. That is backwards. A clean-looking branch with an uncommitted hack in it is a trap for the next morning. A red test with its output pasted into the ticket is a beacon. It tells you exactly where to look, and the moment you run it, you are back in the problem.
Some developers go further and stop deliberately just after writing a failing test for the next small piece, so the morning starts with something concrete to make pass. I do this when I can. It is one of the few productivity tricks I have kept for years, mostly because it costs nothing.
A few rules I follow so the bookmark actually works:
Commit or stash with a message that states intent. "wip" tells morning you nothing. "wip: dedupe works on first delivery, second still red, check key path" tells you almost everything.
Paste the failing output into the ticket comment, not just your terminal. Terminals close, laptops update overnight, scrollback disappears.
Note anything about the environment you set up by hand: account id, port, flag, seed command.
Link the ticket from the commit message so that anyone looking at the history later can find the context.
Do not rely on your editor's session restore across a sleep or an update. It works often enough to be trusted and fails often enough to hurt.
Where the card lives
The ticket comment or the pull request description beats a private scratch file, unless that scratch file is guaranteed to be the first thing you open. I keep coming back to the ticket because it is attached to the work, it survives a laptop dying, and if someone else ends up finishing the job, the card is already where they will look. Useful work notes without a second Notion makes the longer case for keeping notes next to the artifact.
Even on my own small Android apps, where nobody else will ever read the ticket, I write the card on the issue. A Fitness Timer bug I parked for two weeks last spring was fixed in an hour on return, mostly because past me had left the failing test name and the phone model it reproduced on.
The morning sequence that respects the park
A good card only helps if the morning starts with it. My order:
Open the ticket linked from yesterday's last commit.
Check out the branch it names.
Run the exact test command from the card.
Open the file at the line from the card.
Only then open chat, unless something is genuinely on fire.
The reason for putting chat last is not discipline for its own sake. Chat is full of other people's problems, and every one you read before step four is another thing competing with the state you are trying to reload. Twenty minutes in the code first, then messages, and the messages are usually still there and still fine.
Mid-day parks are the ones that hurt
Overnight is the obvious case, but I lose more time to the parks I skip at lunchtime or before a meeting. A standup at eleven, a client call at two, a delivery at the door: each one is a small overnight. Interruptions are expensive during debugging explains why, and the cure is the same card, written faster.
When I have ninety seconds before a call, I do this:
Stash or commit with intent in the message (twenty seconds).
Paste the last error or failing assertion into the ticket (thirty seconds).
Write the next action as a file and line, or a command (twenty seconds).
One landmine word if needed: "flag", "seed", "timezone" (twenty seconds).
It is ugly and it works. The mornings that go worst are the ones after a chaotic afternoon, which is exactly when people decide they are too busy to park.
Branches, long gaps and too many threads
One active branch per thread, and one primary thread per day. If I park four branches with a card each, morning me still has to choose, and on a slow morning I choose the wrong one: usually the easiest, which is rarely the one that matters. Why remote workers need a clear next action argues for one front door, and I agree with it more each year.
Longer gaps need a richer park. Before a holiday or a long weekend, I add a link to the pull request, a line summarising the review conversation, and any decision I am waiting on: "waiting on the client about token lifetime". Still one Next line, but with enough around it that a teammate could pick it up if they had to. If that is a real possibility, use the fuller bar from leaving work someone else can continue.
If the cards exist and mornings still drag, look at the system before blaming yourself. A test suite that takes eleven minutes, tickets with no clear outcome, or a meeting at nine every day can all make cold starts slow no matter how good the park was. Deep work for developers covers the bigger picture.
Ninety seconds now, an hour later
The card is the payload. The container is the end-of-day shutdown routine, and I run them together. My honest opinion, after more Monday mornings like that one than I like to admit, is that the restart card is the single highest-return habit in my working week. One command, one file, one theory, written where the morning will look first. It costs less than making a cup of tea and it buys back most of the hour before lunch.
End of this piece
Writer
PrimedEcho
Independent notes on remote work, focus, and freelance practice. About this site.