I’ve yet to see a really good essay by anybody who isn’t a developer talking about engineer burnout. JWZ, Rachel Kroll, or cbloom (back before he zorched his rambles) are all good examples, but otherwise I haven’t seen a lot else.
I’ll add some data points to it, go in-depth on what I think causes it, and attempt to offer some advice for engineers and managers.
Important note 1: This is all very heavily-based on my own experiences, as a beginner up to now senior developer with experience bootstrapping (and failing), hiring, and growing teams, and grinding on terrible projects. My experience may not match yours. That’s cool. Go write your own blog post about it and help bring sunlight to a nasty topic.
Important note 2: Burnout sucks. This should be discussed solemnly in person, on IRC, or over email, but until that’s more common maybe this will help people find a starting point. I’m sick of self-serving Medium articles and Twitter circlejerks with people singewashing their experiences for pageviews.
Examples and stories of burnout
Three example stories I’ve collected, redacted to one degree or another, none are me (that’s a different section):
Dev works at game company in crunch, postpones sleep, eventually starts seeing noses on everything. His own hands. Car’s dashboard. Trees. Finally stops after a couple of weeks of sleep.
Dev works at a startup, spends a couple hours every week on a couch just kinda staring into space. Eventually quits, won’t talk to folks from that gig.
Dev works at older software company, one day stabs self in the neck with a writing implement in the lobby of employer and bleeds out until paramedics get there.
Note that those are the final battles of whatever war the people were fighting—healthy people don’t exhibit those behaviors unbidden overnight.
Things I personally have done, witnessed, or handled the fallout from:
Dev quits immediately after finding out a long-requested performance review was done mainly to fire a coworker.
Dev under massive pressure from outside of work runs late for a standup and gets really flustered. Is taken for a walk to clear their head and reassured that nothing is as bad as feared.
Dev breaks down crying in front of execs after crunch to get last part of a project finished—during demo, only feedback was “why is x missing”.
Dev accuses management of lying during team lunch, is invited to meet the following hour, puts in one month’s notice and leaves. Is unable to program for a few months for any reason without getting irrationally angry.
Dev disappears into the mountains to avoid any chance of contact for a few days during a critical deliverable just to get away from business pressure. Contractors cheerfully negotiate weekend, active-fire rates.
Listed as sanitized bullet-points, these stories look out at us from the monitor as flaccid little factoids. One of the things you have to understand is that, from the outside, any individual case of burnout looks really uninteresting.
To get the full picture, you have to get on the inside of the situations. What I’ve left out here is the context for each one, the people involved, the projects, the companies. Sometimes I’ve done that out of respect for the parties involved, sometimes because it’d take to long to explain, and sometimes because I frankly can’t really figure out how to go into the story in a way that wouldn’t distract and detour from the rest of this post.
It took me a few months after quitting my last job to start being able to open up about what happened (a story for another time). Interestingly though, to me, that in short order I ended up with a few friends over hot chocolate (caffeine being bad for the nerves for a lot of us) exchanging these stories—people with careers half as long, twice as long, the same length…everywhere I probed, I could usually find somebody with a story.
That’s scary as fuck.
Who gets hit?
“Angersock,” you might say, “this is something that just happens to those wacky folks chasing the dream out in the Bay area, or to already unwell individuals experiencing the stresses of business.”
To this, I say no. Those stories? Hardworking folks, recovered to varying degrees (I think) thankfully. All happened in flyover country in nominally pretty normal populations. These aren’t the folks you’d expect from some freewheeling, white-hot Valley VC pump-and-dump gamble, but folks doing relatively straightforward work for normal pay and with only occasionally weird environments.
I’d like to be able to claim that there was some pattern to it, some demographic at risk beyond “do you sling code for a living?”. Alas, I haven’t found one. I’ve seen this happen to both men and women, gay and straight, cis and trans, young and less young, left and right, single and paired, and it keeps happening to some poor soul regardless of where they fall in that lineup.
In a way we can find that both scary and reassuring since it implies that the damage comes from a working environment and not something in the makeup of the person. If we can figure out what environments lead to burnout, maybe we can repair it or at least recognize when it’s happening.
Anatomy of a burnout
Two major areas of suffering are required to cause burnout: the work, and the environment.
Work factors for burnout
The work that I’ve seen lead to burnout tends to be:
- All-consuming
- Uninteresting
- Lacking visible progress indicators
- Lacking a clear end date
Let’s take an adversarial approach to this and pretend we’re trying to design work to maximally distress our developers.
All-consuming work is work that takes priority over everything else. The occasional shitty gig or task is annoying or inconvenient, but for burnout to happen the work itself must eclipse every other thing in the developer’s working life. Writing from an American perspective, knowing that many workers are probably putting in 8-9 hours a day at their job, it’s important to note that this means that something like a third of their daily life-force is being taken up by a project. If you decide to do your accounting to focus just on time spent awake, then the bloody thing is taking up, at minimum, half of their waking time (assuming they’re getting enough sleep).
And here’s a dirty secret: if they’re younger or more “passionate” or frankly just plain single, they’re probably going to give even more waking hours over to their work because there are fewer competing demands on their time.
So, if things start going south with the work, it’s easy to see that there just isn’t an escape from it. Lucky for us, this is the cultural norm and expectation in the US, and so we don’t actually have to go out of our way to make the work permeate every part of their life.
Uninteresting work is work that does not stimulate the exploring or learning modes of the worker. This is a slippery one, because it sounds a little too much like whining that “oh gee this is so boring, I’d rather learn a new JS framework.” The typical response to that cry is “well, not all of us get to do fun work.”
However, fun is precisely not what I mentioned—uninteresting work is uninteresting because it is predetermined and doesn’t help the developer grow. Examples of this work that I’ve seen include:
Many UI/UX projects (design given, implementation delivered, testing done, tweak suggested, repeat) on the same interface, over and over again (because selling something is harder than polishing a turd and so biz will chase that instead of just selling harder).
Gradual refactoring of a codebase, where each individual step is trivial but there’s just so many of them—and this is why big-bang rewrites often happen, because that’s just less terrible than trying to mop up a floor with a muddy mop.
Bringing a large codebase into compliance with a style guide, though this is a lot less terrible than it used to be due to tooling improvements.
Constantly keeping on top of a codebase that’s changing out from under you, which easily happens if you work on a long-running feature and others are in the same codebase. Fixing conflicts isn’t hard, it’s just tedious and you are often rewarded with…more conflicts!
Bughunting and ops stuff, once you’ve gotten the hang of things. The only “new” info you ever learn about a production system is that it is broken or, even worse, that it is somehow managing to deliver value despite having the software equivalent of hyperdimensional aggressive bone cancer. Instead of merely not affording chances to learn or explore, this work actively punishes you for digging into the abyss.
Lacking visible progress indicators is part of work that disorients and confuses the worker. At this point, our dev is on a project that is consuming most of their waking hours and is doing something that is not causing them to explore or learn. So, next, let’s take away their frame of reference and make it so that the work that they are doing never appears to get any further along.
If it’s UI work, constantly send it back for rework so that they never see progress, only change. If it’s ops work, don’t track a baseline to make it easy to see if the system is getting more stable or less stable. If it’s refactoring work, the entire point is that to an external observer nothing is different regardless of how much effort was expended.
We can also modify our process to make this even easier: have product managers intermediate the developer’s exposure to customers. Use story points and chop up tasks into small Jira tickets so that it’s hard to piece together the overall view of where a project is going—and never, ever use thorough acceptance criteria to give developers a way of seeing when they’ve actually delivered what needed to get done.
Remember, you never want the developer to hit a wall or stop, because that is actually a useful form of feedback. Instead, you want them to continually spew life force out into the all-consuming maw of your project in such a way that maybe, just maybe, this feature will be enough to move the needle and get them unstuck. Humans are very responsive to this.
In short, the developer should never feel like their actions have any actual positive impact on the state of things but should have just enough hope that maybe the next time will be different.
Lacking a clear end date is how to get work that cannot be bounded in its suffering. If you have a hard day serving coffee or working the help desk, at the end of your shift the work is over and done, and however bad things are they end. If you tell somebody that they only need to hold out for six more hours before dinner, they’ll get hungry but they can pull it off. A project with a hard deadline of launching on Christmas day, while stressful in its own right, is out of the hands of everyone December 26th.
To really grind the bastards down, you want to make sure that there is no strong timeline that can be used to internally gird themselves. If the developer can say “Well, if I can make it to launch this week, everything will be fine or at least it will be over” then they may be able to hold out long enough to see themselves through to the other side of a bad project. Instead, prefer to constantly renegotiate deadlines and “buy extra time” to keep a purgatory project going.
Why do this?
The most jaded developer will call upon deep wells of fatalism and make their peace with a project failing, write it off, and square themselves to face things anew. They may be able to make their peace with impending failure and start planning the next project or their next gig. If you keep extending the project, though, there is no chance to write off the future. There is no opportunity to heroically make one last desperate push. There is just a modified Gantt chart stamping on a programmer’s face, forever.
Further, you can cleverly increase even further the internal pressure a developer is under. If you refuse to fire them, but you also refuse to let the project die, they are forced to work on something that is traumatizing them knowing full well that the only escape is to either finish the project (unlikely) or quit themselves (unsatisfactory).
Given this option, many developers will double down and become their own kapos, prisoners to their work but foolishly believing that they are doing so of their own free will and that the work has some intrinsic value to them—after all, it that wasn’t the case, why would they be doing it? The most prideful and otherwise wily programmers can be thus brought into line.
Environment factors for burnout
Let’s take off our adversarial hat, fun though it is for the rhetoric, and just talk plainly about environmental factors outside the work itself.
Some environmental factors I’ve seen lead or contribute to burnout are:
- Lack of non-work havens
- Health issues
- Lack of non-work support networks and preoccupations
- External reminders of happiness and progress
Lack of non-work havens is faced by developers who basically split their lives between an uncomfortable home and a soul-sapping office. Without a home, cafe, bar, park, museum, library, or space to unwind and relax, there is no opportunity to let the mind unwind and stop thinking about the project. There is no place to “find zen”, no place to force a shift to some other modality of thought, no way of telling the body “hey we’re in a place with stimnuli that do not mimic the place that we’ve come to associate with this project that is slowly eviscerating us.”
This can get really gnarly for remote workers, and one of the most common bits of advice shared is to make a dedicated space for work and to also leave it and get out of the house. Further, spending time “getting away” from work only to be surrounded by people talking about the startup hustle or similar project material can ruin any benefit from leaving your work—instead it’s followed you and is reminding you of what you were doing!
One unfortunate wrinkle on this is that a lot of young engineers, due to preference or due to finances, tend not to settle down in a super comfortable place. They may have super long commutes, they may live in a tiny cramped space, they may not spend cycles cleaning, they may have roommates—all of these are things that can make staying longer at work seem reasonable or desirable. I was one of those engineers, and only after finally getting my own place and making a concerted effort to transform it from being a house containing angersock to being angersock’s home did I find relief to a stress I didn’t know that I had.
Health issues can exacerbate burnout. Chronic fatigue, bad sleep, low energy, and any physical factors that get in the way of enjoying time away from work hurt us. Developers with depression or anxiety suffer even more during burnout, because they’re already operating with a handicap in terms of being able to fairly evaluate their own work—and as we saw above, perspective is a key component of what makes work induce burnout.
Believing that we don’t deserve to work on better projects, believing that the world will come crashing down (and if we’re under financial stress, that’s not an unfounded concern even before mental health enters into it!) if the project is abandoned or we don’t deliver, believing that if we stop working on a project we have failed ourselves or our mentors or our parents or our partners or the people who support us…all of these things make each low point lower in turn exacerbating the burnout.
While those beliefs are, I think, common in one form or another to any healthy person, folks at risk may take them to a point of rumination ) and be unable to find respite until something causes a drastic change of circumstances.
Lack of support networks again help prevent the formation of useful frame and perspective. Without having people outside of the project to confer with and socialize with, we lose the ability to keep the project at the right level of importance in our life. Without a hobby or stimulating activity to give us alternatives to work, many of us will keep devoting cycles to worrying about the project and trying to sink effort into it—and left unchecked, will often start to abandon support networks and activities in order to free up time to push past the rough spot in the burnout. This of course never works, because the projects usually don’t allow for it (again, see above).
Compounding this is the fact that many of us have switched cities or locations away from family or friends in order to work on our current gigs. Many of us are also engaged in “startup community” activities that frankly boil down to little more than drinking together and trying to sell each other on a vision of success that none of us are living. Such activities only serve to alienate us from people who, were we all a bit more open and honest about our struggles, might be able to at least remind us that whatever thing we’re stuck doing, it can’t be that bad. This is all aggravated by the absurd NDAs and fear of blackballing that all of us have in this sector.
External reminders of happiness and progress are, as mentioned in the preceding section, also sources of burnout. They themselves aren’t what does it, but if you’re already feeling hopeless and spread thin and worried about your progress seeing constant messaging about how the lifestyle is successful (for everybody but you), how hard work is the way to a massive exit (for everybody but you), and how much everybody (but you) is enjoying things and killing it does nothing but make your struggle seem more pointless and your own inadequacy larger.
Of course, there is no end to this messaging. Even setting aside the massive industry of entrepreneurship porn—which is all around us if you’re doing startup or software work—the simple fact is that the culture of our sector is not about helping others for their own sake nor about introspecting on projects and learning how to responsibly manage them. The mythos of our industry is rooted in the lone engineer or small team heroically fighting all odds to deliver a project seemingly through sheer force of will alone, and we judge ourselves and expect to be judged according to the same metric.
So, when I’m going through burnout I see people succeeding and not helping, and I expect to be treated like a pariah. And at some level, we all know that that is what will become of us if we stay in that way for too long; and that threat reinforces the fears of losing our support networks and our safe spaces.
Recovering from burnout
In my experience, recovering from burnout requires getting as far away from the work as is feasible and reestablishing perspective. Burnout takes as while to set in, and getting out of it takes a time as well. In one case it took three months before I could open an editor without slamming it shut, cursing the very idea of writing code.
Reestablishing perspective often means hitting those things we talked about each by each and fixing them or trying to do the exact opposite. To kind of recap some of them in a convenient bullet form. For the work stuff:
- Work on projects that can be picked up and put down with no sense of urgency. If you feel like you’re “forcing” the project, or just slipping into flow and letting it cut into your time, step away from it and come back later. Reassert that you have a life outside the project.
- Learn something new or go do some completely exploratory/fun work, preferably completely unrelated to the source of burnout. Maybe that’s a raytracer, maybe that’s writing stories about bunny rabbits, maybe that’s fishing.
- Work on something that immediately rewards your effort, like building a workbench or baking some cookies or cleaning your home. Do literally anything that shows a clear and irreversible state change due to your own actions. Find a reminder that progress is something that actually exists.
- Do something with a clear end date, and walk away. Say “I will try a hackathon” or “I will build a model this afternoon” or “I will write a poem” and then walk away or burn it once the time is up. Forcibly close it out.
For the environment stuff:
- Find a happy place or make one, and spend time there without your burnout project. Find a park and enjoy an afternoon, move all your work crap into your home office and organize the rest of the house, go out to a rave—just do anything to find a place that hasn’t been psychically tainted by your burnout or project.
- Work on your health issues. If you’re depressed or anxious, find a good therapist—hell, do that anyways. If your body isn’t doing what you want it to do, start working with it. If you’ve been putting off a surgical procedure, get it taken care of.
- Find a hobby and people disjoint from your work (and from tech sector). Go to church, go dancing, go to meetups for basket weaving or art, go on dates. Have movie nights with friends, get in arguments with people online, do whatever it takes to block out headspace that work and burnout is not allowed to seep into anymore.
- Stop paying attention to people in the tech sector. Stop following Hacker News and TechCrunch and ProductWatch and all of that other bullshit. Stop going to meetups where startup hopefuls lie to each other. Talk to people that can offer perspectives and offer sympathy without needing to worry about causing future career issues for yourself.
Those are just some ideas and things that’ve worked for me. If you find success some other way, do that instead. More importantly, talk to other people about what they’re going through on projects, and try to spot if they’re in a similar position and try to help.