Take the 2-minute tour ×

You ever try to implement something simple but for some strange reason it doesn't work.

So you try a possible solution but then something else doesn't work. You keep trying different workarounds but every time something different isn't working.

Every time you get one step closer you also get one (or more) step farther from solving this problem and its now been 3 hours when this should have taken you 10 minutes. And it still isn't solved.

There is no one in your company who can help, and you are about to put your fist through your screen.

At this point you are so frustrated you can no longer think about the problem clearly. What should you do at this point? Or what can you do to avoid reaching this point?

share|improve this question
I think you and I just had/are having the same experience. –  AndrewKS Feb 2 '11 at 21:39
Put it on SO and offer a bounty. –  JeffO Feb 2 '11 at 22:06
If only it was that simple. Some of these kind of problems are amongst the many many dead/unanswered/fail answered questions. –  Aditya P Apr 20 '11 at 12:43
This question appears to be off-topic because it belongs on workplace.stackexchange.com –  Kilian Foth Jul 17 '13 at 8:59
add comment

closed as too broad by gnat, MichaelT, Kilian Foth, Giorgio, user61852 Jul 18 '13 at 13:22


15 Answers

up vote 50 down vote accepted

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.

* kiss your partner, caress your pet - suggestions from my wife :-)

share|improve this answer
+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 –  CaffGeek Feb 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. Ant Feb 2 '11 at 20:50
And don't work more than 8 hours a day. The more tired you are the easier you get frustrated. –  HLGEM Feb 2 '11 at 22:25
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. –  barrycarter Feb 3 '11 at 8:14
@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ök Jan 5 '12 at 12:37
show 5 more comments


The magic word is should. Strike that from your vocabulary.

Who said it should take 10 minutes? Who specifically? What was the factual basis for their claim?

If you've done in 3 times before, and each time you were close to 10 minutes, you have a rational basis for a should.

If you've never done it before, saying should is only setting yourself up for failure. You should stop using should today.

share|improve this answer
+1 made by day :) –  Rook Apr 20 '11 at 13:09
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 Herlocker Apr 20 '11 at 13:17
@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.Lott Apr 20 '11 at 13:48
add comment

Find someone to use as a sounding board

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.

share|improve this answer
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 Brown Feb 2 '11 at 20:57
@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ök Feb 2 '11 at 22:31
@Mike Brown - see "rubber duck debugging" –  Slomojo Feb 2 '11 at 22:32
Rubber Duck Debugging? pfft. I keep a Debugging Goomba on my desk for just this reason, ducks are better for the project management side of things. –  glasnt Feb 3 '11 at 1:50
Yeah I was going to reference that...was just too lazy to pull up the link :P –  Mike Brown Feb 3 '11 at 4:11
show 3 more comments

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'.

share|improve this answer
I use the whiteboard all the time. Very useful for visualizing while debugging. –  Michael K Feb 2 '11 at 20:57
+1 great answer, I like the steps. –  JD Isaacks Feb 2 '11 at 21:03
Step 3 is known as changing the domain of the problem to see if a parallel success can be reused. It's also referred to as using a metaphor. –  Kurucu Feb 3 '11 at 9:54
add comment

Walk away for a while and do something else. Get a good night's sleep and come back to the problem in the morning.

Also, don't beat yourself up. Your ten-minute estimate is clearly not correct, and that happens all the time.

share|improve this answer
add comment

I would ask a question here and have the community help you resolve it. Less stressful that way.

share|improve this answer
Sometimes just writing the question will lead to the solution –  JoelFan Feb 3 '11 at 5:58
add comment

I have a different kind of solution - SLEEPING!!

When you are frustrated with a problem you can't easily get out of it. So it is better if you become so tired trying to solve the problem and then fall asleep.

When you wake up you will have a fresh feeling and again you can think clearly with the problem. I do it sometimes.

share|improve this answer
Not to be nitpicky, but this "different" solution has been mentioned in at least two earlier answers. –  Péter Török Feb 2 '11 at 22:24
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 –  eagleye Feb 2 '11 at 22:28
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

Two suggestions:

  1. The smartest person I know, who has two PhD's and has the job title "Research Fellow", at a smallish private company, says this

    If you've though about it for 15 minutes and you don't have the answer, you're doing it wrong.

    Stop thinking about it.

    Have a nap. ( go for a walk or something)

    The answer will be there when you wake.

  2. Get David J Agan's book "Debugging". It will probably teach you more about debugging so that when things don't work, you can debug it quickly.

share|improve this answer
add comment

When ever I am faced with something that is not working I always remember this quote:

When you are in hell, keep walking as its is the best thing that can be done at that point.

Have a break, try to refresh your self and focus on problem with new level of energy.

share|improve this answer
add comment

echoing others' recommendations:

  • this situation is almost always something trivial that you just don't see; take a break
  • another pair of eyes or even just explaining the problem to your cat can help

and adding:

  • re-examine your assumptions, especially the unstated ones; chances are you've been barking up the wrong tree
  • reverse the situation: assume the current behavior is the desired outcome, so what would you have to do to the code to make that happen?
  • write some test code (asserts or logging, or conditional breakpoints - keep it simple) to verify your assumptions along the execution path
share|improve this answer
add comment

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.

share|improve this answer
add comment

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:

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

share|improve this answer
add comment
