<i>A programmer’s greatest enemy is getting stuck.</i><p>Agreed. I often know where I want to go but can't seem to get there with code. This sucks and good programmers must find a way to get through this.<p><i>A crucial skill in programming...is the ability to recognize when they’re stuck,</i><p>Yes, and this is the only time I ever measure lines of code. Here is my metric: If I've been sitting at my computer (developing, not testing or anything else) more than one hour and LOC written or changed = 0, then I'm officially stuck, and must move to GettingUnstuck mode.<p><i>to get out of being stuck,</i><p>The most effective way I've ever found to get unstuck is to <i>get away from the computer</i>. I take pencils, paper, and code listings and get away, always into another room, sometimes to another building.<p>I have learned that the reason I'm stuck is not because I don't know how to do something; it's because I don't know <i>what to do</i>. <i>What</i> needs to be determined away from the computer; <i>how</i> can be determined at the computer.<p><i>and to avoid getting stuck in the first place.</i><p>This is the one time I disagree with OP. Getting stuck is not the problem; getting unstuck is. If you're not getting stuck on a regular basis, then you're probably not working on big enough problems.<p>Never getting stuck makes programming like almost any other vocation. For me, getting stuck and then getting unstuck and making something cool work for the first time ever is one of the best feelings you can have.
This is actually one of the few useful points in Pirsig's _Zen and the Art of Motorcycle Maintenance_: getting stuck is a bug report, and getting unstuck is debugging. It's worth a short quote:<p>___
“Okay,” I say. I tell him getting stuck is the commonest trouble of all. Usually, I say, your mind gets stuck when you’re trying to do too many things at once. What you have to do is try not to force words to come. That just gets you more stuck. What you have to do now is separate out the things and do them one at a time. You’re trying to think of what to say and what to say first at the same time and that’s too hard. So separate them out. Just make a list of all the things you want to say in any old order. Then later we’ll figure out the right order.
___<p>Pirsig is talking about writing here, but he also applies it to motorcycles and it can apply equally well to programming. The key thing is that stuckness is inside your head, and having tools to get yourself unstuck is vital.
I completely agree.<p>I sometimes find myself procrastinating, not able to get my head into the game.<p>And it _always_ turns out that I'm afraid of something. That there's something lurking ahead that I don't know what to do about - lacking requirements, a problem I don't know how to solve, technology that's being a massive pain to work with in the past.<p>The thing that works for me is stopping, working out where the fear is coming from, and then taking a bit of time out to work out what the solution is. Once I've done that my productivity skyrockets.
I've found explaining the situation to another person helps.<p>Usually having to make coherent statements about a thing causes me to realize what I am failing to put together.<p>Also, often whatever obvious thing I am failing to see stands out clearly to someone with fresh eyes. Those eyes could be someone else's. Or they could be your own.<p>Did you know that the human eye constantly moves around even when its staring at something? If it didn't, the same exact stimulus would eventually be invisible to it. They've held eyes completely still in the lab and kept the stimulus the same and eventually the eye stops seeing anything.<p>The same thing can happen to your attention when it constantly focuses on a problem.
I'm really stuck. I hate my job and dread every day of it. I'm too scared to move on somehow because of some ill form of loyalty towards its owner and a limited job market here.<p>I've dropped out of college (a really good one, you should know it) because I couldn't afford it any more and I'm now working as a .NET web developer (4 years) with people clearly less knowledgeable about programming and the internet in general.<p>The most senior dev guy (works there for 14 years) is a cocky jog who only knows VB.NET, who advocates the use of POS content management systems such as DotNetNuke. His code is such a bad and unmanageable mess, I could supply thedailywtf with code excerpts for the rest of eternity. When you try to explain concepts such as anonymous methods to him his head explodes.<p>Do you think we have code versioning? Do you think we freeze functionality, have releases, or even any sort of requirements for our custom modules and libraries? No, every fucking web site has a slightly different version, it's a pure ghetto.<p>Sometimes I slack off for the entire day, browsing reddit, and with 30 minutes of coding I'm still more productive than any of ny work mates.<p>These guys don't know what the "cascading" in CSS stands for. "What is a selector?".<p>When I started I had to fix the all of our web servers, they crashed every day because of simple configuration mistakes.<p>These are guys that set up the dbs with a full transaction logging only to delete the transaction logs every day because they're getting too big.<p>"We" now made the decision to move like 400 web sites, (some of them are nationally known and get a lot of traffic), sites that expose public web services, sometimes have custom services running in the background that require os access, and more, to a SHARED web hoster where we don't have any other access than PLESK. Without any migration plan. Bringing up VPS or dedicated hosts will give you empty stares. They now started migrating and realized that well, it's not going to work out like this... durr... "what do we do now?"<p>These guys make CMS updates on a live server without informing the customers, if they're having a good day they at least don't forget to make a db and site backup first. Ah yeah, we also don't have staging servers. So most of the guys do development on live sites.<p>I tried to change things, introduce new practices, I tried really hard. But now I'm just bitter. Before I was a nice and outgoing guy, now I'm not even advocating for alternatives and I stopped giving input.<p>Man... I'm about to throw up
The five minute shout. If you are stuck for five minutes, ask the room.<p>This is not an admission of failure. This is not an admission of incompetence. It's an admission that you're stuck. It's an admission that you are human. It's recognition that the project is more important than your ego. It's a chance to communicate with your team. It's a chance to laugh at your oversight. It's a chance to improve.<p>Just ask. No harm will come of it. And the chances are very high that you will become unstuck.
Many times when I'm stuck, I seem to draw the conclusion that this is because the documentation is lacking. It might be me scapegoating, but many times I find that it is because there is a lack of documentation that I spend hours on hours trying to figure something out.<p>Debugging on Windows, is a prime example. If you take someone from the normal Visual Studio give give them a PDB file, the compiled executable, limited / no source code, a crash report and a minidump, they're going to be stumped looking on the internet for some resources and instructions on how to debug the program.<p>Others include debugging in general, making the switch to and working in a *NIX environment (ie. sans IDE) from Windows, adding functionality to a large enterprise application that doesn't have comments or documentation (so essentially you're stuck for 3 hours trying to find this interface to that will execute a command), and so on.
I am glad that I am not the only one, it's making me consider another line of work. I get stuck badly and often for many months - much longer than the timescales mentioned here, working on things that are beyond my basic level of ability and eventually having to give up if it's a solo effort or most recently have a more senior guy take over and finish the work. During this time I don't learn much. It's usually down to not having a crucial piece of information and being unable to determine what exactly isn't behaving as it should. On top of this, every other setback during the period that I'm stuck is magnified. Typically it tends to be cross platform stuff that works differently on different systems and one system, usually Windows, is holding me back. Perhaps the solution is to read Charles Petzold's Win32 programming book.
Being stuck can seem like a waste of time because it’s holding up productivity on your current project. However, when I am stuck I often learn things about the platform, debugging tools, even things like how to use google and stack overflow well. I agree it sucks, but I’ve learned a lot being stuck.
You're stuck because you're demotivated, and you're demotivated because you are in unfamiliar territory. This is the cusp of learning. Take the leap and you'll discover the addiction of empowerment.<p>(Ok - that sounds like a load of crap ARobbins might spout.)<p>Stuck is the result of not knowing where to - and your reluctance to - begin.
The real difficulty is in recognizing that you are stuck. You might be working on 10 different things. You may be making or ogress on 9/10 things. However the one thing that gets stuck may be holding you back on milestones. I've noticed in the past that I would put more effort to get the other 9 things going faster than put an effort to recognize that I'm stuck on a task and that's really important to achieve the milestone. I would be avoiding the task without even being aware of it. A personal project plan helps me notice the lack of progess on a task. I've been reading "Getting things done" by David Allen. Listing out things you need to get done and inventorying them periodically helps me to a certain extent.
Just wanted to thank everybody for the discussion here. I was stuck on a project for a while now and avoided working on it, because I had a good excuse (learning math).<p>I've had been cleaning up a mess of code that I've ported from a book whilst changing parts to fit my needs. I've got stuck on the process of cleaning up and now I'm going to reread the book and try to understand the concepts fully to then write my own code based on my understandings.<p>Even though I already considered doing that I still felt completely demotivated. The discussion here and the quote from the zen-book made me reconsider my options and think about what the correct next step would be.<p>I'm feeling relieved.
I hope you didn't write this blog post because you got stuck. Besides that great read! I think every coder knows this special time when you can't boot up your mind because you're afraid of crashing somewhere.
The problem with knowing when you're stuck is that it's very analogous to the halting problem - virtually unsolvable but for a specific set of subproblems.<p>That said, usually when I feel like I've started spinning in circles I take a break, come back and ... delete the whole thing. Start from scratch.<p>I find this frees me to solve the problem with a new pair of eyes and from a different angle. most of all, my thinking isn't bogged down by everything I've already done.
This article is very timely, but I'd argue that lack of focus is a more common reason developers fail to complete work. Otherwise a great and timely (for the guy who posted this: <a href="http://news.ycombinator.com/item?id=3114749" rel="nofollow">http://news.ycombinator.com/item?id=3114749</a>) piece of advice.