The auth bug was ten minutes from fixed. I had the whole failure loaded in my head: the token refresh racing the retry, the three files it touched, the one line I was reaching for. Then a Stripe email slid across the top of the screen at 3:12 PM. I read it. Fourteen seconds, maybe. Then I looked back at Xcode and the structure was just gone. Rebuilding it took the better part of forty minutes.
That ratio bothered me enough to start timing it. A fourteen-second glance had cost me forty minutes, and no tool I owned had a place to record that. My calendar knew about the meeting. My timer knew the hours. Nothing knew the tax.
What thirty days of timing actually showed me
- The interruption is the cheap part. Re-entry is where the time goes, and almost nobody measures it.
- My re-entry cost was bimodal. Trivial switches ran about two minutes; deep ones ran thirty to forty-five. There was almost nothing in between.
- The single biggest predictor of which one I got was stupidly simple: whether I had written down my next move before I left.
- Blocking interruptions barely moved the number. Making re-entry cheap moved it a lot.
The setup, and why a solo dev can't just "avoid distractions"
Here is the part the productivity advice skips. As a solo developer I am the engineer, the support desk, the ops on-call, and the person who notices the payment failed. Most of my interruptions are not distractions I can silence. They are the job arriving out of order. "Turn off notifications" is advice written for someone who has colleagues to absorb the things they ignore. I don't have colleagues.
So after the forty-minute day I stopped trying to block interruptions and started measuring what they cost. One line per interruption for thirty days: the time, what I was doing, what pulled me away, and when I was genuinely back in. That last field turned out to be the one that mattered. I defined "back in" as my first correct edit after returning, not the moment my eyes hit the screen. Those are very different timestamps.
I want to be honest about the instrument before I quote it. This is one developer timing himself, and on a bad day the faculty doing the timing is the same one the bad day has already degraded. Treat my numbers as a shape, not a benchmark.
The population number does exist, and it is worse than most people think. Gloria Mark's team at UC Irvine, shadowing office workers through their real days, found it took an average of 23 minutes and 15 seconds to return to a task after an interruption, and that people don't go straight back but pass through about two intervening tasks first. Her 2023 follow-up is bleaker: average attention on a screen has fallen to roughly 47 seconds, with an interruption about every three minutes. The 23-minute figure is real. What it hid, for me, was the shape underneath the average.
Why is re-entry the expensive part, not the interruption?
Because the interruption doesn't charge you for its own length. It charges you for the teardown.
When I'm deep in a bug I'm holding a small structure in working memory: which call races which, what I've already ruled out, the exact edge I'm standing on. That structure isn't saved anywhere. It lives in the most volatile storage I own. A fourteen-second read doesn't cost fourteen seconds; it evicts the structure, and then I have to rebuild it from source — reopen the files, re-derive what I'd ruled out, walk back to the edge. Mark's two-intervening-tasks finding is the same story told from the outside: you rarely drop straight back into the thing. You bounce off two smaller things on the way.
This is the extension of something I found the hard way a couple of months ago, when I was logging energy instead of hours: the villain in that ledger was never interruption either, it was unresolved ambiguity running a background thread and eating the depth I was saving for the hard task. This is the same monster in a different coat. Interruption isn't expensive. Losing your place is.
What the timer showed: the same switch, two different bills
Once I sorted thirty days of lines, the split was embarrassingly clean. The cost of a switch had almost nothing to do with the interruption and almost everything to do with the one thing I controlled: whether I had left myself a note.
| No next-action written | Next-action written | |
|---|---|---|
| Shallow switch (I knew where I was) | ~2 min | ~2 min |
| Deep switch (mid-problem, stack loaded) | ~34 min | ~6 min |
The top row barely reacts. When the work was shallow, re-entry was cheap no matter what, because there was no structure to lose. The bottom row is the whole story. A deep switch with nothing written down cost me a median of about 34 minutes. The same depth of switch, when I had spent one second writing down my next move, cost about 6. Same interruption, same me, a five-fold difference that came down entirely to whether I had left a breadcrumb.
The fix that didn't work
For a month before this I did what everyone recommends. Notification batching. Do Not Disturb blocks. "Focus hours" fenced off on the calendar. It moved the number so little I almost didn't bother logging it.
The reason is that blocking assumes the interruption is optional, and mine mostly weren't. The build broke; I had to look. A customer couldn't log in; I had to answer. The pattern the advice is built for, a stream of pings you could ignore without consequence, is not my pattern. You cannot Do-Not-Disturb your way out of being the entire company. Blocking treats the switch itself as the enemy. For me the switch was usually the correct thing to do. The damage came afterward, in the re-entry, and blocking did nothing about that.
The one that did: cheapen re-entry, don't prevent the switch
So I gave up on preventing switches and put everything into making re-entry cheap. The whole method is one habit: before I leave a task, even for fourteen seconds, I write one line saying exactly what I was about to do next.
Not "fix auth." That is a task label, and it is useless coming back — it names the mountain, not the step. The line has to be the specific next physical action: refreshToken guard in AuthClient fires before the refresh resolves; change the guard near line 80, not the retry. That sentence reloads the structure. When I come back I don't rebuild from source; I read one line and step onto the exact edge I left.
The catch is that this only works if writing the line is nearly free. If capture takes longer than the thought, I won't do it mid-switch, and I'll quietly promise myself I'll remember. So the breadcrumb rides the same one-second capture path as everything else I catch, because a thought I can't get out of my head in about a second is already gone. One line into my own email, there in about a second; on the evenings I sit down to curate, the same line is already under that day's heading in my vault. The point isn't where it lands. The point is that the exit costs a second and the re-entry it buys back costs half an hour.
The part I don't want to oversell
This is n=1, self-reported, and the "back in" timestamp is a judgment I made about my own head. The breadcrumb has a real failure mode too: when the interruption changes the task (a production incident that rewrites what the next action even is), there's no place to return to, and the note is worthless. And none of this is some new law of attention. It's one crude instrument telling one developer he had been counting the wrong number for years.
Which is the actual takeaway, if there is one. Every tool I own counts interruptions. Not one of them counts re-entry, and re-entry is the number that was eating my days. Measure the thing that costs you, not the thing that happens to be easy to count.
A few questions I keep getting
Isn't a breadcrumb just a TODO? No, and the difference is the whole point. A TODO records a task: "fix auth." A breadcrumb records a resume point: the specific race, the specific line, the thing I had already ruled out. A task label makes you rebuild the context; a resume point hands it back. You can feel which one you wrote by whether reading it reloads your head or just reminds you the mountain is still there.
Doesn't stopping to write the line just add another interruption? It lives inside the switch you were already taking, and it costs about a second against a re-entry that runs into the tens of minutes. I have never once regretted the second. I have lost the afternoon plenty of times by skipping it.
What if I can't tell a deep switch from a shallow one in the moment? You don't have to. Write the line on every switch. On shallow ones it costs a second and you throw it away; on deep ones it saves you half an hour. It is cheap enough to buy as insurance on all of them, and you stop having to make the call.
So here is what I actually want from you: what is your own re-entry time after a deep interruption, and have you ever measured it apart from just counting how often you got interrupted? The count is the number every app puts in front of you. I am increasingly sure it is the wrong one, and I would like to know whether your log says the same.
I'm a solo developer building Simple Memo, an iOS app that gets one line of text into my own email about a second after I think it — roughly the speed a breadcrumb has to be caught to survive a context switch. I write here every few days about the parts of building alone that caught me off guard.
Top comments (0)