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.
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.
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.
Being stuck due to shitty docs is the worst. Particularly when docs are wrong, leave our crucial info, or the examples don't work (!).
Developers, please take pride in great documentation, and if you get stuck due to someone else's shitty docs, tell them at least, at best: fix the docs yourself. You can often write great (passionate) docs if you just had hands-on experience with the pain-points.
Also, make sure your examples work (examples+tests are often the best docs)
Truly I tell you, people can be forgiven all their sins and every slander they utter, 29 but whoever blasphemes against the Holy Spirit will never be forgiven; they are guilty of an eternal sin.”
I sometimes find myself procrastinating, not able to get my head into the game.
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.
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.
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.
A crucial skill in programming...is the ability to recognize when they’re stuck,
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.
to get out of being stuck,
The most effective way I've ever found to get unstuck is to get away from the computer. I take pencils, paper, and code listings and get away, always into another room, sometimes to another building.
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 what to do. What needs to be determined away from the computer; how can be determined at the computer.
and to avoid getting stuck in the first place.
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.
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.
My trick for getting unstuck is to start maintenance on the part where I'm stuck. Any kind of cleanup, comment clarification and so on will do. Once I'm doing that I'm doing something and moving from doing something to doing what I want to do happens more or less automatic at some point.
I got this trick from working in a metal shop. We'd get stuck trying to solve a problem all the time, and whenever that happened we'd simply start cleaning up. Usually after cleaning up the 'way forward' was crystal clear.
Now, of course one day there will be a problem where this will not work but for now it seems like a really good trick.
The underlying mechanism is as far as I can see related to being stuck in the same cycle in your head. As soon as you start cleaning up you force yourself to look at the forest instead of the individual trees and that's where you'll find the key for moving on.
I once was stuck for seven months. I never quite understood why my employer was OK with that. The solution however was just as you described. I needed to get away from the computer. In that case, I had to get some science/math straight. Once that was sorted, I steamrolled that roadblock in one evening. True story.
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.
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.
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.
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.
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:
___
“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.
___
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.
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.
(Ok - that sounds like a load of crap ARobbins might spout.)
Stuck is the result of not knowing where to - and your reluctance to - begin.
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).
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.
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.
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: http://news.ycombinator.com/item?id=3114749) piece of advice.
I've found explaining the situation to another person helps.
Usually having to make coherent statements about a thing causes me to realize what I am failing to put together.
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.
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.
The same thing can happen to your attention when it constantly focuses on a problem.
This really helps. I once spent a couple weeks trying to figure something out. A quick trip to the local coffee shop and a chat with a fellow programmer fixed things. By the time I was done explaining where I was, I already saw where the issue was and knew how to fix it. He didn't have to say anything. Just talking it out can really help.
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.
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.
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.
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.
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.
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.
These guys don't know what the "cascading" in CSS stands for. "What is a selector?".
When I started I had to fix the all of our web servers, they crashed every day because of simple configuration mistakes.
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.
"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?"
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.
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.
Um you need to get in contact with some folks here at hacker news after you put a nice project up on github and contribute to haxe. The people you work with are not programmers. Programmers understand discrete operations.
Put an email in your profile. You are complaining about the right things, in a constructive way which shows you want to improve the system. There are a number of people hiring on HN who value that.
Sounds remarkably similar to my life in my early 20s.
Get out. Now. I spent about 5 years in a job that initially taught me a lot about a lot of different technologies, but I peaked very quickly. I felt like I couldn't leave, however, since I was easily the most technical and was responsible for lots of disparate systems. So, I would go to work and spend 95% of my day chatting on IRC and 5% of my day writing a solid chunk of code that made it look like I was busy.
The biggest regret I have is that I spent at least 2 years too many at that job before I grew the balls to change my life. Don't waste another day of your life rotting away in an environment that's doing nothing for you.
Currently in an almost identical situation. Finally made the decision to start an independent software business within the last month. Not sure how. Don't know what to make. Don't know how I'm going to market anything. But simply having the plan makes a huge difference. I feel so much better.
"with 30 minutes of coding I'm still more productive than any of ny work mates"
Use the rest of your time on research and planning for your own business. Don't actually do work on their computers, but research is fine. Feel absolutely no loyalty to the company. I guarantee they have no loyalty to you.
The five minute shout. If you are stuck for five minutes, ask the room.
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.
Just ask. No harm will come of it. And the chances are very high that you will become unstuck.
Depending on the work environment this might be good advice. On the flip side, however, I think many people have or remember having coworkers who ask questions any time they get stuck without hardly trying to solve the problem for themselves.
Spinning your wheels for too long doesn't help anyone, but a lot can be said for people who are independent and don't needlessly distract those around them.
"Mutt can't remember the name of the Unicode version of the strcpy function. He could look it up, which takes 30 seconds, or he could ask Jeff, which takes 15 seconds. Since he's sitting right next to Jeff, he asks Jeff. Jeff gets distracted and loses 15 minutes of productivity (to save Mutt 15 seconds).
"Now let's move them into separate offices with walls and doors. Now when Mutt can't remember the name of that function, he could look it up, which still takes 30 seconds, or he could ask Jeff, which now takes 45 seconds and involves standing up (not an easy task given the average physical fitness of programmers!). So he looks it up. So now Mutt loses 30 seconds of productivity, but we save 15 minutes for Jeff."
Granted, interrupting a peer makes more sense if you actually can't make progress without another opinion on design, rather than just being lazy and using them as a living reference work.
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.
40 comments
[ 0.21 ms ] story [ 2203 ms ] threadDebugging 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.
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.
Developers, please take pride in great documentation, and if you get stuck due to someone else's shitty docs, tell them at least, at best: fix the docs yourself. You can often write great (passionate) docs if you just had hands-on experience with the pain-points.
Also, make sure your examples work (examples+tests are often the best docs)
I sometimes find myself procrastinating, not able to get my head into the game.
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.
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.
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.
A crucial skill in programming...is the ability to recognize when they’re stuck,
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.
to get out of being stuck,
The most effective way I've ever found to get unstuck is to get away from the computer. I take pencils, paper, and code listings and get away, always into another room, sometimes to another building.
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 what to do. What needs to be determined away from the computer; how can be determined at the computer.
and to avoid getting stuck in the first place.
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.
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.
I got this trick from working in a metal shop. We'd get stuck trying to solve a problem all the time, and whenever that happened we'd simply start cleaning up. Usually after cleaning up the 'way forward' was crystal clear.
Now, of course one day there will be a problem where this will not work but for now it seems like a really good trick.
The underlying mechanism is as far as I can see related to being stuck in the same cycle in your head. As soon as you start cleaning up you force yourself to look at the forest instead of the individual trees and that's where you'll find the key for moving on.
ymmv, it works for me.
I've found doing a bit of refactoring on messy code has always helped if stuck and the effect is just as you describe.
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.
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.
___ “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. ___
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.
(Ok - that sounds like a load of crap ARobbins might spout.)
Stuck is the result of not knowing where to - and your reluctance to - begin.
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.
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.
I'm feeling relieved.
Usually having to make coherent statements about a thing causes me to realize what I am failing to put together.
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.
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.
The same thing can happen to your attention when it constantly focuses on a problem.
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.
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.
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.
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.
These guys don't know what the "cascading" in CSS stands for. "What is a selector?".
When I started I had to fix the all of our web servers, they crashed every day because of simple configuration mistakes.
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.
"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?"
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.
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.
Man... I'm about to throw up
Get out. Now. I spent about 5 years in a job that initially taught me a lot about a lot of different technologies, but I peaked very quickly. I felt like I couldn't leave, however, since I was easily the most technical and was responsible for lots of disparate systems. So, I would go to work and spend 95% of my day chatting on IRC and 5% of my day writing a solid chunk of code that made it look like I was busy.
The biggest regret I have is that I spent at least 2 years too many at that job before I grew the balls to change my life. Don't waste another day of your life rotting away in an environment that's doing nothing for you.
"with 30 minutes of coding I'm still more productive than any of ny work mates"
Use the rest of your time on research and planning for your own business. Don't actually do work on their computers, but research is fine. Feel absolutely no loyalty to the company. I guarantee they have no loyalty to you.
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.
Just ask. No harm will come of it. And the chances are very high that you will become unstuck.
Spinning your wheels for too long doesn't help anyone, but a lot can be said for people who are independent and don't needlessly distract those around them.
"Mutt can't remember the name of the Unicode version of the strcpy function. He could look it up, which takes 30 seconds, or he could ask Jeff, which takes 15 seconds. Since he's sitting right next to Jeff, he asks Jeff. Jeff gets distracted and loses 15 minutes of productivity (to save Mutt 15 seconds).
"Now let's move them into separate offices with walls and doors. Now when Mutt can't remember the name of that function, he could look it up, which still takes 30 seconds, or he could ask Jeff, which now takes 45 seconds and involves standing up (not an easy task given the average physical fitness of programmers!). So he looks it up. So now Mutt loses 30 seconds of productivity, but we save 15 minutes for Jeff."
Granted, interrupting a peer makes more sense if you actually can't make progress without another opinion on design, rather than just being lazy and using them as a living reference work.