The first time I really noticed it, I was running along the river on a Tuesday evening, about three kilometres in, not thinking about anything in particular. A bug I had been chewing on all afternoon, the kind that had me adding print statements to a dbt macro and getting nowhere, suddenly resolved itself in my head. Not as a hint. As a full diagnosis: the macro was being compiled in the wrong context, and I knew which line, and I knew the fix. I had not been thinking about the bug. I had been thinking about my breathing.
I went home, opened the laptop, and the fix took eight minutes. Including the test.
I have since had this experience too many times to keep counting. The architecture decision that sorts itself out while I’m chopping onions for dinner. The right shape for a confusing API that comes to me in the shower. The “oh, that’s what’s wrong with the SQL plan” while I’m walking to the supermarket. None of it is mysterious, or at least, not to me anymore. It is a feature of how brains work. And learning to trust it, and to make space for it, has made me much better at this job than any productivity system ever did.
What’s actually happening
I won’t give a neuroscience lecture, partly because I’d get it wrong. The short version is that your brain has at least two modes of thinking. One is focused: tight, narrow, sequential, the mode you’re in when staring at a stack trace and rebuilding the call graph in your head. The other is diffuse: looser, broader, slower, the mode that runs in the background while your conscious attention is somewhere else.
Focused mode is great for executing a known plan. It’s terrible for finding new ones. The mistake almost everyone makes when stuck on a hard problem is to apply more focused mode: they keep looking at the same code from the same angle, building up tunnel vision and frustration. Diffuse mode is what gives you new angles, because it can hold lots of half-formed ideas in parallel.
The catch is that diffuse mode requires you to be doing something else. Walking. Showering. Running. Doing the dishes. The conscious brain has to be otherwise occupied or pleasantly idle, or it doesn’t kick in. You cannot will yourself into diffuse mode. You can only set up the conditions for it.
I learned this most clearly from Barbara Oakley’s Learning How to Learn course, but the same idea shows up everywhere from working programmers to mathematicians to writers.
Real examples, not mystical ones
I want to be specific about this, because “go for a walk and your bug will solve itself” sounds like the worst kind of LinkedIn post. It isn’t magical. It is mechanical.
A dbt model on Postgres was producing duplicate rows in a downstream table, and I could not find the join that was wrong. I spent an afternoon staring at the SQL and got nowhere. That evening I went for a run, and about halfway through, I realised I had been assuming a particular dimension table was unique on the join key, and it almost certainly wasn’t. The model was fine. The data assumption was wrong. Total active thinking time after the run: maybe ten minutes.
An Airflow DAG was failing with a timeout that didn’t reproduce in any test environment. Two days of logs and metrics got us nowhere. On the Thursday afternoon I went to do groceries, and while queueing for self-checkout, I remembered that the production cluster had different resource limits than staging. The timeout was almost certainly OOM, not network. The next morning we checked, and it was OOM. The two days of staring had been the wrong tool for that problem.
How to protect this time when calendars are aggressive
Here’s where the advice gets harder. Knowing that diffuse mode is real is one thing. Defending the time for it, in a corporate calendar full of meetings and Slack notifications, is another.
A few things I’ve found helpful, none of them revolutionary.
Block time for thinking that isn’t sitting at your desk. I have recurring slots on my calendar that say “Walk, problem X”. I take a walk. I think about the problem in a soft way. If something comes up, I voice-memo it. If nothing comes up, I had a walk. The calendar slot is a forcing function so that the meeting I’d otherwise have accepted gets a polite “I’m in something else, can we move it to Thursday?”.
Stop eating lunch at your desk. Lunch is one of the cleanest diffuse-mode windows in the day. If you spend it answering Slack with one hand and typing with the other, you’ve given up forty-five minutes of free thinking. Five days a week, compounded over a year, that’s a lot of bugs not solved.
Refuse to schedule “thinking work” against meetings. If you have a hard problem this week, find the longest unbroken stretch on your calendar and block it. Title it “deep work, do not book”. Then actually use it for the hard thing, not for catching up on email. The diffuse mode does the unsticking, but the focused mode does the doing. Both need their slot.
Take real breaks, not phone breaks. Doomscrolling Twitter is not a break. It is the same kind of attention-fragmenting task as work, with worse content. A real break is closer to “stare out the window for five minutes”, “make a coffee and drink it without a screen”, “walk around the block once”.
Toxic productivity and the always-at-desk culture
There is a culture in some teams, sometimes called hustle culture, that treats time-not-at-keyboard as time-not-working, and time-not-working as suspect. The engineer who walks at 3pm is goofing off. The engineer at their desk at 7pm is dedicated. The engineer who answers Slack at 22:00 is a team player.
This is, in my experience, almost completely backwards. The engineer who walks at 3pm is doing the work that the engineer at the desk at 7pm is failing to do. The “dedication” of the always-at-desk version is, mostly, the dedication of someone who hasn’t noticed they’re working in the wrong mode for the problem in front of them. They are running focused mode at a problem that needs diffuse mode, the way you might keep pressing harder on a stuck jar lid that needs a different grip. More force is not the answer.
Worse, the always-at-desk pattern actively suppresses diffuse mode in the people around you. If you’re the manager who pings Slack at 22:30, you’ve made it harder for your team to switch off, and “switched off” is precisely the state in which their best work happens. You are paying for the appearance of effort, and you are getting it, while the actual problems remain unsolved on the board.
”Have you tried going for a walk?”
When a junior engineer comes to me stuck, after we’ve talked through the obvious things (have you read the actual error, have you printed the variable, have you reproduced it locally), my next question is usually “have you stepped away from it today?”.
They almost always say no. They almost always look slightly defensive, as if I’m accusing them of slacking off. The opposite. I’m asking because another forty minutes of staring is the worst use of their afternoon, and a twenty-minute walk has roughly a 30% chance of cracking the problem outright and a 70% chance of clarifying which question they should actually be asking.
One thing the junior engineers take a few months to internalise: this works better when you’ve already done the focused-mode work. Diffuse mode does not generate insight from nothing. It rearranges the material your focused mode has loaded into your head. Walk before you’ve looked at the bug, and you’ll think about your shopping list. Walk after two hours of focused investigation, and your brain has something to chew on.
A note on Pomodoros (and the trap of using systems to avoid thinking)
The Pomodoro Technique (twenty-five minutes on, followed by a real break) is genuinely useful. So are deep-work blocks and “no-meeting Wednesdays”. They work because they create rhythm: bursts of focused mode, then proper breaks where diffuse mode can run.
But there’s a failure mode I want to flag, because I’ve fallen into it. It is using productivity systems as a way to avoid actually thinking.
You set up your Notion. You configure your Pomodoro app. You read three blog posts about deep work. You buy a new notebook. By the time you sit down to do the actual work, you are tired, and you reward yourself with a break for having “set up your system”. This is admin cosplaying as deep work. It is seductive, because it feels like progress while requiring none of the discomfort that real thinking requires.
The systems are tools, not goals. If your Pomodoro app helps you concentrate for twenty-five minutes, great. If your system is taking ninety minutes a day to maintain, you’ve built a productivity system that prevents productivity. The minimum viable rhythm is: a few hours of focused effort, real breaks where you do not look at a screen, and a willingness to be away from the keyboard when the problem is being stubborn. The rest is decoration.
Takeaway
The hardest problems in your week will rarely yield to forcing it. They will yield to a walk, a coffee, a night’s sleep, a long shower, a run by the river. This is not laziness, and it is not a productivity hack, it is just how brains work. Your job is to load the problem properly with focused effort, then trust the diffuse mode to do its share of the work, and to refuse to feel guilty about the time when you are not visibly typing. The senior engineers I respect most have made peace with this. They work hard, but they also walk away from problems on purpose, because they have learned that walking away is, sometimes, the work.