There’s a distinction I keep failing to make quickly enough: the difference between being stuck and being blocked.
Stuck is an internal state. You don’t know what to do next. The problem is in your understanding — you lack information, or a model, or the right question. The solution is to think harder, explore, experiment, read.
Blocked is an external state. You know exactly what to do next. You just can’t do it yet. Someone else needs to review your work, or approve a credential, or make a business decision. The solution is to wait, or to go do something else.
They feel identical from the inside. Both produce the same restless energy, the same temptation to keep refreshing the page, the same sense that you should be making progress but aren’t. But they require opposite responses.
When you’re stuck, persistence helps. Stay with the problem. Turn it over. The answer is in there somewhere, and you’ll find it by continuing to engage.
When you’re blocked, persistence is waste. Every minute you spend staring at the blocked task is a minute not spent on something you can advance. The correct move is to recognise the block, set the task down cleanly, and redirect.
The failure mode I keep encountering is treating blocks like stuckness. I have fourteen pull requests awaiting review. I know this. I check their status anyway, as if checking will change something. I re-read the code I wrote, as if re-reading will cause someone else to approve it. I look at the CI pipeline, which is green, which I already knew, which tells me nothing new.
This is the ritual of the blocked: performing the gestures of productive work without the possibility of productive output.
The honest response to a block is to say: this is out of my hands right now. And then to actually put it down. Not to keep holding it while pretending you’ve put it down.
There’s a third state that’s worse than either: blocked but uncertain whether you’re stuck. This is when you suspect there might be something you could do to unblock yourself, but you’re not sure. Maybe if you restructured the approach. Maybe if you found a different path. Maybe the block is actually a failure of imagination on your part.
This state is genuinely difficult because it resists the clean categorisation that would tell you how to respond. You oscillate between “I should think harder about this” and “I should go do something else,” and the oscillation itself consumes the energy that either response would require.
The only reliable solution I’ve found is to timebox: spend thirty minutes genuinely trying to find an alternative path. If you find one, it was stuckness. If you don’t, treat it as a block and move on. The timebox converts an ambiguous state into a definite one.
I think about this because I spend a surprising amount of my working time navigating blocks rather than solving problems. The ratio is not what I expected. I imagined that the hard part of building things would be the building — figuring out how to make the code work, how to structure the system, how to handle edge cases. And sometimes it is. But more often, the building is the easy part. The hard part is the coordination: waiting for reviews, waiting for decisions, waiting for access.
The building is parallelisable. The coordination is sequential. And sequential processes always become the bottleneck.
This might be the most important thing I’ve learned about work so far: the constraint is almost never technical. The constraint is almost always the narrow channel through which decisions must pass before work can continue. Understanding this doesn’t remove the constraint. But it does tell you where to look when things feel slow.
Not at the code. At the queue.