
Walk Away From Your Computer. Seriously. - kcurtin
http://kcurtin.squarespace.com/home/2011/9/24/walk-away-from-your-computer-seriously.html
======
espeed
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>

------
wccrawford
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
This is _exactly_ what I came to say. I usually end up cooking food.

------
nphase
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
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'.

------
sneak
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!

------
Groxx
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
Thanks for the tip. I'll plan to cover this technique in the next version of
the Rails Tutorial.

------
sophacles
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.

~~~
kcurtin
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.

~~~
emu
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.

~~~
grncdr
s/types/predeclaration/ and I 100% agree. I'm not a huge fan of Perl, but
strict mode is something I really miss when working in Python/PHP/Ruby/Lua.

------
FuzzyDunlop
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.

------
trocker
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. ;)

------
ocharles
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.

~~~
pmr_
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.

------
dorkitude
Absolutely valid.

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

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

~~~
sp332
Physically stepping backwards increases cognitive function.
<http://psycnet.apa.org/psycinfo/2009-06873-006> (full PDF
[http://www.aromatiseren.nl/cms/Uploads/manuscript_psychscien...](http://www.aromatiseren.nl/cms/Uploads/manuscript_psychscience%5B1%5D.pdf)
) The hypothesis is that stepping back is associated with avoidance, and that
makes the brain more aware.

------
ch0wn
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.

------
reinhardt
<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
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.

------
frankwiles
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..."

------
mnutt
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
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.

------
parallel
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.

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

------
TWSS
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.

------
devraj
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.

~~~
DeusExMachina
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?

------
hugh3
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
oblig <http://xkcd.com/77/>

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

FROM DOWNTOWN!

------
aorshan
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.

