What causes developer burnout?

Answer 1

I suspect it's pressure from management. When you don't anticipate and allow setbacks, every bug in the code causes more stress and schedule slippage. The instinctual reaction from management is to stress the employee to work harder/faster. This accumulates over time and once the developer reaches their physical limits they burn out.

There was a semester in college when I took 5 computer science classes in a semester. Near the end I was working nonstop to get my projects finished and for a while after the semester ended I didn't touch my text editor. Eventually, however, I started working on my own projects again. It may take a while, but I suspect that the developer will resume writing software again.

Answer 2

Personally I think that your friends problems started when he started working "strange" hours and did not realize that something is wrong enough to elevate it to management.

Stopping one's self from being consumed and literally be eaten by work is a conscious choice and effort. Forcing one's self to stop working with the realization that working late is not only futile, but also means that more bugs are introduced into the system as you program in a less healthy mental and physical state. Eventually most of the work he did would have been because of bugs he introduced while in his depressed, stressed-out mood.

Why does burnout happen so often in our field? Because of the misguided belief that "pouring a few hours more into the problem" will solve them. How do we solve it? By learning when to quit.

Answer 3

Treat employees like assets, not liabilities.

I have experience in both the small agile company, and the big sluggish cooperation. The one main thing that sets them apart is that single point. At the large company, I was treated like a liability that was replaceable. That management style leads to the long drawn out projects you mentioned above. When employees have the mind set that they are expendable, they tend to grow to hate what they do which in turns leads to worse and worse code being produced. You see this type of decline all the time in factories.

When a project turns into a death march, management should recognize that there is something drastically wrong with what that project is trying to accomplish. Whether or not that problem is the developers responsible or not does not matter, something needs to change either way.

The best way to avoid burnout yourself is to only do what you love. If you do not love your current job, leave. The chances of it changing for the best are slim to nothing. Look at it this way, do you really want to look back on the last decade and have not liked anything you've done? Or have all of those memories overshadowed by the fact you had a job you hated going into ever day? Me neither.

Answer 4

Perhaps the Zolt cola drinking coding at 4am hacker mentality contributes to these problems. Steve McConnell wrote about this in Rapid Development.

Answer 5

Well all of the developers i have seen burnout are usually just pushed to hard by management. No matter how much you love something having to work at it to hard and to long will make it wear on you. Some peoples breaking points are sooner/later than others, that is just a personal limit we all have.

As far as preventing it, well until we can train managers to not slave drive their programmers i do not think we can prevent it.

One thing that could sure help is having standard work environments and expectations among all programming workplaces. Though for something like that to happen we would need a strong union movement. Here are a few organization working at just that goal. washtech programmers guild ieeeusa

I am a firm supporter of unions and the benefits they bring. Having a programming union and unionizing workplaces would basically keep management from burning out our friends and colleagues. Though it is a very ambitious goal, but every avalanche starts with one pebble.

Answer 6

maybe the guy is not happy anymore.

Answer 7

I'd love to say that it was all down to management, but it was probably down to an uncountable list of reasons.

Anyone that had read the widely-recommended book The Mythical Man-Month by Frederik P. Brooks Jr will say that many projects fail, project time-lines are often unrealistic, we widely disregard complications in implementing our ideas, and so on.

The answer to your question would probably take years of research. I like to think of Software Development like Cooking, mainly the act of preparing a Michelin Star Dish. Much like with creating software you have to take the raw components and deliver them in a perfect manner for the finished piece to be accepted. Everything has to work in the way you intend it, otherwise your goal will never be achieved.

The reason software development causes developers to become disillusioned with their trade is because it is an unnecessarily complicated trade, yet we assume that everything is going perfectly well because there is something working. If I may carry on the Cooking concept, it's the equivalent of cooking a piece of fish perfectly, but adding nothing else to the dish. Sure, the fish is great, but it lacks everything else that makes the meal. Anyone could cook a piece of fish, but unless you provide the sauce, the vegetables and the mashed potato you do not have a Fish Pie, and that is what the customer had ordered.

