7 ms·

Walk Away From Your Computer. Seriously.

121 points by kcurtin 15y ago

dorkitude 15y ago
Absolutely valid. When I'm doing something difficult, nothing is more important than giving my subconscious some time to work out a problem.
- kcurtin 15y ago
  I'd be interested to learn more about the psychology behind this and why our minds work this way..
  - sp332 15y ago
    Physically stepping backwards increases cognitive function. http://psycnet.apa.org/psycinfo/2009-06873-006 http://psycnet.apa.org/psycinfo/2009-06873-006 (full PDF http://www.aromatiseren.nl/cms/Uploads/manuscript_psychscience%5B1%5D.pdf http://www.aromatiseren.nl/cms/Uploads/manuscript_psychscien... ) The hypothesis is that stepping back is associated with avoidance, and that makes the brain more aware.
  - hasanove 15y ago
    There is a good book - "Your Brain at Work" by David Rock - explaining this (and many other things) http://www.amazon.com/Your-Brain-Work-Strategies-Distraction/dp/0061771295 http://www.amazon.com/Your-Brain-Work-Strategies-Distraction...
wccrawford 15y ago
When I first started programming, I wasn't able to do this. Walking away meant I kept thinking about it. Trying to go to bed was impossible. I -needed- to solve the problem before I could sleep. Now, if I get frustrated, I'm much more likely to walk away and do other things and come back with a fresh mind later. It has almost always been helpful.
- 3pt14159 15y ago
  This is exactly what I came to say. I usually end up cooking food.
  - deleted 15y ago
    [deleted]
FuzzyDunlop 15y ago
I'd say this wasn't counterintuitive nor particularly abnormal. Sometimes you can, for whatever reason, get so close to something - a project, a situation, a problem, a case, etc. - that you get tunnel vision and fail to appreciate the bigger picture. That's just a product of focus, determination, and ambition, I think. Once you step out of that tunnel and focus on something else, you can release the frustration you had before and return to the problem with a clear mind and even a totally fresh outlook. The problem doesn't matter as much as your own wellbeing, so there's no point in stressing yourself out over one when there are million other things you could be doing. Such a laid back approach may allow you to be more productive, hence in that case it would be intuitive.
mnutt 15y ago
While solving problems on your own is a great way to learn things, another solution to this is to just talk to someone. They don't have to be an expert in the field, they just need to be there for you to confirm your base assumptions are sound. In fact, often the act of explaining the problem to them will force you to think through your problem differently, leading to the solution. Like Kent Beck said, "Once a problem is described in sufficient detail, its solution is obvious."
- kcurtin 15y ago
  Someone suggested the same thing over on my blog - it definitely makes sense, I just didn't think to apply it to programming. When I proofread papers it always helps to have someone around to read outloud to - things that seemed great in my head end up sounding completely different. I can see this applying to code as well.
