Why there’s so much burnout in software and what to do about it

Why There’s so Much Burnout in Software and What To Do About It

This is a post in my occasional series, Notes to a Young Software Engineer. Sign up here.

Melancholia (Wikimedia)

I was programming alone in my apartment — the GPU heating my cold apartment, a few days stubble on my face, and my last human interaction eight days before — when burnout hit me.

At the time, I was attempting to will my 3D printing CAD startup into existence with a remote team. Initially, working out of my apartment meant I could code without interruption. Then the isolation became stifling. Days would go by without seeing another human, other than a sporadic Skype call.

Given our limited funding, I did more than I bargained for. Not just the backend coding and algorithmic work I so enjoyed, but the frontend development, the marketing, and the fulfilment.

Interacting with our users even became discouraging. I would get angry emails when our free software — which we had built for fun — was sporadically offline.

“I appreciate your explanation [why the website was down for 24 minutes] — and the fact that it’s free — but if it isn’t accessible it’s of no value.”

Eventually, my productivity ground to a halt. It took me six months to recover.

Burnout is Everywhere in software

My burnout story is hardly unique in software engineering.

In gaming, an interminable “crunch” around launches got so bad that a spouse wrote an open letter to Electronic Arts’s management:

I’m what you might call a disgruntled spouse … The current mandatory hours are 9am to 10pm — seven days a week … The love of my life comes home late at night complaining of a headache that will not go away and a chronically upset stomach, and my happy supportive smile is running out.

In open source, Steve Klabnik famously and publicly called out a critical user in a Github issue, saying “You are [the] reason people burn out on open source. Don’t be such an ass.” As Mike Perham from Sidekiq echoes, the common open source journey is:

- start project with much enthusiasm- build something valuable, give away for free- get overwhelmed with support requests and issues- burn out and walk away

In startups, we consistently commiserate about burnout. The roadmaps are never-ending and the resources few. The continuous iteration in pre-product market fit startups leads to a high number of discarded features — thrash — that tests morale.

The burnout confessional has become its own genre in software writing. The top 50 HN burnout posts elicited tens of thousands of upvotes and comments.

After the worst experiences, my friends have never been the same again. The joy they derive from programming is never quite what it was, their passion never again so palpable.

For engineers early in their career, I’ll make a few observations:

Nearly every software engineer will experience burnout, probably more than once. Certain parts of software — startup engineering, gaming, open source — are especially prone to burnout. Try to identify burnout early, as it becomes exponentially worse over time. Since each person is different, experiment with your own strategies to hold it at bay. And the ultimate goal isn’t always less work, but leaning into activities that unlock you.

What is Burnout?

To address burnout, you have to be able to identify it.

Technically, burnout is “a state of physical or emotional exhaustion that also involves a sense of reduced accomplishment and loss of personal identity.” Burnout is often due to long-term and unresolvable job stress. You may feel emotionally drained or alienated from those around you.

If that sounds broad, it’s because there are conflicting views of how best to define burnout. Professionals also debate whether it is an actual disorder (DSM-5 doesn’t include burnout as a distinct diagnosis).

In my view, burnout is working on things you don’t enjoy — coupled with a lack of agency, reward, and recovery. You have unending long hours, with little prospect of downtime leading to resentment and exhaustion. Or you do something valuable, but the reward was far from what you were expecting. Or you have ideas for how to improve things, but don’t get the autonomy or trust to make them happen.

The biggest fallacy about burnout is that it is due to working too hard, and the surest way forward is to cut down on hours. While sometimes true, I’ve also been intensely excited working 100 hours a week, while feeling burnt out at 30 hours/week. As another developer makes clear, “I wasn’t overworked, but I was exhausted all the time.”

It’s also important to note what burnout is not, given how its symptoms coincide with other conditions. Depression, ADHD, boredom, laziness are commonly mistaken for burnout because the symptoms are so similar.

Depression is a clinical condition where low mood is consistent. It comes from factors beyond just your environment, like genetics and psychology. Unlike burnout, depression can’t be addressed simply by taking a break.

ADHD is characterized by difficult paying attention and behavior without regard for the consequences. Boredom is more about a lack of stimulation. When you’re unsure, there’s value to finding a licensed professional, rather than chalking up challenges to burnout.

Why so much Software Burnout?

Why is there so much (anecdotal) burnout in software? Software engineering is challenging — but it hardly compares to the stresses in, say, nursing, law, and the armed forces.

Software engineering has no boundaries. Rather than a set amount of hours each day, work is driven by idealistic management deadlines. As one senior tech CEO told me, “I knew there was no chance of hitting my deadline, but I wanted to push the engineering team to work faster.” Under-resourcing is common because developer recruiting is hard — and expensive.

Unclear or rapidly shifting direction leads to burnout, as is common in new products, startups, and highly political environments. Features that never make it into production — or are quickly deprecated — remove the positive feedback that engineers value.

