62

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?

5
  • 3
    I think you and I just had/are having the same experience.
    – AndrewKS
    Commented Feb 2, 2011 at 21:39
  • 19
    Put it on SO and offer a bounty.
    – JeffO
    Commented Feb 2, 2011 at 22:06
  • 4
    If only it was that simple. Some of these kind of problems are amongst the many many dead/unanswered/fail answered questions.
    – Aditya P
    Commented Apr 20, 2011 at 12:43
  • 2
    This question appears to be off-topic because it belongs on workplace.stackexchange.com Commented Jul 17, 2013 at 8:59
  • The same problem of mine and same question.
    – Anwar
    Commented May 26, 2016 at 18:13

15 Answers 15

70

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 :-)

11
  • 12
    +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
    Commented Feb 2, 2011 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
    Commented Feb 2, 2011 at 20:50
  • 9
    And don't work more than 8 hours a day. The more tired you are the easier you get frustrated.
    – HLGEM
    Commented Feb 2, 2011 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.
    – user11586
    Commented Feb 3, 2011 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. Commented Jan 5, 2012 at 12:37
34

its now been 3 hours when this should have taken you 10 minutes.

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.

2
  • 2
    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.
    – user3792
    Commented Apr 20, 2011 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.Lott
    Commented Apr 20, 2011 at 13:48
22

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.

8
  • 7
    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. Commented Feb 2, 2011 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) Commented Feb 2, 2011 at 22:31
  • 3
    @Mike Brown - see "rubber duck debugging"
    – ocodo
    Commented Feb 2, 2011 at 22:32
  • 1
    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
    Commented Feb 3, 2011 at 1:50
  • Yeah I was going to reference that...was just too lazy to pull up the link :P Commented Feb 3, 2011 at 4:11
9

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.

9

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

2
  • I use the whiteboard all the time. Very useful for visualizing while debugging.
    – Michael K
    Commented Feb 2, 2011 at 20:57
  • 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.
    – Elliot
    Commented Feb 3, 2011 at 9:54
2

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

1
  • 6
    Sometimes just writing the question will lead to the solution
    – JoelFan
    Commented Feb 3, 2011 at 5:58
1

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.

2
  • Not to be nitpicky, but this "different" solution has been mentioned in at least two earlier answers. Commented Feb 2, 2011 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
    – ruben
    Commented Feb 2, 2011 at 22:28
1

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.

1

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.

0

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.

0

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.

0

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.

0

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
0

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.

0

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.

Not the answer you're looking for? Browse other questions tagged or ask your own question.