ch0wn 15y ago
This is such an important advice, it can't be repeated often enough. I can't even count the times making break helped me solve a problem in minutes that I tried before for hours.
sophacles 15y ago
Tangential to the main point: The OP just learned a valuable lesson in what computers actually do. The single char oops is usually programmers' first insight into what it really means when we say "computers do exactly what they are told nothing more or less". This is one of those things we all have had frustrate us to no end. Similar mistakes abound, and are one of the those things that cause a lot of people to give up on the programming thing all together. Here's a real kicker about it: they don't stop with experience, we just get better at noticing them faster. For example about 2 years ago -- 5 years into a programming career and 12 years into programming in general, I had this code give me trouble: // C Code: if (test_fails) do_crashy_thing(); So I decided to throw a quick printf in there (the situation was such that learning the debugging tools available to me would take a couple weeks, so printf was my quick solution here). I should note that I hade been working heavily in python for the preceding 3 months. My code looked like this now: // C Code: if (test_fails) log("info about test"); do_crashy_thing(); Which caused my code to crash every time instead of sometimes. C coders will know that multi-statement conditionals need to be wrapped in { } but single statement ones don't. Further python if statements are indent scoped. The recent python work sort of made me blind to the problem in the code. After 3 days of WTFing, talking to the rubber duck, and so on, I called over a colleague and he pointed out the mistake in something like 40 seconds. A younger me would have been embarrased, but this just happens in programming. My point is: these things happen, and I'm glad to see a blog post about this, without the demoralization that normally comes with it. I think it should be more openly discussed in tutorials and other newb oriented posts. A few tips for anyone who is experiencing this sort of thing and not sure what to do: Get a rubber duck (or whatever) and start employing the rubber-duck debugging technique: http://en.wikipedia.org/wiki/Rubber_duck_debugging http://en.wikipedia.org/wiki/Rubber_duck_debugging it really helps! Be willing to include colleagues early and often. Experienced programmers understand and won't think less of you. Doubly so if you are new. (The will tease you a bit about it, but in that shared experienced bonding way, not in the "mock the outsider" way). Realize that as you are chasing the bug by getting down and dirty with other bits of the program, you aren't wasting time, you are most likely fixing other bugs that would have otherwise just manifested later anyway.
- jebblue 15y ago
nphase 15y ago
I have lost track the number of times where my coworkers and I will be pounding our heads on our desks for hours to find a solution to a problem, only to find the solution in the middle of a bathroom break. Walking away is critical to any creative process.
Aviwein77 15y ago
I completely agree with this, countless times it has been variables with the slightly wrong name, or forgetting to upload on filezila, or one of many small mistakes that afterwards seem obvious but cause a lot of frustration. One comment that I saw on the original thread was talking to people. I wanted to highlight this because it has helped me more times than anything else. Even explaining step by step what my program should do to my girlfriend, who has very little computer expertise in general and usually gives me a blank stare, can help a lot. I remember finding an image on reddit a while back of a programmer laboring over his code for hours only to find a greater than which was supposed to be a less than sign, my thought was 'a mistake we will all learn again and again'.
ocharles 15y ago
I, like the rest of the commenter's here, do certainly agree that a break can be all you need. However, I think the OP is missing a valuable lesson, which is that not only should they focus on getting the code to work they need to understand what was wrong and importantly - how to spot the symptoms that it was wrong. In this case, it was a misnamed variable. It's great that that's been fixed, but it's very easy to go hurtling on into the next problem. A few minutes of reading the error message again (and perhaps trying to cause it somewhere else in purpose) goes along way in building up a much more reactive way of working.
- kcurtin 15y ago
  I may start keeping a notebook next to my computer with a list of common error messages I encounter.
- pmr_ 15y ago
  Also the process showed him his lack of knowledge very clearly: He can't read error messages. This is an useful skill in every language although it transfers not at all to any other activity (even reading compiler messages of a different vendor). Especially since this was a common error it is important to realize it early and fast. You just can't go to sleep every time you have a typo. OP only sees the immediate solution (insofar just waiting for a flash of genius counts as a solution) but no the actual error.
espeed 15y ago
He's right, the "walking away" trick does work wonders some time. It gets you to relax, take a step back, and see the big picture. The other aspect to this is reliance on Google. This is part stood out to me... I start to panic a little bit...I turn to google hoping for a quick fix and copy/paste one of my error messages into the search box. Unless Ruby/Rails error messages these days are completely anemic (I haven't worked with Rails in a while), then the line number and error message should provide enough clues to debug a misspelling without having to go to Google. Trust your analytic abilities -- it will keep you from that "panic" state. Instead of seeing an error and panicking, be like Stanley Moss in Wag the Dog -- "This is nothing" :) Eventually you'll get to a point like Paul Graham where debugging relaxes you: I like debugging: it's the one time that hacking is as straightforward as people think it is. You have a totally constrained problem, and all you have to do is solve it. Your program is supposed to do x. Instead it does y. Where does it go wrong? You know you're going to win in the end. It's as relaxing as painting a wall. Source: http://www.paulgraham.com/hp.html http://www.paulgraham.com/hp.html
hugh3 15y ago
Sometimes I feel compelled to take a one-year break from all computers. But I know that if I did, I'd just feel compelled to blog about it.
- zokier 15y ago
  oblig http://xkcd.com/77/ http://xkcd.com/77/
  - sneak 15y ago
    Referencing two-digit xkcd comics in 2011 feels like the internet meme equivalent of a three-point-shot. FROM DOWNTOWN!
