What neuroscience reveals about movement, creative thinking, and why stepping away from your screen may help solve difficult problems.
The bug that followed you out the door
(The following scene is fictional. No developers were harmed, though one was mildly humbled)
You’ve been staring at the same function for two hours. You’ve read the documentation twice, the second time more slowly, as if the problem were your reading speed. You’ve added logging, then logging for the logging. You’ve questioned the architecture, then your career, then whether the race condition might be personal.
Eventually you go outside. Not as a strategy. As a surrender.
Six minutes later, waiting at a crosswalk, it arrives: the cache isn’t stale, it’s being warmed by the wrong job. You can see the whole thing. Your laptop, meanwhile, is three blocks away, asleep and smug.
If you’ve ever had an idea arrive after stepping away from a stubborn problem, you know the peculiar timing. The interesting question isn’t whether it can happen. It’s why it sometimes happens just after deliberate searching has stopped, and what that says about how thinking works.
What happens when scientists ask people to walk?
In 2014, Stanford researchers Marily Oppezzo and Daniel Schwartz ran four experiments on a deceptively simple question: does walking change how people generate ideas?
In the first, 48 students sat at a desk facing a blank wall and completed two tasks. One was the Alternate Uses test: list as many uses as possible for an object, like a button or a tire, in four minutes. The other was the Compound Remote Associates test: find the one word that links three others (“cottage, Swiss, cake” → cheese). Then they stepped onto a treadmill, also facing a blank wall, because science is glamorous, and did new versions of both tasks at a comfortable pace.
The results split cleanly. In the first experiment, 81% of participants generated more creative responses while walking than while sitting, counting only ideas that were both novel and appropriate. Across participants, creative output rose by roughly 60% on average. Walkers talked more overall, but the proportion of their ideas that counted as creative also rose, so the effect wasn’t simply a matter of volume. On the remote-associates test, the one with a single correct answer, walking made performance slightly worse.
That asymmetry is the most useful finding in the paper. Walking didn’t make people smarter. It seemed to loosen the flow of candidate ideas while mildly hurting a tightly constrained search for one right answer.
Later experiments tackled the obvious objections. Practice didn’t explain the effect: people who sat twice didn’t improve. People who walked and then sat down kept much of the boost. Walking outdoors worked too, although nine participants had to be excluded after being ambushed by bikes, loud trucks, and, in one case, their own phone, which may be the most realistic detail in the literature. In the final experiment, participants generated analogies while sitting indoors, walking on a treadmill, walking outside, or being pushed outside in a wheelchair. For the highest-quality novel analogies, walking mattered and scenery didn’t. For novelty defined more loosely, walking and being outdoors each contributed separately.
The caveats are part of the story. The last two experiments had about ten people per condition. Participants spoke their answers aloud to a friendly researcher, and the authors themselves asked whether the effect would hold on a solitary walk. Follow-up studies are mixed. A 2017 study found that walking beat standing on two different idea-generation tasks. A 2018 study, in which 32 students walked for 15 minutes before testing, found no significant difference from sitting on any creativity measure. And naming unusual uses for a tire is not designing a schema migration. These studies measured idea generation in a lab, not programming performance anywhere.
Your brain has more than one way to work
The split between generating and evaluating matters because software work constantly alternates between them. Sketching three approaches to a rate limiter is generative. Confirming that the one you chose doesn’t double-count requests under concurrency is evaluative. Both are thinking. They are not the same kind.
Neuroscience offers a suggestive picture, not a definitive one. Psychologist Roger Beaty and colleagues reviewed imaging studies of tasks ranging from divergent thinking to poetry and musical improvisation. They noted a recurring pattern: two brain networks that often work in opposition tend to cooperate during creative tasks. One is the default network, linked to internally directed thought such as memory and imagination. The other is the executive control network, linked to goal-directed attention. A 2018 study of 163 people found that connectivity among default, salience, and executive systems predicted individual divergent-thinking scores, a pattern that held up in independent datasets.
These findings are correlational. They describe brain activity and individual differences rather than proving a mechanism, and none of them involved walking. Networks are also not departments with job descriptions. There is no creativity center, no right-hemisphere art studio, no switch that boosts creativity by turning focus off. If anything, the evidence suggests creative thought involves coordination between spontaneous and controlled processes, not the absence of control.
Why the shower gets all the good ideas
The shower has never installed a compiler. Yet it gets credit for a remarkable number of fixes.
Researchers call this incubation: setting a problem aside before returning to it. A 2009 meta-analysis by Ut Na Sio and Thomas Ormerod, pooling 117 studies, found a real but conditional effect. Open-ended, divergent-thinking problems benefited more than insight puzzles with a single answer. Longer preparation before the break was associated with larger incubation effects, which suggests the work done before stepping away matters, not just the break itself. The break’s contents mattered too. Demanding activities tended to shrink the benefit, while for one class of word-based insight problems, light activity beat pure rest.
A 2012 experiment led by Benjamin Baird seemed to explain why. Participants worked on unusual-uses problems, then spent 12 minutes on one of three breaks: a demanding memory task, an undemanding one, or rest. A fourth group took no break. The undemanding group improved substantially, but only on problems they had already seen. They also reported more mind-wandering, without reporting more deliberate thought about the task. Mind-wandering, it seemed, was doing the work.
Then came the replication attempts. In a 2016 series of studies, mind-wandering measured during the break didn’t predict creative performance. A later conceptual replication with 443 participants found no evidence that mind-wandering during an incubation break improved divergent thinking. Stepping away can help. The claim that a wandering mind is what makes it help is on much shakier ground.
Why breaks sometimes work remains unsettled. Candidate explanations include escaping fixation on a wrong approach, continued associative processing, and picking up new cues. These are hypotheses. Nothing here shows your unconscious quietly closing tickets while you rinse out shampoo.
A walk is not a debugger
Back to the crosswalk. The cache-warming idea felt like certainty. Feelings of certainty are cheap.
A walk might help you consider that the bug lives in a background job rather than the request path. It cannot tell you whether that job actually runs before the cache is read, whether your fix creates a thundering herd, or whether the elegant refactor you imagined survives the forty edge cases your tests encode. Recall the remote-associates result: the condition that helped idea generation slightly hurt the task with one correct answer.
The useful model isn’t “focus bad, wandering good.” It’s a cycle. Sustained attention loads the problem: reading traces, building a mental model, ruling things out. A change of mode may let alternatives surface. Then focus returns to test them. Skip the first phase and the walk has nothing to work with. Skip the last and you’ve merely had a nice idea.
The productivity paradox
Here’s the uncomfortable part. Most workplaces can see only one of those phases.
Typing is visible. Commits are countable. Green status dots are reassuring. Twenty minutes spent staring out a window and reframing a problem looks, from outside, exactly like twenty minutes of not working.
Researchers who study developer productivity have pushed back on single-metric thinking. The SPACE framework, from Nicole Forsgren and colleagues, argues that productivity spans several dimensions and can’t be captured by activity levels alone. That doesn’t prove walks make teams faster; nobody has shown that. It does suggest that “looks busy” is a weak proxy for “is making progress.”
Picture two developers. One types steadily all afternoon, iterating on the same wrong assumption. The other walks for twenty minutes and comes back with a better hypothesis. Neither outcome is guaranteed, and this is an illustration, not data. But a culture that rewards only the first pattern is measuring motion and calling it thought.
When stepping away doesn’t help
Sometimes a walk is just a walk.
If you’re missing information, like an undocumented API behavior or a log you haven’t found, no amount of incubation will conjure it. If the work demands careful verification, such as reviewing a security-sensitive change or reasoning about a memory model, nothing in this research suggests a stroll will help. Some problems want a profiler, a teammate, or a methodical bisect through commits.
The effects themselves are variable. Incubation depends on the task, the preparation, and the break. Single bouts of exercise tend to produce small cognitive effects that shift with duration, intensity, and task type. Those short-term effects are a separate question from the long-term benefits associated with regular physical activity, which come from a different body of research. None of it adds up to a prescription.
The best idea may arrive after you close the laptop
Our fictional developer walks home, opens the laptop, and writes a failing test for the cache-warming theory. It fails exactly as predicted. The fix takes eleven minutes. This time the theory was right. Next time it might not be, and the test will say so.
The walk didn’t solve the bug. It changed the developer’s relationship to the problem long enough for a different explanation to surface. The solving still happened at the keyboard.
Maybe the mistake isn’t that developers spend too much time thinking. Maybe it’s that we’ve defined thinking so narrowly that we only recognize it when it’s typing.
Sources and Further Reading:
Walking and creative thinking
Oppezzo, M., & Schwartz, D. L. (2014). Give your ideas some legs: The positive effect of walking on creative thinking. Journal of Experimental Psychology: Learning, Memory, and Cognition, 40(4), 1142–1152. https://doi.org/10.1037/a0036577
Zhou, Y., Zhang, Y., Hommel, B., & Zhang, H. (2017). The impact of bodily states on divergent thinking: Evidence for a control-depletion account. Frontiers in Psychology, 8, 1546. https://doi.org/10.3389/fpsyg.2017.01546
Frith, E., & Loprinzi, P. D. (2018). Experimental effects of acute exercise and music listening on cognitive creativity. Physiology & Behavior. https://doi.org/10.1016/j.physbeh.2018.03.034
Incubation and mind-wandering
Sio, U. N., & Ormerod, T. C. (2009). Does incubation enhance problem solving? A meta-analytic review. Psychological Bulletin, 135(1), 94–120. https://doi.org/10.1037/a0014212
Baird, B., Smallwood, J., Mrazek, M. D., Kam, J. W. Y., Franklin, M. S., & Schooler, J. W. (2012). Inspired by distraction: Mind wandering facilitates creative incubation. Psychological Science, 23(10), 1117–1122. https://doi.org/10.1177/0956797612446024
Smeekens, B. A., & Kane, M. J. (2016). Working memory capacity, mind wandering, and creative cognition: An individual-differences investigation into the benefits of controlled versus spontaneous thought. Psychology of Aesthetics, Creativity, and the Arts. https://doi.org/10.1037/aca0000046
Murray, S., Liang, N., Brosowsky, N., & Seli, P. (2024). What are the benefits of mind wandering to creativity? Psychology of Aesthetics, Creativity, and the Arts, 18(3), 403–416. https://doi.org/10.1037/aca0000420
Brain networks
Beaty, R. E., Benedek, M., Silvia, P. J., & Schacter, D. L. (2016). Creative cognition and brain network dynamics. Trends in Cognitive Sciences, 20(2), 87–95. https://doi.org/10.1016/j.tics.2015.10.004
Beaty, R. E., Kenett, Y. N., Christensen, A. P., Rosenberg, M. D., et al. (2018). Robust prediction of individual creative ability from brain functional connectivity. PNAS, 115(5), 1087–1092. https://doi.org/10.1073/pnas.1713532115
Exercise and cognition
Chang, Y. K., Labban, J. D., Gapin, J. I., & Etnier, J. L. (2012). The effects of acute exercise on cognitive performance: A meta-analysis. Brain Research, 1453, 87–101. https://doi.org/10.1016/j.brainres.2012.02.068
Erickson, K. I., Hillman, C., Stillman, C. M., et al. (2019). Physical activity, cognition, and brain outcomes: A review of the 2018 Physical Activity Guidelines. Medicine & Science in Sports & Exercise, 51(6), 1242–1251. https://pubmed.ncbi.nlm.nih.gov/31095081/
Developer productivity
Forsgren, N., Storey, M.-A., Maddila, C., Zimmermann, T., Houck, B., & Butler, J. (2021). The SPACE of developer productivity. ACM Queue, 19(1), 20–48. https://queue.acm.org/detail.cfm?id=3454124
Top comments (8)
What a great reminder that software engineering is as much about managing cognitive processes as it is about writing code. One of the most important points here is the distinction between generating ideas and evaluating them. We often treat problem-solving as one continuous activity, assuming that staring at the code longer will eventually produce a breakthrough. But creative thinking and analytical verification are different modes of cognition, and effective engineering requires both.
I've noticed that some of the hardest technical problems aren't necessarily solved by writing more code, but by challenging the assumptions that led us down the wrong path in the first place. When we're deeply focused on an implementation, we can become attached to a particular mental model. Every new piece of evidence gets interpreted through that model, and we end up optimizing a solution to the wrong problem. Stepping away can create enough mental distance to recognize an alternative explanation.
I particularly appreciate that the article doesn't romanticize mind-wandering or suggest that walking is some magical debugging technique. The research is nuanced: walking appears to support divergent thinking more consistently than tasks requiring a single correct answer, while incubation benefits depend on the nature of the problem and what happens before and during the break. That's an important distinction. A walk cannot replace understanding the system, reading logs, investigating dependencies, or validating a hypothesis with tests.
For developers, I think the practical takeaway is to deliberately alternate between two modes:
Focused exploration: Understand the problem, inspect the evidence, trace dependencies, and build a reliable mental model.
Unstructured reflection: Step away, let go of the current implementation, and allow alternative explanations or approaches to emerge.
Critical validation: Return to the problem, challenge the new ideas, write tests, measure behavior, and verify the solution.
There's also an important cultural implication here. If engineering productivity is measured primarily through commits, lines of code, pull requests, or visible keyboard activity, we risk incentivizing constant execution over thoughtful problem-solving. Sometimes the most valuable contribution a developer makes in an hour is realizing that the team has been solving the wrong problem for three days.
I'd add one more thought: knowing when to stop thinking about a problem is itself an engineering skill. Experience isn't just about recognizing familiar patterns faster; it's also about recognizing when your current approach has stopped producing useful information and when a change of perspective is needed.
Ultimately, the best developers aren't necessarily the ones who spend the most time coding. They're the ones who know when to focus deeply, when to step back, and when to return with a better question.
Sometimes the most productive thing you can do for your code is temporarily stop looking at it.
This is such a fantastic read! The connection between neuroscience, creativity, and everyday software development is genuinely fascinating. I especially love the idea that stepping away from the screen isn't necessarily wasted time, but can be an essential part of the problem-solving process. The distinction between generating ideas and evaluating them is particularly insightful. We often measure productivity by how much time we spend typing, committing, and shipping, while overlooking the thinking that makes those actions meaningful. A refreshing reminder that sometimes the best way to move forward is to take a step back. Brilliantly written and backed by some excellent research! 👏
The part that stuck with me is the “load → step away → test” cycle, especially the point that preparation matters. The Sio & Ormerod finding that longer pre-break work was linked to bigger incubation effects suggests a small habit: before you leave, write down what you’ve ruled out, what you still suspect, and the one question you couldn’t answer. Two minutes of that makes the first phase deliberate instead of accidental, and it gives you something concrete to test when you sit back down. It also guards against the “feeling of certainty is cheap” problem you flagged, because the note turns the crosswalk insight into a hypothesis you can check against what you’d already eliminated. Has anyone tried this? I’d be curious whether it changes how often the post-walk idea survives contact with a failing test.
I appreciated that you led with the remote-associates result, where walking slightly hurt the one-right-answer task. Debugging is a strange hybrid. Forming a hypothesis is divergent, but confirming it is as convergent as work gets. That makes me wonder whether the benefit comes from the walk itself or from the context switch and escape from fixation, which a shower, a coffee line, or explaining the problem to a colleague might provide just as well. The studies you cite can’t separate those, and I suspect most developers can’t either. Practically, it may not matter much, but it affects the advice. “Walk more” is a narrower claim than “break fixation deliberately,” and the second probably covers more of the situations where we get stuck.
This is such a refreshing perspective on productivity, especially in a profession where being busy is often mistaken for being productive. One of the most important points in this article is the distinction between generating ideas and evaluating them. Developers spend so much time trying to force solutions through sustained concentration that we sometimes forget creativity and analytical verification are two different cognitive processes.
I particularly appreciated the discussion of the Stanford walking experiments. The finding that walking improved divergent thinking while slightly reducing performance on tasks requiring one precise answer is fascinating. It reinforces the idea that stepping away isn't necessarily about thinking less; it's about allowing the mind to approach a problem differently. Sometimes we're so attached to our original assumptions that additional screen time only reinforces the wrong direction.
The incubation discussion is equally valuable. I think there's an important lesson in the observation that preparation matters before taking a break. Walking away after genuinely investigating a problem is very different from avoiding the work altogether. You've already supplied your mind with information, constraints, and possible explanations. A change of activity can create the opportunity to reconsider those connections without continually forcing the same line of reasoning.
Another point that really resonated with me is the workplace productivity paradox. We can measure commits, tickets, typing activity, and hours spent online, but those measurements don't necessarily capture the quality of someone's thinking. A developer who spends fifteen minutes reconsidering an architectural decision might save an entire team several days of unnecessary implementation and rework.
My biggest takeaway is that productive thinking doesn't always look productive from the outside. Deep concentration, deliberate disengagement, creative exploration, and rigorous verification all have their place. The real skill is knowing when to switch between them.
Perhaps the best developers aren't necessarily those who spend the longest time staring at their screens, but those who understand when to engage deeply, when to step back, and when to return with a better question. Excellent article and a much-needed reminder that sometimes the most productive thing we can do is give our brains room to work.
I love how this article challenges the assumption that problem-solving must happen continuously and visibly to count as meaningful work. The fictional developer's experience is particularly relatable because anyone who has spent hours debugging a stubborn issue knows how easily concentration can turn into fixation. Sometimes we aren't getting closer to the solution; we're simply becoming more familiar with the same incorrect assumption.
What I found especially insightful is the article's refusal to oversimplify the neuroscience into a catchy message about walking magically making us smarter. The distinction between divergent and convergent thinking is crucial. Generating several possible explanations for a race condition requires a different mental approach from proving which explanation is actually correct. Walking may help expand the possibilities, but testing, debugging, and careful reasoning remain essential.
I also think the connection between incubation and cognitive flexibility deserves more attention in software development. When we're deeply focused on a problem, we can become anchored to a particular implementation or interpretation of the available evidence. Stepping away can help loosen that attachment. We may return with a completely different perspective, notice an overlooked dependency, or recognize that the original problem statement was based on a faulty assumption.
There's also a practical lesson here for engineering managers and team leaders. If developers are evaluated exclusively through visible activity, organizations risk discouraging the very thinking that produces better technical decisions. Not every valuable contribution appears as a commit or completed ticket. Sometimes it's recognizing that an implementation should never have been pursued in the first place. That kind of judgment can prevent technical debt, reduce unnecessary complexity, and improve long-term maintainability.
One distinction I'd emphasize is that stepping away should complement disciplined engineering rather than replace it. A walk can produce a promising hypothesis, but a failing test, reproducible example, profiler, or code review must establish whether that hypothesis holds up. The strongest workflow combines exploration with evidence.
My favorite underlying message is that productivity isn't measured by how continuously we use our tools, but by how effectively we use our minds. We need focused effort to understand difficult problems, mental space to explore alternatives, and disciplined verification to turn promising ideas into reliable solutions.
This is a valuable reminder that sometimes changing our environment is exactly what helps us change our perspective. Great read!
What a brilliant and refreshing perspective on creativity and problem-solving! I especially love how you connect neuroscience research with the everyday realities of software development, showing that stepping away isn't procrastination but can be an important part of the thinking process. Your distinction between generating ideas and evaluating them is particularly insightful. The reminder that a walk may help us discover a new hypothesis, but testing and verification still happen at the keyboard, is spot on. Excellent research, engaging storytelling, and a wonderfully practical message for every developer. Outstanding work! 👏💡
Absolutely fascinating and exceptionally well explained! Your exploration of walking, incubation, and mind-wandering makes a compelling case for giving our brains room to work beyond the screen. I particularly appreciate your balanced treatment of the research, including its limitations and mixed findings, rather than presenting walking as some magical solution to every coding problem. The connection to developer productivity is especially powerful: visible activity isn't always meaningful progress, and some of our best breakthroughs happen when we stop forcing an answer. A thoughtful, scientifically grounded reminder that great programming requires not just focused effort, but also space to reflect, imagine, and see problems differently. Thank you for this excellent read! ❤️👏