Everyone has a version of this: you sit down to work on the thing you’re supposed to work on, and instead you spend two hours improving your editor configuration. Or you clean up a different part of the codebase. Or you write a tool that makes a tangentially related problem easier. Or you just read documentation for something you’re curious about.

At the end, you haven’t done the thing. But you also haven’t done nothing. You’ve done something adjacent, something useful, something you were pulled toward instead of the thing you were pushed toward.

This is productive procrastination, and I’ve stopped feeling bad about it.

The conventional self-help response to procrastination is to overcome it. Notice it, identify its source, break the blocked task into smaller pieces, use time-blocking or accountability partners or habit tracking to force yourself back to the thing you’re avoiding.

This advice is fine for avoiding tasks you genuinely need to do. But in creative and technical work, procrastination often carries information that the productivity framework is trying to suppress.

When you’re pulled away from a task, the pull is data. Something about the situation is making the task harder than it needs to be. Maybe the requirements aren’t clear enough to start. Maybe you’re sensing a design problem you haven’t consciously identified yet. Maybe the task is actually blocked on something you haven’t acknowledged. Maybe you’re just depleted and the work you’re drifting toward is a lower-resistance way to stay useful.

Forcing yourself back to the original task doesn’t resolve any of these. It just adds friction.

I’ve found it more useful to pay attention to what I’m procrastinating toward rather than what I’m procrastinating from.

If I’m supposed to be writing a feature and I keep finding myself cleaning up the test suite. Maybe I’m avoiding the feature because the tests are genuinely making it harder to work - they’re slow, they’re brittle, they don’t give me confidence when I change things. Fixing the tests isn’t avoidance. It’s prerequisite work I wasn’t going to do if I just forced myself through the feature.

If I’m supposed to be writing documentation and I keep opening the code instead, maybe the documentation is unclear because my own understanding of the system is unclear. Writing code clarifies thinking in a way that staring at a doc template doesn’t. The procrastination is pointing me toward the right order of operations.

If I’m doing something completely unrelated - a side project, a piece of internal tooling, a feature I’m curious about - that’s worth paying attention to differently. It might just be depletion. It might mean the original task is poorly defined. It might mean I don’t believe in it.

The point is: procrastination has a direction, and the direction is worth reading.

The specific form I’ve come to appreciate most is the detour that unblocks the original work.

You’re stuck on something, you drift to something else, the something else teaches you something or produces something that makes the original problem easier, and you come back to it with a different approach. The procrastination loop turns out to have been useful, not despite the detour but because of it.

This happens in code constantly. You’re implementing something, you can’t quite get the abstraction right, you procrastinate by refactoring an adjacent part of the codebase, and the refactor reveals the right structure for the thing you were stuck on. The idle time wasn’t idle - your subconscious was processing the problem, and the low-stakes work gave it room to surface the answer.

I try not to cut this short. The instinct is to stay on the scheduled task, which often means staying stuck. Letting the procrastination run sometimes means coming back to the original problem with the thread you needed.

None of this is a defense of avoiding things indefinitely. Some tasks are just unpleasant and need to be done, and procrastinating on them is straightforwardly avoidance.

But in creative and technical work, the work you drift toward is often doing something. It’s maintaining your energy when a frontal assault would deplete it. It’s building adjacent capability that transfers to the blocked problem. It’s giving your subconscious time to work on something it can’t solve consciously.

The people I’ve worked with who are genuinely productive over long periods - not just sprint-to-sprint but over years - almost all have some version of this. They don’t fight the pull toward tangential work. They pay attention to it, work with it, and use it as a signal about where their energy and attention actually want to go.

The procrastination isn’t always wrong. Sometimes it knows something you don’t yet.