TWSS 15y ago
As a UI designer, this is something I need to tattoo on my forearm. Sometimes I'll spend so long banging my head against a problem that my bike-racer colleague will take me aside and remind me of the principles of overtraining. Of course, I ignore him 80% of the time because I can't stand to step away from a problem before it's solved, but he's always right.
reinhardt 15y ago
<half-trolling>Seems like that in this case the lesson should have been to use a statically typed language instead.</half-trolling> (PS: dyed in the wool Python guy here)
- Groxx 15y ago
  Unless they were doing something exceedingly strange, they should've gotten the same kind of runtime error (undefined variable) as any statically-typed (or even compiled) language would have told them. Ruby crashes if you try to read from something that isn't defined.
Groxx 15y ago
Um, very true, but this would also be a sign that they need to read their stack traces / test outputs, and probably try a debugger. Seriously. Debugger. For tests, it's as simple as `gem install rdebug` and put `debugger` in the failing test(s). When it stops on that line, type `eval instance_variables`, and viola - your array contains "@microposts" and not "@micropost". Running it against a full Rails application, especially with, say, Passenger, is a bit trickier, but it's still worth the initial effort.
- mhartl 15y ago
  Thanks for the tip. I'll plan to cover this technique in the next version of the Rails Tutorial.
aorshan 15y ago
This is absolutely true. One of the most important lessons I ever learned in English class was to walk away. Always give yourself a day between when you write something and when you edit it. You come back fresh and with a new perspective.
parallel 15y ago
I think the key here is the low quality work at the end of the day. I often knock off when I detect that I'm running at a very low productivity rate. Invariably the next day the overwhelming and seemingly massive task from the night before takes just a few minutes for the well rested brain. There's also something about the "self control as a finite resource" that comes in to play here.
sneak 15y ago
Two things to add: 1. As one of the article commenters pointed out: "git diff". Seriously. 2. One of the best things I ever did was to buy a weight bench/barbell. When I do my twice-an-hour "walk away for five minutes" routine, I go and do 20 bicep curls or bench presses. I solve problems faster and also improve my health/strength. Win/win!
frankwiles 15y ago
I solve more problems taking a walk (to get coffee, fill my meter, or just walk) than staring at the screen for the same period of time. Often, walking around doing nothing, getting your mind off the problem is the answer. Hence why you often hear great stories that start off "So I was in the shower yesterday..." and rarely hear great stories that start off "So I stayed at my desk for an additional two hours..."
trocker 15y ago
The comments reading seems to diverge from the main post, but was fun reading anyway. When I face the same problem and when my head is full of all the noisy - "why is this thing not working, I think I did everything right" s - I stroll around, walk a mile or two - have some coffee there at some store - look at the people there and think - 'what is running on their mind? Not a buggy code,I guess' - and then come back, stare at the screen and voila! there it is! An insignificant pesky ';' was missing! So, yes, walk away from your computer. What you and your computer have is a relationship and you need to spend some time apart to realize what you're missing in there.And to get it to work. ;)
devraj 15y ago
I have never, in 20 years of programming, ever made this mistake; nor have I ever had to fix a bug that was caused by it. I generally do insert the braces anyway on the basis of almost a cargo-cult theory that someone else might make this mistake, but only because of received wisdom floating around on newsgroups an the like.
- MostAwesomeDude 15y ago
  If only all programmers could be as great as you. You are truly an inspiration to us all. Edit: I think you meant to reply to the guy talking about braces, not the parent article talking about typos.
- DeusExMachina 15y ago
  This is a copy and paste of another comment in this thread, that was referring to something completely different: http://news.ycombinator.com/item?id=3036988 http://news.ycombinator.com/item?id=3036988 Is this some sort of spam account trying to get karma?
DanielShir 15y ago
Quite true, which is why you should stop banging your head against the monitor at 3AM, sleep a little and solve that bug in 30 seconds in the morning. I must admit this is very controversial among startups I've worked in, as the policy is usually along the lines of "no one goes home until this works". Good thing I have my own company now, and bugs are only solved by programmers that are "fresh" :)

