Architecture & DesignBurnout and the Developer

Burnout and the Developer content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.

Burnout generally starts with debugging. It’s the defect that you can’t seem to find. The trudging through logs and poring through databases is seemingly endless. Slogging through thousands of lines of code to find that one wrong thing can feel like it will never end. That’s when burnout starts to take make its stranglehold.

Burnout has been a part of the software development industry since the very beginning, with high-performing developers burning out in a blaze of glory. However, it doesn’t have to continue to be this way. We can continue to enjoy our work if we can figure out what burnout is and how it grabs us.

Defining Burnout

The first step is identifying what burnout even is. While definitions vary, the consensus is that burnout is characterized by exhaustion, cynicism, and inefficacy. That’s a great for identification, but it’s nearly useless for learning how to prevent burnout or recover from it. The key characteristic is inefficacy and its effect on your beliefs.

Inefficacy makes us feel as if we don’t have any control, and that is the heart of decades-old research by Martin Seligman and his colleagues. They defined it as learned helplessness at the time. More recently, his former colleague, Steve Maier, discovered that it wasn’t learned helplessness at all—it was learned control that allowed the brain to be adaptive about finding a solution that made the difference. Our belief about our ability to control our environment—our efficacy—allows us to be productive.

We’ve all felt like we’re unable to find a bug that’s been plaguing us or been faced with a technical problem that we don’t know how to solve. It also happens when we’re trying to get our code to work and realize the build was fundamentally broken by other developers, so it feels like we’re spending all our time debugging other developers’ code. The feeling that we’re not getting our work done can be frustrating.

Efficacy Expectations

Most developers get a feel for how long things are going to take. Even the most optimistic developer has a sense for the effort. They may estimate it low, but they know their estimates are typically low. If the estimate and the actual effort are relatively close—after scaling—we feel like we’re getting things done. However, if our expectations and our actual productivity differ for too long, we’ll begin to lose sense of our efficacy.

Whether the estimate was wrong, there were unforeseen circumstances, or some mixture of the two, we’ll feel this as an inability to get things done, and that increases our risk of burnout.

Perception of Results

Our perception of inefficacy isn’t always about the expectations of our efficacy. Sometimes it’s that we’re not perceiving our results in a way that’s consistent with our actual performance. We run late on checking in the feature we signed up for—but we do so because we created a reusable framework that pulls three times as much work off the backlog. We only count the feature we checked in—because, after all, that’s the work we did. We don’t count the additional value of the elegant and reusable solution we found to the project.

If we fail to recognize the unique and special value of what we’re doing and instead minimize or forget we even did it, our actual results and our perceived results are out of alignment.

When this occurs for too long, we feel like we’re not effective at doing our part to pull the project forward. We feel like we’re not as effective as we should be.

Mind the Gap

In the end, burnout is the gap between our expectations of our effectiveness and our perceived results. It’s the place that we crawl into when we feel like we’re not good enough, we’re not doing enough, or others are getting results that are better than ours. If we have lowered expectations and lowered perceived results, we’ll be fine—it’s only the mismatch that challenges our feelings of efficacy.

While we should seek a reasonable expectation for our efficacy and a reasonable recognition of our results that are grounded in reality, it’s even more important that the expectations and perceived results are in alignment. We can have an inflated sense of power as long as we have an inflated sense of our results.

Converting Efficacy to Agency

Our efficacy isn’t the whole story. Efficacy is a backwards-looking measure. It’s what we have done in the past, though we live in the present. The result is that we must move from what we have done to what we can do today and in the future, and that is our personal agency.

You can think of personal agency as a bathtub. The results we accomplish, the support we receive, and the self-care we do all fill our bathtub up. The demands that are placed on us drain our personal agency. When our personal agency bathtub is empty, we’re in burnout.

The key to looking at burnout in this way is that we have the capacity to change all of these. We can focus on high-value activities that drive more impactful results. We can ask for the support we need—and, by and large, we’re likely to get it. We can choose to do self-care or not.

Although it may seem like we have little impact on the demands placed on us, we have a surprisingly high degree of control. We may not be able to tell our manager no, we won’t do what they want, but we can negotiate on the deadline and what will be impacted by high-priority projects. By negotiating on the deadline and the impacts to other deliverables, our demands can become manageable.

If you want to learn more about burnout and how it works, you can find out more in the book I coauthored with my wife, Extinguish Burnout: A Practical Guide to Prevention and Recovery.

# # #

This article was contributed. © All Rights Reserved

Get the Free Newsletter!

Subscribe to Developer Insider for top news, trends & analysis

Latest Posts

Related Stories