What stressors do programmers encounter on the job, and how do you deal with them? [closed]

Question

Learning to manage stress is vital to staying healthy while working at any job. A necessary subtask is learning to recognize and limit the sources of stress.

But, in the midst of the daily grind, it can be difficult to recognize sources of stress (especially for an intense, focused persona such as a programmer).

What types of stressors should programmers look out for, and how can they be managed?

Answer 1

Here are the things I find cause the most stress to me and the developers around me:

1. Ambiguity: Ineffectively stated goals, requirements, or other expectations. Many companies have employees who have an attitude of "I don't know what I want, but I'll know it when I see it. Oh, and by the way I need it tomorrow."
2. Inappropriate deadlines: Most deadlines are set by the business need not by the realistic capabilities of the developers on staff. In addition to this, the expectations for the requirement are increased but the budget/resources are not.
3. Bad assumptions/expectations: Programmers have a tendency to have a high opinion of their capabilities (not an unearned trait), and because of this they expect that other people can match their capabilities, understanding and expectations. Often an assumption will be made that something is "common knowledge" or the like, and this can be catastrophic in the stress category. Now, not only did the business expert not meet the programmer's expectations, but is a complete incompetent to boot. In the converse, if the programmer fails to meet the business's expectations, the programmer is left frustrated because he/she was not given the information they needed to proceed.
4. Lack of respect: Many people have a tendency to believe that just because someone is weak in your discipline that it means they are weak in theirs. There is a reason we all have different jobs/capabilities/expectations, and it is important to respect that the other person is very likely very capable at the tasks they are asked to do. Just because someone doesn't have your capabilities doesn't mean they are incompetent or incapable.
5. Lack of self control: This can be manifested in many things. Perhaps you're a work-a-holic who refuses to take the proper breaks. This leads to build up of stress and is bad. Perhaps you're a Jolt Cola drinker who drinks more caffeine that he should when stress builds up. This is bad for your health and makes your stress response worse. You have to know your limits, know what triggers your specific stress responses, and most importantly know how to relieve that stress response. Taking it out on co-workers or colleagues is not appropriate and will only serve to increase stress.
6. Lack of communication skill: Often we don't speak the same language, and I'm not talking about English, German, or Indian. We're using the same words, but we're not saying the same things. People need to be specific and open about things they don't understand. Even if you think you understand, it does not hurt to clarify. Remember that a business metric can mean something different to different departments in an organization.
7. Bleeding of limits: Keep work at work and home at home. Just because your 7-year-old is leaving his shoes in the middle of the floor and not cleaning up after his breakfast does not mean you need to chew Tiffany from accounting a new one because she hasn't given you the spreadsheet of billing requirements. Same token, just because Tiffany is slacking with the spreadsheet doesn't mean that your wife deserves to be treated poorly on the commute home. (btw, poor Tiffany doesn't deserve that treatment either)

Answer 2

I think the biggest stressor for any programmer is a lack of confidence.

Yes, a lot of meetings (certainly not meetings per se) are unnecessary, but there is quite a lot I as a programmer can do about it. If I regularly have to attend meetings that - in my opinion - are not necessary, than it's my responsibility to stand up and say "hey, I do not need to be in that meeting - I can spend my time more productively".

The same goes for interruptions: Yes, that's a hassle. I've seen it in quite a few companies. However, a lot of times, once again, there are several things that can be done. A programmer doesn't need to check his mail account every five minutes and respond to every mail instantaneous. Likewise, if I don't want to be disturbed for a certain period of time I switch off my instant messanger and forward my phone.

These are just two examples - there are a lot more. Yes, sometimes the going get's rough. But most of the time, the problems we're talking about could be fixed quite easily with a little more confidence. Tell the people on the other side of the communications loop "yes, I heard you and I got your message but I'll get to that later".

The biggest problems are those, that we're creating ourselves! ;-)

Answer 3

3rd party component bugs

It can be extremely stressful when you get an update on some 3rd party component that breaks something. You do not have the source code to debug or modify, but if your system depends on it, it can be pretty terrifying. Going in one morning to find that your source control server is performing unexpectedly and you might lose 2 weeks of check ins can provide quite a bit of stress. This is basically the idea of a leaky abstraction layer, when you are not prepared for it. Take a gander at the open bug tickets on any Microsoft stack technology and the comments will certainly give evidence of that variety of stress.

Answer 4

Unrealistic expectations. I see clients that expect that they can spend 6 weeks of a 7 week design period to get you the file you need to get started and wonder why it isn't done the next day. I've seen people who expect that they can hand you a new task on 4:30 on Friday and expect that you will spend your whole weekend to get it done for presentation on Monday to CEO. I've seen people who take you off one high priority task to do a second high priority task and then get furious that the first one isn't done on time. All of these things are stressful even when you have done your best to clearly explain from the start why their expectation is unrealistic.

Lack of ability to read minds. (I'm gonna make a fortune of I ever invent that mind-reading module.) It's stressful to find out in user testing that what they told you they wanted was not what they actually wanted.

Answer 5

Many of these provided answers are great, especially Joel's listed stresses and those relating to loss of money and pushy management who don't understand what they're asking for.

Some of the major stress I encounter come from

• Inheriting Spaghetti Code

  • I've had some insane experiences where the wheel most certainly needed reinventing. Imagine being hired on after another developer had single-handedly built up a codebase over a year or so only to find out they had no idea what they were doing, fail miserably and get fired. Upon arrival you're told your job is to 'make this work'. Of course there's about one line of notes per 4000 lines of code. Extreme lack of modularity and little to no direction. On top of it all, everything is far beyond having 'quirky' names (which are understandable and sometimes great imho) into just plain 'wth-ness'
  • You're supposed to have two sub points :P (Spaghetti code is bad, m'kay?)

• There's a bug. You KNOW for an absolute fact that it has to be the sort involving one or two tiny character changes. Deadline is tomorrow, you've got 3 features to finish up. This bug takes 5 hours to find and you can't ignore it. ;( Ouch lol.

• Trying to explain the previous

• Being stuck at a desk due to businessy constraints while if you could just go take an hour walk in a park and come back, you'd have golden code waiting to leap from your fingertips. My personal worst, I've got to see some trees and sky if you want me to make good code and fast progress. At least half of programming is an art after all. Find inspiration.

• Not being stuck at a desk when you've got to go home because of businessy constraints and can't just work 20 of your hours today while you're in the zone. Sometimes I click with what I'm doing and if I can't pull an all nighter right then, it's just not the same the next day.. I'll remember most of it but it'll take three times longer to get it down and not be quite as good anyway.

• Sometimes coffee/other consumables makes it worse and my brain just wont listen to my mind like I want it to. =)