The bus factor is low, meaning a small group of developers are the only ones available to maintain or build certain components. This dependence makes it harder for them to take time off. Pager duty responsibilities and customer complaints disrupt sleep schedules and lead to an always on mentality.

Programming is isolating. A developer’s day is spent in deep concentration in front of a computer screen. Teams can be remote — or simply small — which further reduces human interaction.

Engineers can have unwelcome responsibilities thrust on them. A common burnout story is an engineer who enjoys programming, suddenly “promoted” to management and expected to perform in this new role without support.

In open source, true enjoyment comes from “first code” — writing new systems from scratch — rather than the draining work of maintenance. Impatient or ungrateful users can especially destroy the fun of writing OSS. Open source, and many small teams, also need to do work in business, marketing, and design, which might be far from their area of interest.

Many new programmers have a hard time transitioning from their youngest years of coding for fun — where long hours are energizing and the work is done for yourself — to coding for others. As one new developer noted, “I loved CS back in college, but my job [afterward] felt like a punishment.”

Identifying factors that lead to burnout make it easier to address these problems before they become debilitating.

Prescriptions

The basics of beating software burnout are widely known, if poorly applied.

Try to reclaim autonomy and choice. Take regular breaks, try breathing exercises, meditate. Get enough sleep. Foster hobbies other than programming. Limit social media. Eat well. Use caffeine carefully. Over the course of a typical year, don’t skimp on vacation.

Start by prioritizing 3–4:

One developer’s cheat sheet for staving off burnout (Colin Nederkoorn)

For me, three that are especially important are treating my body well, cultivating human relationships, and addressing root causes at work.

Since so much of a software programmer’s day is sitting, it’s critical to build physical movement into your day. It will lift your mood. Yoga, running, dancing, qigong, weight lifting are popular suggestions. Physical movement can also break up your day. Every afternoon, I aim to take a 15 min walk. Even when work is interminable, I almost always clear 30 mins for a workout. And then, I aim for 8 hours of sleep for at least a few days each week.

Ongoing relationships with family and friends are critical to staving off burnout. Spend time with people who bring you joy, even when there’s much work to be done. If you work on a small or remote team, build a group of people that you will regularly talk to. Taking one step back — “wasting time” by spending it with family or friends — will often make you more effective, rather than less.

Building a relationship with your manager is critical. Talk to your boss about burnout symptoms you are facing. Great managers can identify this and support you as you recover. Even self-interested managers realize how attrition or reduced productivity will impact them, if they don’t catch burnout early. If your manager is not the type you can have this conversation with, it may be a good sign that this company isn’t the right long term fit.

Address root causes. Go through the factors that lead to burnout in software, and make a list of which ones you deal with. If you’re working at a company with constant crunch or lack of autonomy, have the conversation with your own family about whether the job is worth its cost.

If these suggestions seem idealistic, it’s because they are. Few burnout strategies survive first impact with the real world. Myopic management, financial responsibilities, and demanding customers will all conspire against you. But these suggestions are a starting toolbox for what strategies you have available when things inevitably get bad.

Once you’re burnt out, it will take time to recover. As one developer notes, “It wasn’t a situation where you simply remove a stressor and everything automatically gets better.” Be charitable to yourself if it takes months or even years to recover.

And if you have trouble addressing your feelings of burnout, experiment with a therapist rather than trying to muddle along.

Getting Back to A State of Play

An aspirational goal in software is to get back daily to the state of play that attracted many of us in the first place. Most developers I know started because programming was the same as childhood play.

To get there, start with two basic questions. What does a state of play look like for you? What tangible things can you do to inject more play in your day?

As Richard Feynman once reflected on his own burnout experience:

I used to play with [physics]. I used to do whatever I felt like doing — it didn’t have to do with whether it was important for the development of nuclear physics, but whether it was interesting and amusing for me to play with … So I got this new attitude. Now that I am burned out … I’m going to play with physics, whenever I want to, without worrying about any importance whatsoever.

One developer echoes his own journey back:

“[I got] back to the basics — started learning some ML and webdev. Built and shipped a side project

Despite its prevalence, burnout is far from the inevitable terminal state in software engineering.

This is a post in my occasional series, Notes to a Young Software Engineer Sign up here or follow the RSS feed. All pieces in this series are published as drafts, with relevant community feedback incorporated. Thanks to thousands of Hacker News comments for providing the raw material for this piece.

Resources

• Maslach Burnout inventory
• Book: The Truth about Burnout (Maslach and Leiter)
• Book: Happiness and Burnout, HN Post: Recovering from Burnout and Depression (Kieran Tie)
• The Upside of Stress
• Understanding Burnout, Professor Christina Maslach (video)
• The Reality of Developer Burnout, Kenneth Reitz

Why there’s so much burnout in software and what to do about it was originally published in Hacker Noon on Medium, where people are continuing the conversation by highlighting and responding to this story.