Re-entry cost is the hidden tax of solo development

A 14-second glance at a Stripe notification once cost me 40 minutes of actual productivity. I was ten minutes away from fixing an auth bug—I had the entire race condition mapped out in my head, the specific token refresh failure, and the exact line of code I needed to change. Then a notification slid across the screen. I read it, looked back at Xcode, and the entire mental model had vanished. Rebuilding that internal state took nearly an hour.

That specific ratio—14 seconds of distraction for 40 minutes of recovery—bothered me enough to track it for 30 days. I stopped trying to "avoid distractions" (which is impossible when you're the dev, the support desk, and the ops lead all in one) and started measuring the "re-entry tax."

The data: Interruption vs. Recovery

After a month of logging every interruption, the trigger, and the exact timestamp of when I was "back in" (defined as the first correct edit made, not just the moment I looked at the screen), the patterns were clear:

• Bimodal Distribution: My recovery time wasn't a bell curve. Trivial switches took about 2 minutes; deep-work interruptions took 30 to 45 minutes. There was almost nothing in between.
• The Predictor: The single biggest factor in whether a recovery took 2 minutes or 40 minutes was whether I had written down my "next move" before switching focus.
• The Myth of Blocking: Trying to block interruptions barely moved the needle. Focus on making re-entry "cheap" provided a much higher ROI.

This aligns with research from Gloria Mark at UC Irvine, which found that it takes an average of 23 minutes and 15 seconds to return to a task after an interruption. More concerning is her 2023 data showing average screen attention has dropped to roughly 47 seconds, with interruptions occurring every three minutes.

Why the "Teardown" is the expensive part

The interruption itself is cheap; the teardown of your mental state is where the cost lies. When debugging a complex LLM agent or a race condition, you aren't just looking at code—you're holding a volatile structure in working memory: what has been ruled out, which call races which, and the exact logic edge you're standing on.

This structure isn't saved to a disk; it's in the most volatile storage we have. A brief distraction evicts that structure. To get back, you have to rebuild from source: re-open the files, re-trace the logic, and re-verify the exclusions.

Practical implementation: The "Breadcrumb" workflow

To lower the re-entry cost, I've moved toward a "breadcrumb" system. Before I allow myself to switch contexts (or when an urgent alert hits), I spend 5 seconds writing a literal "save state" in a scratchpad or as a comment in the code.

Example of a high-cost vs. low-cost exit:

• High-cost exit (The "I'll remember this" approach): Just switching tabs to answer an email.
• Low-cost exit (The Breadcrumb): Leaving a comment like the one below:

// STOPPED HERE: The token refresh is triggering BEFORE the retry logic 
// hits the 500ms timeout. Check if the interceptor is swallowing the 
// error in authService.ts line 142. 
// NEXT STEP: Log the timestamp of the refresh call vs the retry attempt.

By externalizing the working memory, I'm not rebuilding the state from scratch; I'm just loading a save file. This transforms a 40-minute recovery back into a 2-minute one.

If you're managing a complex AI workflow or deep-diving into deployment issues, stop counting the hours you spend working and start measuring the time it takes to get back into the zone. The recovery time is the only metric that actually matters for throughput.