Walk Away From Your Computer. Seriously.(kcurtin.squarespace.com)
kcurtin.squarespace.com
Walk Away From Your Computer. Seriously.
http://kcurtin.squarespace.com/home/2011/9/24/walk-away-from-your-computer-seriously.html
55 comments
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.
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.
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.
Walking away is critical to any creative process.
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'.
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'.
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!
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!
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.
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.
Thanks for the tip. I'll plan to cover this technique in the next version of the Rails Tutorial.
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:
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.
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();
// C Code:
if (test_fails)
log("info about test");
do_crashy_thing();
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.
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.
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.
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.
I have never, in 20 years of programming, ever made this mistake
Good for you!
But fortunately you put the braces in anyway, because the person who touches the code after you might be more prone to the mistake.
I almost never misspell things. I might therefore be tempted to believe that spell checkers are a pointless and annoying waste of time. But not everyone has the same brain as I, and experience has taught me that there are lots of people who can't spell well, many of whom are actually really good writers. I'd assume that the optional-braces problem is a cliche for a similar reason.
Good for you!
But fortunately you put the braces in anyway, because the person who touches the code after you might be more prone to the mistake.
I almost never misspell things. I might therefore be tempted to believe that spell checkers are a pointless and annoying waste of time. But not everyone has the same brain as I, and experience has taught me that there are lots of people who can't spell well, many of whom are actually really good writers. I'd assume that the optional-braces problem is a cliche for a similar reason.
I agree with you here. Never happened to me, and I've never seen it happen.
Another one is if(0 == some_thing). It seems clever and I try to use it, but if you write if(some_thing = 0), the compiler just warns you. So there's no real point in doing this.
Another one is if(0 == some_thing). It seems clever and I try to use it, but if you write if(some_thing = 0), the compiler just warns you. So there's no real point in doing this.
IME, working with large groups of developers on a correspondingly large project where quality varies widely over different bits of code was the quickest way to learn to be grateful for such little syntactic annoyances that however helped catch bugs (or better, prevent them) quickly.
The problem with compiler warnings is, unless you have a warning-free base build, they're difficult to see. And in turn, a warning-free build more or less depends on the very first developers to have turned the warning flags on while they were checking in stuff like mad trying to get someting to ship.
So, yeah, I could claim that I don't too many such silly mistakes (and that might even be true), but I can both understand and approve of such coding standards.
The problem with compiler warnings is, unless you have a warning-free base build, they're difficult to see. And in turn, a warning-free build more or less depends on the very first developers to have turned the warning flags on while they were checking in stuff like mad trying to get someting to ship.
So, yeah, I could claim that I don't too many such silly mistakes (and that might even be true), but I can both understand and approve of such coding standards.
Luckily, I've never worked on a non-open-source C project with anyone but myself. So my builds are warnings clean :)
I fixed a bug in ldap2dns because of this type of error, IIRC, it had to do with SRV records.
I have to agree missing braces in general bugs me and often causes accidental bugs.
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?
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.)
But if you did that, then you would lose contextual information about that sort of bug, especially if you weren't looking at it when compiling. So instead of seeing two lines of code indented after an if (i.e. the mistake), you'd just see the one line if printing a debugging statement and the next line would be indented at the same level as the if.
To my mind that's worse because you lose meaning when doing the auto formatting. Better to just give a warning instead, this also goes for while and for statements.
To my mind that's worse because you lose meaning when doing the auto formatting. Better to just give a warning instead, this also goes for while and for statements.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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. ;)
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. ;)
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.
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.
I may start keeping a notebook next to my computer with a list of common error messages I encounter.
Absolutely valid.
When I'm doing something difficult, nothing is more important than giving my subconscious some time to work out a problem.
When I'm doing something difficult, nothing is more important than giving my subconscious some time to work out a problem.
I'd be interested to learn more about the psychology behind this and why our minds work this way..
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.
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...
http://www.amazon.com/Your-Brain-Work-Strategies-Distraction...
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.
<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)
(PS: dyed in the wool Python guy here)
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.
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..."
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..."
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."
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.
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.
There's also something about the "self control as a finite resource" that comes in to play here.
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" :)
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" :)
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.
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.
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.
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?
http://news.ycombinator.com/item?id=3036988
Is this some sort of spam account trying to get karma?
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.
Edit: I think you meant to reply to the guy talking about braces, not the parent article talking about typos.
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.
But I know that if I did, I'd just feel compelled to blog about it.
oblig http://xkcd.com/77/
Referencing two-digit xkcd comics in 2011 feels like the internet meme equivalent of a three-point-shot.
FROM DOWNTOWN!
FROM DOWNTOWN!
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.
The other aspect to this is reliance on Google. This is part stood out to me...
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:
Source: http://www.paulgraham.com/hp.html