121 points by kcurtin 15y ago

Absolutely valid. When I'm doing something difficult, nothing is more important than giving my subconscious some time to work out a problem.

kcurtin 15y ago
I'd be interested to learn more about the psychology behind this and why our minds work this way..
- sp332 15y ago
  Physically stepping backwards increases cognitive function. http://psycnet.apa.org/psycinfo/2009-06873-006 http://psycnet.apa.org/psycinfo/2009-06873-006 (full PDF http://www.aromatiseren.nl/cms/Uploads/manuscript_psychscience%5B1%5D.pdf http://www.aromatiseren.nl/cms/Uploads/manuscript_psychscien... ) The hypothesis is that stepping back is associated with avoidance, and that makes the brain more aware.
- hasanove 15y ago
  There is a good book - "Your Brain at Work" by David Rock - explaining this (and many other things) http://www.amazon.com/Your-Brain-Work-Strategies-Distraction/dp/0061771295 http://www.amazon.com/Your-Brain-Work-Strategies-Distraction...

wccrawford 15y ago

When I first started programming, I wasn't able to do this. Walking away meant I kept thinking about it. Trying to go to bed was impossible. I -needed- to solve the problem before I could sleep. Now, if I get frustrated, I'm much more likely to walk away and do other things and come back with a fresh mind later. It has almost always been helpful.

3pt14159 15y ago
This is exactly what I came to say. I usually end up cooking food.
- deleted 15y ago
  [deleted]

FuzzyDunlop 15y ago

I'd say this wasn't counterintuitive nor particularly abnormal. Sometimes you can, for whatever reason, get so close to something - a project, a situation, a problem, a case, etc. - that you get tunnel vision and fail to appreciate the bigger picture. That's just a product of focus, determination, and ambition, I think. Once you step out of that tunnel and focus on something else, you can release the frustration you had before and return to the problem with a clear mind and even a totally fresh outlook. The problem doesn't matter as much as your own wellbeing, so there's no point in stressing yourself out over one when there are million other things you could be doing. Such a laid back approach may allow you to be more productive, hence in that case it would be intuitive.

mnutt 15y ago

While solving problems on your own is a great way to learn things, another solution to this is to just talk to someone. They don't have to be an expert in the field, they just need to be there for you to confirm your base assumptions are sound. In fact, often the act of explaining the problem to them will force you to think through your problem differently, leading to the solution. Like Kent Beck said, "Once a problem is described in sufficient detail, its solution is obvious."

kcurtin 15y ago
Someone suggested the same thing over on my blog - it definitely makes sense, I just didn't think to apply it to programming. When I proofread papers it always helps to have someone around to read outloud to - things that seemed great in my head end up sounding completely different. I can see this applying to code as well.

ch0wn 15y ago

This is such an important advice, it can't be repeated often enough. I can't even count the times making break helped me solve a problem in minutes that I tried before for hours.

sophacles 15y ago

Tangential to the main point: The OP just learned a valuable lesson in what computers actually do. The single char oops is usually programmers' first insight into what it really means when we say "computers do exactly what they are told nothing more or less". This is one of those things we all have had frustrate us to no end. Similar mistakes abound, and are one of the those things that cause a lot of people to give up on the programming thing all together. Here's a real kicker about it: they don't stop with experience, we just get better at noticing them faster. For example about 2 years ago -- 5 years into a programming career and 12 years into programming in general, I had this code give me trouble: // C Code: if (test_fails) do_crashy_thing(); So I decided to throw a quick printf in there (the situation was such that learning the debugging tools available to me would take a couple weeks, so printf was my quick solution here). I should note that I hade been working heavily in python for the preceding 3 months. My code looked like this now: // C Code: if (test_fails) log("info about test"); do_crashy_thing(); Which caused my code to crash every time instead of sometimes. C coders will know that multi-statement conditionals need to be wrapped in { } but single statement ones don't. Further python if statements are indent scoped. The recent python work sort of made me blind to the problem in the code. After 3 days of WTFing, talking to the rubber duck, and so on, I called over a colleague and he pointed out the mistake in something like 40 seconds. A younger me would have been embarrased, but this just happens in programming. My point is: these things happen, and I'm glad to see a blog post about this, without the demoralization that normally comes with it. I think it should be more openly discussed in tutorials and other newb oriented posts. A few tips for anyone who is experiencing this sort of thing and not sure what to do: Get a rubber duck (or whatever) and start employing the rubber-duck debugging technique: http://en.wikipedia.org/wiki/Rubber_duck_debugging http://en.wikipedia.org/wiki/Rubber_duck_debugging it really helps! Be willing to include colleagues early and often. Experienced programmers understand and won't think less of you. Doubly so if you are new. (The will tease you a bit about it, but in that shared experienced bonding way, not in the "mock the outsider" way). Realize that as you are chasing the bug by getting down and dirty with other bits of the program, you aren't wasting time, you are most likely fixing other bugs that would have otherwise just manifested later anyway.