As The Mythical Man-Month claims the lack of calendar days is the biggest reason for a project to fail. If a project is taking too long and all programmers are working their hardest it is clear that the project life-cycle is to blame. This is what needs to be addressed and the Project Managers/Project Management Methodology at your workplace need to come under fire.

Answer 8

The Daily WTF has a great article about this. It basically says that the really good developers contribute as much as they can to a project fairly quickly and then realize that they are not performing to their potential. After that they get bored and either move on or get burnt out.

Answer 9

not being on SO causes burnout... we all need ways to relieve stress, burnout happens when there's more stress than someone can handle. get out of the office and have some fun, or browse through SO answering questions that have nothing to do with your work. just do something different to get your mind off the stress.

Answer 10

• unsatisfying salary
• feeling that your work is useless
• not believing in success of the projects
• not feeling yourself as a part of the company
• bad relationships with colleagues\managements
• idiots all around the place :)
• no challenge
• boring work (99% of maintenance)
• stone age technologies (new tech is a big no-no)
• being in vacuum (you don't know what's happening on project)

Answer 11

As mentioned in The Other Burnout Thread, my two burnouts were caused by escalating requirements and shrinking timelines.

Management, and most importantly managing expectations, is key.

Answer 12

The thing is to balance your work with your social life.

If you take your job too serously, and start staying late for a log period of time, you get burned out. You have got to have a social life, even if you have to force yourself to go anywere after work.

If you have a bunch of good friends, a family, anybody, it's easier to get by the hard times.

I'm not sayig that it wasn't the managements fault, an unrealistyc deadline, or something, but there always will be pressure and frustration in this line of work.

The most important thing is balance, at least that's what I think.

Answer 13

I think your friend is the type of person that wanted to get the job done and perform each task to the best of his ability. When everyone miscalculated the timeline and the weight of the project is on one persons shoulders and he isn't the type to accept failure, you have a recipe for burnout.

The other people on the project probably worked their "day" and went home and forgot about the failing project while this guy worked himself to sickness.

I think the Project manager is probably lacking in this case.

Answer 14

For myself, the answer lies in losing my spark at work, which can be characterized by a few things:

1) My boss brings me a sense of dread when he or she comes around. Rather than think, "Oh, I wonder what is up," I tend to think, "What does he want, now?" with the connotation of being a taker and not really giving anything back. Or, the boss comes and says, "Got a minute?" when really he means the rest of your day will go onto this here thing I just found.

2) My ideas are put down, ignored or considered a joke. For example, I may have an idea for some new whiz-bang-y feature that I tell my boss about and get a, "Well, we'll see. Maybe we'll get to it," or on wanting a change in how work flows through the office that gets met with nothing after multiple times of explicitly asking, "Could we work like this?"

3) When I know the legacy systems along with the bureaucracy all too well. Most of the companies I've worked for were young in many ways but they all had their share of the ways things used to get done and that there were 101 issues that I knew existed and weren't going to get fixed.

4) When the team I'm on loses its drive. Rather than be a team that is on the go and getting somewhere, we're all going in different directions that seems pointless enough that I lose my desire to work hard.

5) When communication has lost all enthusiasm and humour. I'm not saying I want the place I work at to be all jokes all the time, but there should be some joy in being at the office from my view, some reason to come in and have the attitude, "What will I rock with today?"

6) When finishing something means more problems. An example here is where I finish the features for a new release and as I put in feature A, out comes enhancements B, C, and D to do ASAP. Or in fixing a bug, I find another few bugs and my work load keeps going up and up and up until.... Another way to see this is the notion that my work is like a killing a hydra where for each head I chop off, there are 3 more that grow back and I keep swinging and swinging knocking off a large number of heads, but then think about how many heads there are by then, e.g. if it had 5 heads to start and I chop off each of the original ones, there are 15 at the end of that.

Preventing it can be simple if the environment can be changed into a nuturing one, where there is some connection and the management does know how to run things well. I could work on older technologies all day long if I felt that my work is appreciated and that when I got into the office there was a feeling of, "Wow, now that you're here we can do these awesome things!" or something similar. It is the question of how much of myself is in the job and how much of the job do I like.

