There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs.
If this question can be reworded to fit the rules in the help center, please edit the question.

3

I think you and I just had/are having the same experience.
–
AndrewKSFeb 2 '11 at 21:39

15 Answers
15

Although this is a real problem, it isn't specific to programming. However, it is IMHO so important that it deserves a place on this forum.

My suggestions: have a break. Go for a walk, meditate, sleep, do physical activity* - do something completely different to allow your brain to relax and get out of the mental rut, while letting your subconscious work on the problem in peace. Usually it delivers results surprisingly fast - it just needs to let you know about it. But while your conscious mind is desperately repeating the same cycles of thoughts over and over again, it won't be able to listen to anything else.

what can you do to avoid reaching this point?

Relaxation and mindfulness techniques are a key to get over the stress reactions and allow your mind to focus clearly. And practicing these really pays off. When someone is experienced in these, (s)he can already notice the stress level rising before the frustration could take over. Then one can interrupt the cycle of thoughts e.g. by taking a few deep breaths, or doing a couple of minutes relaxation practice. This may be all what is needed at that point.

+1, Our mind is ALWAYS attempting to solve problems, just because we aren't consciously trying to solve it, our mind is still churning away. That's why you seemingly remember a name out of the blue, an hour after not being able to recall it. And wake up with a problem solved in the middle of the night. A great book explaining this is Pragmatic Thinking and Learning: Refactor Your Wetware
–
CaffGeekFeb 2 '11 at 20:42

+1 Couldn't of said better myself. I actually get out of my cube, leave the office, and walk around town, call my wife, and then go back to the office. Works almost 100% of the time.
–
Mr. AntFeb 2 '11 at 20:50

8

And don't work more than 8 hours a day. The more tired you are the easier you get frustrated.
–
HLGEMFeb 2 '11 at 22:25

3

When I take a break to pee, I often have the problem solved by the time I'm walking back to my desk. It's like your subconscious is waiting for your conscious to shut up.
–
barrycarterFeb 3 '11 at 8:14

1

@junxiong, one can use these techniques even when under time pressure, but this requires experience. Someone who has been e.g. meditating for years, can control and calm him/herself in a matter of minutes or even seconds. But trying to learn something new - and especially mindfulness - under time pressure is very difficult. If all else fails, take this as an important lesson, and once the deadline is over, start preparing for the next crisis by analysing your behaviour and practicing some techniques mentioned here or in other answers.
–
Péter TörökJan 5 '12 at 12:37

Of course, there are plenty of things that you have done a million times that one day just stop working. A corrupted file in some auto-generated code can be pretty darn frustrating, and is sometimes extremely difficult to debug. I'm thinking of times when I accidentally named two things the same name, then used a refactoring tool to change all instances where the name occurred. I've made that bone-headed move a few times with classes that conflicted with my ORM generated classes. Do something like that, and you had better hope you've been good about check-ins.
–
Morgan HerlockerApr 20 '11 at 13:17

1

@Prof Plum: "I've made that bone-headed move a few times". Excellent point. That means that an expectation has to include time for that bone-headed move. Again, the "should" should include all the facts, not the "if everything went right" facts, and excluding the "bone-headed move" facts.
–
S.LottApr 20 '11 at 13:48

Even if nobody has expertise in exactly what your working on, its a good idea to talk about these things frequently. Just the sheer act of using someone as a sounding board can make your mind start turning. You'll find yourself thinking of new things to try. It will also alleviate your stress to vent a little and potentially make a new friend. Its also just healthy in general for the team to feel comfortable sharing and commiserating with each other to generate a team-oriented atmosphere for solving these kinds of problems.

Even if the person doesn't have a clue about what you're telling him, just the act of talking it out helps to clarify things.
–
Mike BrownFeb 2 '11 at 20:57

2

