Walk Away From Your Computer. Seriously.

http://kcurtin.squarespace.com/home/2011/9/24/walk-away-from-your-computer-seriously.html

by kcurtin • 15 years ago

121 54 15 years ago

kcurtin.squarespace.com

dorkitude• 15 years ago

Absolutely valid.

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

kcurtin4• 15 years ago

I'd be interested to learn more about the psychology behind this and why our minds work this way..

sp332• 15 years ago

Physically stepping backwards increases cognitive function. http://psycnet.apa.org/psycinfo/2009-06873-006 (full 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• 15 years 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...

wccrawford• 15 years 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• 15 years ago

This is exactly what I came to say. I usually end up cooking food.

FuzzyDunlop• 15 years 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• 15 years 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."

kcurtin4• 15 years 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• 15 years 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• 15 years 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 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.

kcurtin4• 15 years ago

Are there any tell tale signs that help you notice these types of bugs faster? I am learning Ruby on Rails but I assume there is some type of continuity with how this rears its head between languages.

I will definitely experiment with the tips posted above - I am learning Github which could be useful for this I think, but do you recommend any simple tools for showing someone who is remote your code? The issue with copy/pasting is figuring out which code is relevant to show someone.

Thanks for your insightful comment.

kelnos• 15 years ago

If you use git, that can definitely help you. The trick is in making small, targeted changes that do one logical 'thing', and then committing that. Don't be afraid to make tiny commits -- often I'll make a series of 1-liners if they aren't strictly related. Commits are very cheap in git, so don't worry about making "too many".

Then when you run into a problem, you can easily use "git bisect" to figure out which commit caused the problem, and if you've kept to small commits, you should hopefully be able to figure out the offending line(s) of code pretty quickly.

But beyond this, I think the early sign is your gut says, "it should be so simple but I can't figure out what's wrong". Listen to your instinct -- it's probably right! Don't spend another 2 hours poking at it. That's a good time to either step away for a bit or ask someone else to look over your shoulder for a bit while you try to explain to them what's going on.

mrud• 15 years ago

For me a big tell is if it should work and you have no clue why it doesn't or why it really behaves strangely/unexpected.

For showing code to others in general i really like pastebins. http://paste.pocoo.org/ supports "multiple files" which means you can upload multiple distributed snippets at once. http://jsfiddle.net/ is really great for javascript/html and helps others to change/modify the stuff.

I often try to simplify the example (if the persons i am showing it to are not working in the same team as i am) to make it clear what the problem is and make the problem more accessible. This simplification often helps me to understand and solve the problem.

emu• 15 years ago

To echo one of the comments on the linked post --- it is because of bugs like this that I am a firm advocate of languages with strong static checks.

A few claims: * no matter how good a programmer you are, you will make stupid mistakes (such as typos, as in the case of this article) every now and then. * it is statistically inevitable that you will make many such errors in a large code base. * bugs are easier and cheaper to fix the earlier you catch them; the best time to catch a bug is before the code is paged out of a programmer's brain. * it doesn't take too many experiences of discovering a typo bug in your "production" code base before you realize there must be a better way.

My personal approach is the following: * restrict the use of untyped scripting languages to pieces of code that can fit in one screen or so; that is, just small enough that you can keep all of the moving pieces in your head at once. * as much as possible, use languages and tools that provide strong static checks for larger projects. This includes language type systems (e.g., Scala, OCaml, Haskell, etc.) and tools that help you check your code (Prefix/Prefast, Coverity, Findbugs, etc.) * testing is good, but static checks are far better.

Unfortunately these opinions don't match common practice in the web programming world.

keeperofdakeys• 15 years ago

The best way to prevent these kind of bugs is to change your programming style. Always inserting { } for if-statements, even for one liners, is a programming style, and helps eliminate this specific bug. You will pick up these things as you write programs, or by looking at other peoples code.

0x12• 15 years ago

This is why you always use braces, even when they're optional. Imo a single-line if without braces is an accident waiting to happen.

barrkel• 15 years ago

This one has always been mysterious to me; 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.

Mind you, much of the C code I've co-maintained for the past while is compiler source, and compiler developers may be more attuned to seeing structured text as a parse tree.

GreySyntax• 15 years ago

I have to agree missing braces in general bugs me and often causes accidental bugs.

cageface• 15 years ago

My rule is that a simple conditional without braces can go on one line:

    if (not_true) return;

Anything longer goes on the next line, within brances.

Figs• 15 years ago

This is such a common mistake in C (and other curly brace languages) that it's surprising that compilers don't generate a warning based on weird indentation like that. It doesn't seem like it should be that hard to add a check for, but maybe the interactions with the preprocessor make it more complicated than I am imagining?

hrktb• 15 years ago

It could be an argument for using automatic formatting (not only automatic indentation while typing, but reindentation of the whole code before compile for ex.)

jebblue• 15 years ago

Thanks for sharing that example. It bit me in the past too. When I harp to colleagues "use braces always" and they say "it's a style thing" ... arrrgh!! No, it's an engineering thing.

In the early 1990's half of the country went without phone service for I think it was several hours due to a rare case statement that ended up running, he forgot a break, code that wasn't supposed to, ran. Crash.

nphase• 15 years 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• 15 years 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• 15 years 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.

kcurtin4• 15 years ago

I may start keeping a notebook next to my computer with a list of common error messages I encounter.

pmr_• 15 years 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• 15 years 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

hugh3• 15 years 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• 15 years ago

oblig http://xkcd.com/77/

sneak2• 15 years ago

Referencing two-digit xkcd comics in 2011 feels like the internet meme equivalent of a three-point-shot.

FROM DOWNTOWN!

TWSS• 15 years 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• 15 years 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)

Groxx2• 15 years 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.

Groxx2• 15 years 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• 15 years ago

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

aorshan• 15 years 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• 15 years 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.

sneak2• 15 years 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• 15 years 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• 15 years 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• 15 years 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• 15 years 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• 15 years 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

Is this some sort of spam account trying to get karma?

DanielShir• 15 years 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" :)

Walk Away From Your Computer. Seriously.

Related Stories