• 15 minute breaks. Just enough to throw me off, not enough to make brain fresh. Boooooo.

• There have been times I was picking out a new library or..worse..a new framework. This has been one of the most surprisingly stressful tasks I've encountered. When it goes right or even ok-ish, it's lovely. Every now and again when it goes bad...oh boy. You can sit there cranking away at it trying out endless tests of different styles and get your head so filled up with too many interfaces that parts of my mind just start shutting down and saying "no, no... I wont do that. Too bad. Go away." Only to be forced to beat them into submission. Le sigh.

• The bad kind of linker errors. I'm not sure how to describe them.

• Importing large amounts of data from an annoying file format to your objects. This is sometimes pretty fun and often burns you out really quick when it's not. I remember working with this old excel format that had some very very tricky and undocumented escape character horror. This alongside the fact that the information in the actual column we were extracting was full of funky characters,... it still haunts me. I kept thinking "aha it works now!!....!............oh... nevermind.."

Answer 6

I think a lot of the stress is a result of the following premises:

1. Good programmers are often the people who can accomplish some non-programming task (production support/troubleshooting, documentation, answering questions from the business or other team members, offering technical opinions on future directions) most efficiently.
2. Programming is an activity that this best done in long stretches of uninterrupted time.
3. Understanding of Premise #1 >> Understanding of Premise #2.

As a result, programmers are often called on to do a number of different things, which erodes their productivity and quality of their work in their chosen craft. The manager who does this calling sees this as a "win," because the acute problem has been solved quickly and efficiently, and the cost is not immediately apparent.

There's some strategies for managing it, with various advantages and drawbacks.

1. Time management -- Devote some of your day to programming, and another part of your day to other work, and be disciplined about it. One disadvantage of this is that I ended up letting the non-programming work take up all my 8-5 time, and did my programming work at night, which is bad for work/life balance.
2. Education -- This is where people like Joel are doing yeoman's work -- getting the word out that the cost of a 15 minute interruption can be much greater than 15 minutes. (e.g. http://www.joelonsoftware.com/articles/fog0000000022.html)
3. Team development, documentation -- Ensure that you are not the sole source of knowledge for critical pieces of your company's technology.
4. Nasty Personality -- I'm only half-joking. If you develop the reputation of responding with a snarl to interruptions, people will tend to find other ways to get something done. You better be really good to pull this off, though.

Answer 7

The main stressor that I encounter is what I like to call "Mort Syndrome". Basically it's the attitude some developers have that mediocrity is okay, and there's no need to improve or do things differently, ever. As someone who spends time outside of work reading blogs and books, listening to podcasts and watching videos of better ways to do things professionally, I find this to really stress me out because 95% of the time I'm the only person on the team, if not in the entire company, who understands why, for example, writing unit tests are good or why it's bad to have thousands of lines of code in a single class (or classes that do half a dozen different things), and trying to educate my co-workers results in either blank looks, excuses of "We don't have time to fix it", "We won't ever use because we haven't ever used it before." or "That's not how we do things", or in worse case scenario me being shown the door and fired for trying to change things for the better.

Answer 8

It would be difficult to get a general answer to this question. People thrive under different conditions.

1. too much work in too short time
2. too little feedback from users
3. blame culture
4. lack of trust atmosphere.

I tend to find that work is the least cause of stress for most people, not programmers in particular. It's the extraneous items like company culture, unit atmosphere, communications issues that cause most stress for most people. It's not that they can't handle the work; it's that they can't handle the atmosphere in the kitchen if you like.

A more useful discussion might centre more on solutions to said problems.

Answer 9

"Other duties as assigned".

I've had to answer phones. I've had to work in the warehouse. I've had to do inventory. I've been in all day long company meetings. I've even had to go out and do limited lawn maintenance.

I don't know if I'll ever take another job that has that as part of the description.

Answer 10

Poor Management. I can't tell you how many stories I've experienced or seen of managers (especially senior managers and top company people) making outrageous decisions without consulting anyone who actually knows anything about the area they have decided on, or they don't consult notes from previous meetings before moving ahead in the opposite direction as was decided.