Answer 15

Coming late I still want to try addressing two questions you have raised. But first, lets see how burnout is commonly defined:

Burnout is a psychological term for the experience of long-term exhaustion and diminished interest (depersonalization or cynicism) Wikipedia

Why does burnout happen so often in our field?

Well, software development as a field is notoriously susceptible to the plague of over-optimistic estimates and resulting unrealistic schedules, missing and constantly changing requirements, relentless technological change and high expectations.

It is like finishing a second lap of a mile long indoor race only to discover, that the distance had blown up to half a marathon and has been swelling further since, most of the track is going to stretch through a cross-country terrain and your competition prefers driving to running, but still you are expected to finish within next 20 minutes.

Given the situation any sane person would have given up and quitted straight away, apart from the fact that things are not quite that clear and measurable with software. It always seems that you are almost there, at the finish straight, one last step and you cross the line, a winner, but the distance keeps increasing.

How can we prevent it?

The easiest to prevent a burnout is either being realistic about what is achievable within constraints or not setting constraints altogether. And I talk about time above all, because it is time that sets the pace.

The next great thing is letting and helping developers to influence and improve their environment to achieve the goal. Give them the leverage what is needed.

And the third point is to make an effort to celebrate achievement. Positive stuff needs to be commemorated, for the events to stick in your memory and give a boost at inevitable times of low.

Obviously due to its position management has the most ability to make these things happen. However, there things that can be done by a “mere developer”:

• Whether you feel that a manager tries to superimpose an unrealistic deadline or there is very little current evidence in support of an estimate or actual feasibility, just ask how they envisage the task being managed or implemented. It is best to convey the unrealism of expectation not through opposition, but good, constructive questions.
• Keep changing your working environment. The little things, acquiring better tools, techniques, making your workplace more comfortable.
• Celebrate your own achievements and the achievements of others. Schedule it. Few people have the ability and the skill to make a day feel special.
• When in an adverse situation, do not equate it to your life or aspirations. Sometimes a single person effort is not enough to overpower other factors and unless you can make an alliance just quit. It is silly to try to cross an ocean in a leaky boat lead by a drunkard captain, who is followed by inept crew. There are plenty of solid boats, sober captains and skilled seamen.

Answer 16

One burnout pattern I have seen is frustration over dictated solutions.

Generally, the motivation of a good developer is to create good solutions. When details of the solutions are dictated, and especially if they are dictated more by business interests than technical merit, it leads to frustration.

When someting can be solved very elegantly by using solution X, but management has dictated that you have to use solution Y, motivation leads to frustration. Burnout next.

The real problem is how decisions are made. Sometimes management will make a decision that is neither well-informed or well-communicated. Sometimes management should listen more to developers, or leave the technical decisions to those with technical knowledge.

I have been in companies that

• Has hired a top notch .net developer only to tell him to choose between localizing a Delphi application or using Visual FoxPro
• Has strategically selected Oracle db platform even though all the developers and operations people knows and prefers SQL Server, and then not funding development tools or training
• Has forced use of a java component, interpreting a proprietary and undocumented script language, to do a simple calculation even though everybody else uses .net and it would be easier to hardcode said calculation in C#. Purpose: taxdodge. The java component comes from a central part of the global company, and carries a 50% kickback.
• Has dictated that a certain dll from a ISV has to have its own physical server, even though it would be easier to just call it from the same machine. Creating the unnatural need for a whole new service and TCP communication scheme.
• Has forced developers to follow some ridiculous SOA structure only because they spent huge amount on consultants to make a proof of concept. The concept then becomes a holy cow because management will loose face if the concept isn't used.
• Has hired architects with no technological skill. The word architect means arch-technologist.

Answer 17

Ultimately I think it comes down to a negative balance of achievement to effort. By that I mean the developer is putting in more than they perceive they are getting back.

As I'm sure Jeff & Joel have blogged before, we as a group tend to have very internal loci of control, we do what we do because it interests us and we love it. Rarely do we work purely as a result something external (e.g. financial reasons), we do it for the sense of success we get when we complete something, or the sated curiosity that comes from truly understanding.

