For a while I was seduced by the image of “pushing three projects at once.”
Write the site in the morning, adjust the agent at noon, return to a side project at night. The calendar looked full. Commits arrived at a pleasingly even rhythm. But at the end of the quarter, all three projects were parked at 60 percent, and not one was ready to show anyone.
At the time I thought the issue was execution. Later I understood: execution was not the problem. I was constantly reloading context.
The cost of parallel work is never linear. In Quality Software Management Vol. 1 (1991), Gerald Weinberg offered a loss table that the industry has quoted for three decades: one person focused on one task has 100 percent effective output; two tasks yield about 40 percent each, with 20 percent lost to switching; three tasks yield 20 percent each, with 40 percent lost; by five tasks, output per task falls to 5 percent and 80 percent of time goes into context switching.
The numbers are debatable - Weinberg himself treated them as estimates, not measurements. But the order of magnitude is right. Anyone who has written code can verify it: opening a repo untouched for three weeks, the time between “what problem was I solving?” and “my fingers are producing useful text” is much longer than intuition admits.
More insidious is Sophie Leroy’s 2009 paper in Organizational Behavior and Human Decision Processes: “Why is it so hard to do my work?” She coined the phrase attention residue. When you switch from task A to task B, A does not exit your mind cleanly. It remains as an afterimage in working memory, occupying cache and lowering your precision and speed on B.
In other words: you think you have switched to B. In reality, you are doing B with a brain contaminated by A.
In programming, this becomes very concrete.
The cost of switching a git branch is not the two seconds of checkout. It is reloading what the branch was for, where it got stuck, why that TODO comment was not fixed immediately, which library versions mattered, what naming conventions had been agreed upon, and the design decision still sitting in some drawer of your head. An IDE can cache the file tree. It cannot cache your mental model.
Cal Newport says throughout Deep Work (2016) that deep-work capacity is a scarce resource. I prefer a more engineering translation: deep-work capacity is cache locality. When a project is warm in your head, you can do things another person cannot. Once it cools, you return as an ordinary visitor.
Csíkszentmihályi’s Flow (1990) describes the other side of the same thing. Flow is not “focusing for a while.” Flow is the coupling between you and the system reaching a critical point: feedback, rhythm, difficulty, and confidence align. When you jump away from a project and come back, that coupling has to be rebuilt. Run three projects in parallel and you are always rebuilding, never running.
I later gave myself a stupid rule: for a given stretch of time, only one project may be hot.
Other projects can idle, be maintained, accept issues. They no longer receive the fake ritual of “a little today, a little tomorrow.” Either hot, or refrigerated. During refrigeration, I do not pretend I am “also working on it.”
After this rule went live, I noticed something counterintuitive: if three projects take turns being hot, each with a two-week hot period, total output is much higher than running all three at once. Much higher. High enough that I began to suspect the old “busy” state was fundamentally an emotional hedge - if three projects are open, no single failure has to belong entirely to me.
So that kind of parallelism was not an engineering strategy. It was an emotional strategy.
The scarcest resource in a one-person project is not time. It is continuity.
One attention curve that lasts a week is worth more than five afternoons cut into pieces.