@Mike, even if that "person" is a teddy bear, it still works in a surprisingly large percentage of the cases (there is some real story about this in the Hacker's Dictionary AFAIR)
–
Péter TörökFeb 2 '11 at 22:31

I have a few steps when I reach this point. Normally I can figure out a solution if I take the time to step back and reflect.

Step 1: Walk away from the problem and clear your head. Come back when you aren't frustrated and can look at it with a fresh mind.

Step 2: Go back to the code and see if there was anything you missed. Have someone come and be a second set of eyes if you just can't make heads or tails of it.

Step 3: Remove the code from the equation. What is the problem you are trying to solve? Write it out on a piece of paper or whiteboard. Talk the problem out with someone to get their opinions on the problem and solution.

Step 4: Reach out to the community to see if they have a solution or if anyone else has ever hit the same wall.

Basically, these can be summed up as 'Stop hacking and step away from the code'.

Not to be nitpicky, but this "different" solution has been mentioned in at least two earlier answers.
–
Péter TörökFeb 2 '11 at 22:24

1

what i meant -> not just take a break, walk or sleep rather become tired trying to solve the problem and then sleep. because when you have the problem in you, you mightn't get out of it easily
–
eagleyeFeb 2 '11 at 22:28

Find something to help build back some confidence is what I tend to do when I reach this point. This could be solving a Sudoku or Kenken puzzle, doing some simple mindless administrative task like filling out my time sheet, or getting out for a walk. The key here is for me to have a sense of achievement in whatever this little side distraction is to help pump me up enough to get back on the horse and ride off into the wild blue yonder, to mix a few metaphors there.

As for avoiding getting this bad, I'd likely suggest having some strategy of time-boxing stuff so that if you believe something to take 10 minutes and it is suddenly an hour later with not a lot of progress, I'd stop and have a little break rather than try to keep banging my head against the wall.

I have a special name for this kind of situation: epic programming battle.

If I haven't had at least one epic programming battle with a specific programming language or tool, and solved the problem, I can't say to myself that I can use such programming language or tool.

So there is my solution: mentalize it like a fight and a test of courage and endurance. If I can't solve the problem, then I "live to fight another day".

It may sound a tad ridiculous, but, it will be more fun and gratifying to think of it in this terms (like it was some sort of game you must win) instead of suffering all the way because you have to face the fact that you don't know everything.

Well...I think you need a new career or a completely new set of expectations. While certainly not frequent, taking 3, 4, 8, 10 or 40 hours to do what you originally thought would be a 10 minute job is certainly not uncommon in the software business. I'm sure most developers who work on anything of even moderate complexity have had 2 day tasks turn into 1 month tasks once they delved into it and understood the problem.

Part of being a good developer involves being patient, otherwise the computer is going to win and you will end up incorporating some sort of quick fix hack that only barely appears to work but will inevitably break something you didn't think of. If minor delays cause you that much stress then you probably shouldn't be in this line of work.

Sometimes, it is best to not just try to hack a way through a problem. Take some time and write out in pseudo code what you need to do. I know there is pressure to get things done as fast as possible, but from what I have seen, that style of coding leads to the type of situation that you describe. If someone writes code that will only function given a small set of conditions and that set changes, the code will break or do unexpected things.

Also (I hate admitting my professors were right on this...), documenting and unit testing helps. This would make it easier to know what a section of code will put out given the set of input. Then, it would be easier to see what effect a change in that sections input will cause.

Fatigue or lack of sleep is never an issue with me. I'm more frustrated with the lack of organization within the industry as a whole, and overall the low standards we've set for ourselves. Here's five things that frustrate me:

API's that are complicated in design. It's like learning a whole new programming language. In fact some API's are much harder to learn than learning new programming languages. I admire your intelligence, but you could have saved me time by putting in the documentation that I needed a phd in software engineering or computer science to understand it.

Lack of good documentation. I can never get over the fact that so many API designers spend a great deal of time in making an API only to release it with minimal documentation. Thanks, but how do I use this? What to do in this situation? etc.

Proprietary implementations. Some proprietary implementation is ok, but if standards exists, for the sake of humankind please follow those standards. Nothing more frustrating than spending time wondering why something doesn't work only to discover the implementation doesn't follow the normal standards.

Sandboxed environments/Restrictions. Ok, maybe this helps to keep the bad people out, but in my opinion, restrictions on what a programmer can do only limits creativity and technological progress. Many of great ideas I've had have been trashed after discovering that I'm not allowed to do something. The programming industry is really made for churning out everyday applications, not innovative ground-breaking software. So if you decide on being a programmer you are really choosing to be a modern day grunt, unless you want to become a lonely academic.

Modern discussions. People today still debate over the ugliness of Lisp parenthesis, or the merit of Pythons cleanliness, or how some languages like Cobol or Fortran are going extinct, etc, etc. Really people? This is what we debate about? Let's talk about parallelism, or better ways to design safer systems, or how logic programming can improve our lives. Let's stop thinking like coders and start thinking like designers of tomorrow's world.

So I personally don't program that much anymore due to these frustrations. Until the industry decides it wants to do more than just create the next Facebook, or reinvent the word processor I'm all set. I'll leave it to you guys. Honestly no offense meant, it is good money.