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.<p>The other aspect to this is reliance on Google. This is part stood out to me...<p><pre><code> 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.
</code></pre>
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.<p>Trust your analytic abilities -- it will keep you from that "panic" state.<p>Instead of seeing an error and panicking, be like Stanley Moss in <i>Wag the Dog</i> -- "This is nothing" :) Eventually you'll get to a point like Paul Graham where debugging relaxes you:<p><pre><code> 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.
</code></pre>
Source: <a href="http://www.paulgraham.com/hp.html" rel="nofollow">http://www.paulgraham.com/hp.html</a>
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.<p>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.<p>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.<p>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.<p>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:<p>1. As one of the article commenters pointed out: "git diff". Seriously.<p>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.<p>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.
Tangential to the main point:<p>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.<p>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:<p><pre><code> // C Code:
if (test_fails)
do_crashy_thing();
</code></pre>
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:<p><pre><code> // C Code:
if (test_fails)
log("info about test");
do_crashy_thing();
</code></pre>
Which caused my code to crash <i>every time</i> 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.<p>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.<p>A few tips for anyone who is experiencing this sort of thing and not sure what to do:<p>Get a rubber duck (or whatever) and start employing the rubber-duck debugging technique: <a href="http://en.wikipedia.org/wiki/Rubber_duck_debugging" rel="nofollow">http://en.wikipedia.org/wiki/Rubber_duck_debugging</a> it really helps!<p>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).<p>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.
I'd say this wasn't counterintuitive nor particularly abnormal.<p>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.<p>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.<p>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.<p>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<p>- 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!<p>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.
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><p>(PS: dyed in the wool Python guy here)
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.<p>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."
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.<p>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.<p>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".<p>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.<p>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 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.