Whether natural or built up through constant exposure and experience I think we also have, or like to think we have, some innate understanding of the way systems work. Thus when presented with a system that is no longer working the way it was originally, we're no longer feeling the same buzz being returned for the amount of effort we input, we attempt to analyse and debug what's going wrong.

Typically this can be simplified to a lack of control over our environment, often manifested through issues like being stuck on maintenance or never-ending projects while other developers get the new "cool" work, having to work with old tools or systems when we know of better ones, or even being placed in an work space where there's no space to think or reason. It may or may not be immediately or consciously obvious that the system is broken in this way, but I still think that we grok it on a fundamental level.

Thus the first response most readily available then becomes to just give up and accept defeat, accept that there is a massive bug in the system but that it's not within the programmer's power to fix it. That, to my mind, seems an unacceptable option to the kinds of developers that are likely to suffer from burnout. To them every last bug should be out of the system and they want to see it working properly as intended, anything thing else and the solution's not right, the problem remains unsolved.

That leaves the other option, to adjust the only variable within their control - the amount of effort they put in.

Of course, the hope is that with increasing the amount of effort there will eventually be a sense of achievement to equal all the extra work. Unfortunately it then becomes a vicious circle and all the extra work put in just fuels a growing resentment. Burning out then comes when the programmer finally gives in and chooses option A (often compounded by a feeling of failure due to the perception of a bug getting the better of them).

As a demographic we're actually relatively easy to please. Give us tangible benefits and we're happy - somewhere quiet to work, interesting problems to solve, some variation, and a challenge and we'll be well away coming up with all kinds of new and interesting solutions to your problems. Deprive us of those things and eventually we'll fall into the pattern of becoming desensitised to the ever more rare sense of achievement, or worse, we'll leave to working for the competition.

Given that it seems somewhat surprising to me that we're more often treated as grunts there to stack the shelves with code so the business has something to sell to its customers. But then I suppose I'm on the inside looking out, and I have to accept that the men in suits will never really understand what makes us tick.

Oh yeah, and wearing suits sucks too.

Answer 18

You want a story? I've got one for you.

In 2007, I and a number of other developers were called upon by our new management to produce a software release that the prior regime had suppressed for years. The problem: it was at least a year of construction work, but we only had half a year for detailed design, construction, QA, and release.

Honor bound to produce what we said we've wanted to produce for years, and having a real love for the product, we dug in. Several of us wound up working anywhere from 80 to 120 hours a week for most of the six months. In the end, we successfully released the product on time.

The aftermath was expensive. One top developer quit. The rest of us haven't really spoken much about the lingering effects, but I'm sure I'm not the only one to have suffered. About 2/3rds of the way through, my metabolism started shutting down from the stress. I had chronic low body temperature in the 96-97 degree F range (my normal was the high 98 previously) and on more than one occasion I woke up at 95 degrees. Actually, I had trouble waking up those mornings, because 95 is right on the threshold of hypothermia, and if I hadn't gotten warmer upon wakening I would've had a medical emergency that could've killed me without a trip to the ER.

I took a six week vacation after the project ended, and started a course of hormonal supplements to get my various glands up and running again. The hypothermia stopped, but it took months for my body temperature to stabilize (though 'normal' for me now is still in the 97s, not 98s.) I also feel that I'm not thinking as quickly as I used to, though that seems to be slowly improving.

Yes, I'm still with the company. Yes, top management is aware of the cost of the project, and since then has a directive and policy which is intended to prevent repeats. This has been reasonably successful; we've had crunch times, but never involving as many people for anywhere near as long. I still feel the effort was worth it, but I wouldn't / couldn't repeat it. Career-wise, I'm moving myself out of front-line coding to a higher level position, and the company is backfilling beneath me so the workload can be spread across more people. I'm still burnt out in the sense that I'm happy with not coding as much (I never expected to feel that way), but I'm not so burnt out that I want to completely change my career. (I did contemplate that for a while, though.)

Answer 19

