Dealing with frustration when things don't work

Question

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?

Answer 1

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

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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

Answer 6

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

Answer 7

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.

Answer 8

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.

Answer 9

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.

Answer 10

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.

Answer 11

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.

Answer 12

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.

Answer 13

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.

Answer 14

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

Answer 15

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.