The Value Of Walking Away From The Screen

4 minute read

Published:

Programmers have a particular relationship with difficult problems. When something does not work, the instinct is to stay. One more test. One more search. One more change to the configuration. An hour later the problem is unchanged, and the mind is worse equipped to solve it than it was when the session started.

I have lost count of how many times I have found the answer to a problem during a walk, a shower, or the first minutes of trying to sleep. The solution was not hidden in a new search query. It was somewhere I could only reach by stopping.

Two modes of thinking

Cognitive science distinguishes between focused thinking and diffuse thinking. Focused thinking is what happens at the screen — directed attention, active search, deliberate reasoning within a narrow frame. This is necessary and useful. You cannot understand an error message without it.

Diffuse thinking is what happens when attention is released. The mind continues working on a problem without being directed to do so — making connections between concepts that focused attention, by its nature, does not search for. Dreams and the period just before sleep are extreme examples of diffuse thinking. A walk, a shower, or time away from the problem also produce it.

The insight that does not arrive during two hours of focused debugging sometimes arrives during a ten-minute walk, not because the walk is magic, but because the mind was working on the problem in a different mode that focused attention had crowded out.

The specific failure mode that rest prevents

There is a particular trap that extended focused attention creates: you stop seeing what is actually there and start seeing what you expect to be there.

After two hours of looking at the same function, the eye slides past the error it has seen a hundred times without registering it. The assumption that parameter x is always positive has been in your head so long that you have stopped noticing it is an assumption. A possible cause that would have seemed obvious an hour ago is invisible because your model of the problem has solidified around the wrong hypothesis.

A break disrupts this. Returning after twenty minutes, you are no longer inside the same fixed frame. The line that was invisible is suddenly obvious. The assumption that felt like a fact now looks like a question.

This is also why rubber duck debugging works — explaining the problem out loud to an inanimate object forces you to state your assumptions, which is often enough to reveal which one is wrong. The walk achieves something similar: it breaks the frame.

Types of problems and what they need

Not all difficult programming problems benefit equally from stepping away.

A problem that requires finding a specific syntax, understanding a library’s behavior, or tracking down which line produces an error usually responds better to continued searching — or to asking someone who already knows the answer. These are knowledge problems. The answer exists and needs to be retrieved.

A problem that involves the design of something, the right way to structure a relationship between components, the root cause of an intermittent failure, or why a performance issue appears only in certain conditions is more likely to benefit from distance. These are reasoning problems where the frame you are working inside may itself be the obstacle.

The difficult part is recognizing which kind of problem you have, and this becomes harder when frustration and fatigue are accumulating together.

The less glamorous reason to leave the screen

There is also a simpler case for taking breaks that does not require any theory about cognitive modes.

Eyes become tired. The back becomes uncomfortable in ways that worsen gradually without being noticed. Concentration narrows and becomes less capable over time. A person who has been at a screen for six hours without a real break is making worse decisions than they were at hour two — not because the problem became harder, but because the instrument doing the thinking has degraded.

Some problems need more effort. Others need a little distance. Learning to tell the difference, and to act on it before the hour of diminishing returns has already passed, is a real and learnable skill.