jebblue 15y ago

nphase 15y ago

I have lost track the number of times where my coworkers and I will be pounding our heads on our desks for hours to find a solution to a problem, only to find the solution in the middle of a bathroom break. Walking away is critical to any creative process.

Aviwein77 15y ago

I completely agree with this, countless times it has been variables with the slightly wrong name, or forgetting to upload on filezila, or one of many small mistakes that afterwards seem obvious but cause a lot of frustration. One comment that I saw on the original thread was talking to people. I wanted to highlight this because it has helped me more times than anything else. Even explaining step by step what my program should do to my girlfriend, who has very little computer expertise in general and usually gives me a blank stare, can help a lot. I remember finding an image on reddit a while back of a programmer laboring over his code for hours only to find a greater than which was supposed to be a less than sign, my thought was 'a mistake we will all learn again and again'.

ocharles 15y ago

I, like the rest of the commenter's here, do certainly agree that a break can be all you need. However, I think the OP is missing a valuable lesson, which is that not only should they focus on getting the code to work they need to understand what was wrong and importantly - how to spot the symptoms that it was wrong. In this case, it was a misnamed variable. It's great that that's been fixed, but it's very easy to go hurtling on into the next problem. A few minutes of reading the error message again (and perhaps trying to cause it somewhere else in purpose) goes along way in building up a much more reactive way of working.

kcurtin 15y ago
I may start keeping a notebook next to my computer with a list of common error messages I encounter.
pmr_ 15y ago
Also the process showed him his lack of knowledge very clearly: He can't read error messages. This is an useful skill in every language although it transfers not at all to any other activity (even reading compiler messages of a different vendor). Especially since this was a common error it is important to realize it early and fast. You just can't go to sleep every time you have a typo. OP only sees the immediate solution (insofar just waiting for a flash of genius counts as a solution) but no the actual error.

espeed 15y ago

He's right, the "walking away" trick does work wonders some time. It gets you to relax, take a step back, and see the big picture. The other aspect to this is reliance on Google. This is part stood out to me... I start to panic a little bit...I turn to google hoping for a quick fix and copy/paste one of my error messages into the search box. Unless Ruby/Rails error messages these days are completely anemic (I haven't worked with Rails in a while), then the line number and error message should provide enough clues to debug a misspelling without having to go to Google. Trust your analytic abilities -- it will keep you from that "panic" state. Instead of seeing an error and panicking, be like Stanley Moss in Wag the Dog -- "This is nothing" :) Eventually you'll get to a point like Paul Graham where debugging relaxes you: I like debugging: it's the one time that hacking is as straightforward as people think it is. You have a totally constrained problem, and all you have to do is solve it. Your program is supposed to do x. Instead it does y. Where does it go wrong? You know you're going to win in the end. It's as relaxing as painting a wall. Source: http://www.paulgraham.com/hp.html http://www.paulgraham.com/hp.html

hugh3 15y ago

Sometimes I feel compelled to take a one-year break from all computers. But I know that if I did, I'd just feel compelled to blog about it.

zokier 15y ago
oblig http://xkcd.com/77/ http://xkcd.com/77/
- sneak 15y ago
  Referencing two-digit xkcd comics in 2011 feels like the internet meme equivalent of a three-point-shot. FROM DOWNTOWN!

