It's not a productivity thing. That gap used to be where a lot of my better thinking happened. So I've been trying to put it back. Harder than it sounds.
Slowing Down Used To Be Automatic
The thing I keep circling back to is that nobody in this industry ever had to practice patience. The tools enforced it for us.
Going from an idea to a working prototype used to take weeks, maybe even months, and that had nothing to do with anyone being thoughtful. It's just how long the code took to write.
But those weeks did something. Around day nine you'd notice the thing you were building solved a slightly different problem than the one you started with. Around day fifteen a feature you were excited about on day one didn't matter anymore so you ripped it out.
The idea changed while you were busy implementing it. Nobody scheduled that, it just came free with the friction.
Now the friction is gone.
You can have the working version before you've had a second thought about whether it's the right version, and the pause that used to happen on its own has to be put there deliberately.
Which makes it a skill now, and one most of us never had to develop.
I don't think anyone decided to stop waiting. The capability just quietly expired along with the compile times.
Where My Ideas Actually Come From
Almost none of my good ideas arrive while I'm working.
They show up on walks with the dog, or while lying in bed, embarrassingly often. Playing guitar for an hour helps too. Sometimes it happens somewhere in the middle of a long drive when I'm not thinking about anything in particular.
It's crazy how rarely it happens at the desk. The desk is where I execute things I already figured out somewhere else.
There's research on this that's more specific than the usual advice about stepping away. Sio and Ormerod pulled together 117 studies on delayed incubation, which just means setting a problem down after working on it. The benefit shows up consistently, modest but reliable.
Two details in there caught me.
The pause works better if you spend it doing something mildly occupying rather than nothing at all.
Walking beats staring at a wall. Both beat answering email, which explains why "taking a break" by checking Slack has never once produced anything for me.
And it only works after you've already done real conscious work on the problem. The background processing runs on material you loaded in.
Waiting is what you do with the work after you've done it, and it substitutes for none of it.
That's the line between patience and procrastination, and it's why I'm not going to tell anyone to just slow down in general.
Projects Where This Showed Up
I built the first version of SEO Dash in an afternoon. Four months later I still haven't shipped it (yeah, I know.)
The afternoon version worked though. It did what I wanted and I used it happily for weeks. It was also nowhere near ready for anybody else, and most of the four months since have been the slow work of noticing why.
The scope shifted and I could never have predicted how back on day one. I rebuilt features I'd already finished, I added an AI agent that was never in the plan, and that one arrived as an answer to a problem I'd been circling for weeks without ever putting into words.
The tool was great at telling you what was wrong with a site and useless at helping you decide what to do about it.
I didn't reason my way to that. I noticed it slowly, the way you notice a sound your car has been making. You know?
AutoChangelog went through several rounds before it was right, and that's a far smaller product with a narrower job. Hyperfocal took 7 months of thinking about it and about 3 weeks of building. It took 3 weeks because I circled the idea for all those months. I already had it all figured out in my head.
Neither of those felt like patience at the time. AutoChangelog just felt unfinished, over and over. Hyperfocal felt like I hadn't started yet, right up until I did.
It Isn't Only Projects
The part I've been thinking about more is that this isn't a work problem I can fix with a better process.
When I moved to Mexico it was partly to have a slower life, but I then filled the slower life with the same pace I brought with me. Geography doesn't fix tempo, you usually bring your own.
I run about a dozen things at any given time (plus the day job), and the honest accounting is that most weeks I'm reacting rather than thinking.
Not because anything is on fire, but because there's always something available to react to.
The phone is right there, the dashboard is right there. Whatever I'm avoiding is one tab away from being avoided more comfortably.
Slowing down in that context isn't restful at all. In fact, it's uncomfortable, at least at first.
There's a stretch of about twenty minutes where doing nothing feels like something has gone wrong.
I haven't solved that. I just know the discomfort is the price, and the thinking is on the other side of it.
Slow Has Its Own Failure Mode
Because there's a version of this that's just an excuse, and I want to be honest about it.
Teresa Amabile ran a study at Harvard collecting over 9,000 daily diary entries, and the headline is that time pressure tends to kill creativity.
That's the part everyone quotes. The bit underneath is more useful.
Low pressure with real engagement is where the exploring happens. Low pressure with no engagement is just autopilot, and it produces nothing at all.
So slow isn't the goal. Attention is.
You can absolutely spend four months not shipping something and have it be avoidance rather than incubation, and from the inside those two feel remarkably similar.
There's one more finding from that study I keep thinking about. People consistently believed they'd been more creative on high-pressure days. The feeling ran backwards from the measurement.
Which is roughly what METR found when experienced developers came out 19% slower with AI while estimating they'd been 20% faster. Twenty years apart, completely different setup, same illusion.
We're bad judges of our own tempo. Worth knowing before you trust the feeling of moving fast.
I Still Don't Know If I'm Doing This Right
SEO Dash hasn't launched (yet!) I think the time will pay off and I have no way of knowing that it will, but it's ok.
Most writing about patience gets narrated from a comfortable after, where the waiting obviously worked because the thing succeeded. I'm still inside it.
I know the four-month version is better than the afternoon one. No question about it.
I don't know whether four months was the right number, or whether two would've done it, or whether I'm dressing up ordinary slowness as deliberate craft.
What I can say is that shipping the afternoon version would've been a mistake I'd have felt within a week. I'm 100% convinced of that.
What I'm Actually Doing About It
None of this is a system, just stuff that seems to help.
Load the problem properly before setting it down. Sitting on a half-formed idea produces a half-formed idea with dust on it.
Then go do something mildly occupying. Walking, dishes, guitar, go for a drive, etc. whatever holds you lightly without asking for real attention.
Separate two questions that speed collapsed into one. Whether to build it and when to build it used to get answered on different days because they had to be.
Now they arrive together, and they're still different questions.
And the week test, which is the one I use most. If I can still explain the idea crisply seven days later without notes, it survived.
The ones that don't survive were usually just excitement, and I couldn't tell the difference at the time.
Where This Leaves Me
The tools aren't going to get slower and I'm not asking them to. Heck, I use them constantly and I'd be worse off without them. Not gonna deny that.
But the pause has to be built now, and paying for it still feels unproductive in a way it never did when writing the code was done manually or the compile was going to take twenty minutes regardless.
I'm not sure I'd even call that patience. Feels more like relearning something I used to get for free.