Crappy management. Poor work environment. Sub-standard compensation.

Lastly, and most importantly, and is in fact part of the work environment: CRAPPY code, and this is usually mananagement's fault for not paying off their technical debt.

Answer 20

I guess there needs to be a balance between salary and interest plus a healthy work/life balance.

What could help is to attend some soft skills trainings like e.g. time management.

It is certainly NOT only a matter of money.

There are many jobs where you could not pay me enough to get me doing them.

There are a few others where you could pay me less than I would deserve and I would still go for it. (say doing my embedded stuff for Disney)

Answer 21

A interesting reading on this topic is this blog post.

"Burnout: running on empty"

Answer 22

There are many reasons burnout happen
However, there's a very simple preventative solution to avoiding burnout:

Boundaries.

Your fellow developer needed to set some boundaries.
Come in at 9 AM, leave at 5 PM.
He's worked his hours.

Quit the passive aggresive BS.
Sever any emotional attachment to their project.

Enough said.

Answer 23

The Red Queen's Race of Technology

"Now, here, you see, it takes all the running you can do, to keep in the same place. If you want to get somewhere else, you must run at least twice as fast as that!"

I enjoy working with new technologies, but sometimes it just gets ridiculous. The pace of change in programming tools and methodologies makes it so you can't really ever truly become an expert at anything anymore unless you hyper-specialize.

I miss being able to get into the nitty-gritty details of some technology and find my comfort zone. The pace of change used to be just slow enough so the new thing would come around about the time I was getting bored with the old thing.

Also, it just isn't that exciting to switch to a new technology that doesn't really give you all that much new capability, but rather just forces you to relearn how to do what you already know, for example:

• ODBC
• DAO
• RDO
• ODBC Direct
• ADO.NET
• LINQ
• (N)Hibernate / ORM

or

• ASP
• ASP.NET
• ASP.NET MVC

Answer 24

When I was working part-time as an undergrad I had a couple of bosses who would do that "in my extensive experience, that should only take you a couple of months" trick on what were really quite involved projects (which I nailed with a great deal of effort).

The idea was to instill a bit of self-doubt and guilt to make me think I should always be working harder so they could get maximum effort out me of while they had me.

An old trick for the newbie, also done to summer interns and fresh graduates. There's a couple of big cubicle farms here (such as Trimble and Allied Telesyn) that pump up egos of the fresh young grads and try to screw as much out of them as they can for a year or so, knowing they will quit and find a decent job, so the race is on to get something out of them in that time.

Beware those kinds of bosses.

Answer 25

IMO, what causes burnout: putting people into situations in which they perceive that there is no way out. Early animal studies on the etiology of depression have shown that if you induce the stress response while making it impossible to fight/flee, then you can successfully destroy an organism's nervous system and artificially create a state of "conditioned helplessness." On the African savanna the stress response was very useful for us - it kept us from becoming lion food in specific instances. However, the stress response was never meant to be kicking into high-gear 24/7, and having it elevated continuously leads to burnout, a.k.a. General Adaptation Syndrome - the true pandemic of our time.

This would seem to be an unfortunate byproduct of our system, though in certain instances I've witnessed psychopath managers putting people into hopeless situations intentionally in an effort to break their spirit (remember the ditch-digging scene in the movie 'Cool Hand Luke'?). But without continuing to dwell on the negative, given the above, here's my suggestion:

• Promote and facilitate novelty in the workplace: certain studies on the brain's reward pathway have shown that human beings are driven by the urge to experience new and exciting situations, as opposed to Freud's dated 'pleasure principle'.
• Always allow people to be understood and heard. See also: Dale Carnegie's "How to win friends and influence people".
• Keep the programmers in a state of "flow" (Read the book "Flow" by Mihaly Csikszentmihalyi). Basically strive for projects that are challenging and intrinsically rewarding but not impossible. It's admittedly a fine line to walk.
• Change the basic rules underpinning our system from a relentless drive for maximum profit to something more humane, like having a rewarding work experience at the micro level. This is a fairly far-fetched goal at this point but it's always nice to dream.