Why does not thinking about a bug sometimes help you solve it? [closed]

Question

Yesterday I spent a good part of the afternoon trying to fix a bug, which I thought to be trivial. I was going around in circles, not having a clue what was wrong. Rewriting large parts of the code. Checking on SO. Still no joy.

So I went home, walked the dog, watched a little TV and just before I went to sleep, bingo I realized the obvious mistake I was making. This morning it took about 10 minutes to fix.

While I was home, I wasn't actively thinking about the problem. Yet taking myself out of the situation enabled me to solve it.

It isn't the first time it has happened, and I know that it is a fairly common way to solve a programming problem. I have even heard of people dreaming the answers.

Why does this work?

Perhaps more importantly, is there a good guide as to when you should take a break from a problem, how long should the break be, and after how long does leaving a problem stop being effective?

I suppose I am trying to work out how to optimize this subconscious processing (or whatever is going on)

Answer 1

Being too focused on a problem prevents you from taking a step back. When you debug your code, you tend to needlessly repeat the same tests.

The more you try, the more you fail and you become very frustrated. Increased stress and frustration make things worse.

That's why quite often, a colleague can by chance, look over your shoulder, and point out the problem (and solution) in a few seconds.

They are not in the same mental state as you.

I often try to stop looking after a certain period of time and come back with a calmer mind a few hours later.

But the most powerful technique is just... asking for help.

Answer 2

If you have been working on a problem for some time, your mind follows the patterns you setup during development. In other words, you develop temporary "black spots" for things outside of the mental frame you set up.

Taking your mind off the problem for a while helps removing this filter and allows you to mull things over without the filter in place.

What has often helped me in cases like these is to explain to someone else why it should work (when it doesn't) - normally halfway through your explanation you will realise where you went wrong in your reasoning or which step you missed.

Apart from developing a mental filter during development work, you brain is massively multi-threaded and often keeps going over a problem as part of unconsious processes. I sometimes use this by learning everything I can about a problem in an afternoon, then letting the problem lie for a day or 2 before working on a solution.

Answer 3

I'm not a psychologist, but when you're too concentrated on a single issue (finding the bug) you tend to lose the view for the larger system. But often the answer is not "down there" where you're currently looking for it but in someplace else - that you're not able to see at that point.

So what you really need to do is get out of the trenches and start looking at the whole system from a more general point of view - again. One tends to ignore this fact thinking "I really know it's right here, I just haven't found it yet". It happens to all of us, all the time. I even get to the point where I know "I can't find the bug using a good debugging technique so it has to be somewhere else" and still don't take the right thing and take a break - the human brain is such a funny thing.

However, it really doesn't matrer that much what you do - whether it's going to the bathroom, talking to a coworker or walking the dog. I used to go the a nearby store to buy some candies when I was stuck and as soon as I put my jacket on the solution popped into my head - almost everytime. It may also be a good thing to drink a lot of water during the time you're programming. It forces you to take a break every now and then to visit the bathroom and zap, there is the reason that forces you to break out of the trenches.

Answer 4

From my personal experience and what I've witnessed in the junior developers I train, we all approach a problem with assumptions and expectations. We assume function x does task y to produce result z. It always has, so why should that change? As we focus more and more on a problem, we assume that we've covered the basics and the problem must indeed be much more complicated than when we addressed it originally. Attach fatigue to a growing list of things we assume to be true but have not actually verified, and you set yourself up for a complete "WTF" moment later on.

It's only later when you've disconnected yourself from the problem that the assumptions can be thrown out and retraced. In addition, we usually tackle a problem on the back of a different problem that we just solved. I fixed A but it broke B, now I must fix B. So we already have a momentum and direction we're traveling (which makes our assumptions even harder to disassociate). When you return to solving problem B, problem A is no longer fresh in your mind blocking out potential possibilities. You're able to address the problem without preconceptions, and this opens up new paths of thinking and new angles of looking at the problem.

Now, whenever a junior asks me for help, they know the first question they have to answer is "What are your assumptions?". Even attempting to answer that problem can help remove you from your mental blocks.

Answer 5

I guess your brain, like muscles, gets tired. Taking a break allows it to rest, top up with oxygen/fuel etc and start working again.

Going for a walk or taking exercise is often a good approach when you are really stuck with something. Even if you don't have a "eureka" moment it can often allow you to come back and take a new approach to solve the problem.

Answer 6

I like to call it the incubation time on ideas and problems.

Your sub-conscience still continues to process the problem out of your awareness in a non-linear approach. This is very similar to what happens when you learn something new before you take a nap. Your mind has time to 'defragment' the information into ways that can be approached with greater flexibility.

Also, another helpful tip for overcoming being stuck on a bug, is called confessional de-bugging. This is where you approach another person who does not know the problem and you begin to explain the problem. I find more often than not, that by just saying aloud the problem, the solution comes to mind.

check out these psych links: creativity tips & problem napping

Answer 7

"We all get pricked by a rose sometimes. Sadly when we concentrate so much on the pain we forget about the beauty of the rose."

Answer 8

I fixed several critical bugs in my career, during shower time.

I am not a psychologist but I guess the difference is:

• sitting in front of the computer, I see source codes, breakpoints, printf outputs ...

• in the bathroom, codes run in my mind.

Answer 9

I've experienced the same phenomenon, and attributed it to looking at the problem with a different perspective as I spend time away from it (more time away implies a more distant perspective, approximately).

But there's another trick that I find accomplishes the same thing most of the time: explain the code to a co-worker. It's not for them to catch your bug, although they may; it's to force you to step back and explain the logic of the code at all relevant levels. I've never (though fair warning--sample size is limited) been able to subconsciously solve a bug that escaped this describe-to-coworker treatment.

Answer 10

I've recently been using the pomodoro technique thanks to a suggestion from someone on this site, and think it provides a good answer to your question on timing and lengths of breaks. Basically, it has you work focused on a problem for 25 minutes, followed by a short 3-5 minute break, then a longer break after every 4 cycles of that. They cite some studies to back it up, but anecdotally I've found those intervals very effective.

I had thought the 25-minute spans would keep me from getting "in the zone," which people claim takes 15 minutes or so. On the contrary, with this timing I get in the zone almost immediately. I think that's because it's a lot easier to keep myself from being distracted when I know I only have to keep it up for 25 minutes. It's also easier to postpone external interruptions for only 25 minutes. It was much difficult before when I was trying to buckle down for 4 hours of work before lunch.