TWSS 15y ago

As a UI designer, this is something I need to tattoo on my forearm. Sometimes I'll spend so long banging my head against a problem that my bike-racer colleague will take me aside and remind me of the principles of overtraining. Of course, I ignore him 80% of the time because I can't stand to step away from a problem before it's solved, but he's always right.

reinhardt 15y ago

<half-trolling>Seems like that in this case the lesson should have been to use a statically typed language instead.</half-trolling> (PS: dyed in the wool Python guy here)

Groxx 15y ago
Unless they were doing something exceedingly strange, they should've gotten the same kind of runtime error (undefined variable) as any statically-typed (or even compiled) language would have told them. Ruby crashes if you try to read from something that isn't defined.

Groxx 15y ago

Um, very true, but this would also be a sign that they need to read their stack traces / test outputs, and probably try a debugger. Seriously. Debugger. For tests, it's as simple as `gem install rdebug` and put `debugger` in the failing test(s). When it stops on that line, type `eval instance_variables`, and viola - your array contains "@microposts" and not "@micropost". Running it against a full Rails application, especially with, say, Passenger, is a bit trickier, but it's still worth the initial effort.

mhartl 15y ago
Thanks for the tip. I'll plan to cover this technique in the next version of the Rails Tutorial.

aorshan 15y ago

This is absolutely true. One of the most important lessons I ever learned in English class was to walk away. Always give yourself a day between when you write something and when you edit it. You come back fresh and with a new perspective.

parallel 15y ago

I think the key here is the low quality work at the end of the day. I often knock off when I detect that I'm running at a very low productivity rate. Invariably the next day the overwhelming and seemingly massive task from the night before takes just a few minutes for the well rested brain. There's also something about the "self control as a finite resource" that comes in to play here.

sneak 15y ago

Two things to add: 1. As one of the article commenters pointed out: "git diff". Seriously. 2. One of the best things I ever did was to buy a weight bench/barbell. When I do my twice-an-hour "walk away for five minutes" routine, I go and do 20 bicep curls or bench presses. I solve problems faster and also improve my health/strength. Win/win!

frankwiles 15y ago

I solve more problems taking a walk (to get coffee, fill my meter, or just walk) than staring at the screen for the same period of time. Often, walking around doing nothing, getting your mind off the problem is the answer. Hence why you often hear great stories that start off "So I was in the shower yesterday..." and rarely hear great stories that start off "So I stayed at my desk for an additional two hours..."

trocker 15y ago

The comments reading seems to diverge from the main post, but was fun reading anyway. When I face the same problem and when my head is full of all the noisy - "why is this thing not working, I think I did everything right" s - I stroll around, walk a mile or two - have some coffee there at some store - look at the people there and think - 'what is running on their mind? Not a buggy code,I guess' - and then come back, stare at the screen and voila! there it is! An insignificant pesky ';' was missing! So, yes, walk away from your computer. What you and your computer have is a relationship and you need to spend some time apart to realize what you're missing in there.And to get it to work. ;)

devraj 15y ago

I have never, in 20 years of programming, ever made this mistake; nor have I ever had to fix a bug that was caused by it. I generally do insert the braces anyway on the basis of almost a cargo-cult theory that someone else might make this mistake, but only because of received wisdom floating around on newsgroups an the like.

MostAwesomeDude 15y ago
If only all programmers could be as great as you. You are truly an inspiration to us all. Edit: I think you meant to reply to the guy talking about braces, not the parent article talking about typos.
DeusExMachina 15y ago
This is a copy and paste of another comment in this thread, that was referring to something completely different: http://news.ycombinator.com/item?id=3036988 http://news.ycombinator.com/item?id=3036988 Is this some sort of spam account trying to get karma?

DanielShir 15y ago

Quite true, which is why you should stop banging your head against the monitor at 3AM, sleep a little and solve that bug in 30 seconds in the morning. I must admit this is very controversial among startups I've worked in, as the policy is usually along the lines of "no one goes home until this works". Good thing I have my own company now, and bugs are only solved by programmers that are "fresh" :)