Why Burnout Syndrome Is More Common Among Software Developers

@capeofgoodcodeCape of Good Code

Everything you wanted to know about your code but were afraid to ask: software quality analysis with DETANGLE®.

Summary: Why is burnout so common?

Burnout symptoms are often a result of suboptimal procedures and working conditions. They are signs of a serious and protracted illness.
Especially, burnout of software developers is more widespread than one might suspect. It hits companies via increased employee turnover, reduced team productivity, and above-average sick leave just as hard as the affected employees.
Amongst many other reasons, “meaningless” work, frequently changing priorities, unrealistic goals, deadlines, and overwork are disproportionately often named as causes.
Early indicators for these most important burnout causes can be identified from the work on the software code with the DETANGLE Analysis Suite.
With these analysis results, project leaders/-management have information at hand to identify health-threatening working conditions of their developers at an early stage and can initiate countermeasures timely.
By regularly applying these analyses, additional information regarding the trend of the relevant key metrics will become available. Over time it becomes increasingly easy to narrow down the causes of a developer’s burnout and to avoid it before the individual and as a consequence, the organisation is seriously impacted.

Why are software developers so often exposed to burnout symptoms?

Burnout is a serious and protracted illness. There is still no clear definition and diagnosis for it. Often, it is confused with depression.

A helpful description can be found, for example, at Burnout Prevention for Software Developers [1]:

Burnout is one of those things you don’t notice until you already have it. But people with symptoms of burnout are people who are generally always working, always on – they feel like they can never take a break or have downtime.
– Abby Kearns, Cloud Foundry

The consequences of burnout are severe for the individual developer, the team, and the company. The following list of some symptoms are consistently cited in How Not to Burnout: Guide for Software Developers [2]:

“Becoming cynical or overly critical at work”
“Lack of energy and concentration with no evident cause”
“Constant fatigue”
“Procrastinating on tasks that you used to do enthusiastically”
“Feelings of dread, apathy, and being out of control”
“Lowered productivity”
“Minor to major anxiety”
“Outbursts of anger”

One could argue that burnout happens in every profession. But software engineering is particularly predestined for it. And there is a reason for that.

Software engineering has no limits. Work is not defined by a set number of hours per day, but by optimistic and sometimes arbitrary management deadlines. As one senior tech CEO told me, “I knew there was no chance of meeting my deadline, but I just wanted to get the engineering team to work faster.” In addition, understaffing of project teams is common because recruiting developers is difficult – and expensive. [3]

The publication Beware Burnout [3] lists the following software development-specific reasons for an increased probability to get burnout:

“Unclear or rapidly changing direction” (A),
“Bus factor is low” (B),
“Programming is isolating” (D),
“Draining work of maintenance” (C),
“Impatient or ungrateful users” (in the case of open source development)
“Coding for others”

Other publications such as 7 Reasons why programmers burn out [4] and Only You Can Prevent Tech Burnout [5] list quite similar and further reasons. The various reasons the different authors find causal for increased susceptibility for burnout can be consolidated into four clusters:

Early indicators of burnout are measurable

The first step in burnout prevention is to identify indicators that are known or reasonably suspected to be associated with an increased susceptibility for burnout as shown in table 1. For the category clusters A, B, and C, we record the following parameters per developer over time with DETANGLE®:

What is the developer’s share of the workload of system maintenance vs. feature development?
How many features/user stories does a developer work on simultaneously and what is their effort distribution?
How many different source code directories is the developer working on simultaneously?
How many different programming languages is the developer working with?
Does a developer pose a project risk over a longer period of time due to his relevant and special knowledge, and is she/he aware of it (bus factor)?

The analysis of these data gives clear insights about working circumstances that are known to cause an over-proportional amount of employees burdened with burnout syndrome. For example, the higher the individual’s maintenance effort, the lower the proportion of real value-adding work that usually is seen as a satisfying activity (C). The higher the number of features/user stories and the higher the number of source code directories or programming languages, the lower the developer’s focus (A), whereas the Bus Factor also indirectly reflects his workload (B).

Figure 1 shows the Bus Factor, i.e. the number of key developers for the Django open-source project. It can be seen that their number has increased from 4 to 7 developers from 2019 to 2020, and about 12% of the developers are considered mission-critical and contribute to the Bus Factor. The loss of one of these developers is always a project risk. Since these key developers also usually have the highest workload and responsibility, they are particularly at risk for burnout. Thus, the Bus Factor is also an early indicator of the number of employees at risk for burnout. If a developer is recorded as a Bus Factor for a longer time, project management should try to rebalance his load and reduce his/her high level of continuous high importance for the project(s).

We have already addressed the causes of category D from the previous section (problem of poor cooperation) in several blogs. Under Software Due Diligence – Developers and their Cooperation in Focus [6] and The Diffusion of Responsibility Phenomenon Analyzed: Unravel the Truth [7] we have explained that it is not the star soloists, but the team players that matter in order to limit the stress level in the team while still improving productivity and quality.

Conclusion: Developing software is challenging and the risk of burnout is real

Developing software is an intellectually challenging process for many brilliant minds. Software companies are, therefore, “people” companies. The risk of burnout is real and present given the challenges and pressure in software development projects. We strongly recommend identifying burnout indicators early on or even better continuously to minimize the risk of employees dropping out for months due to overwork or dissatisfaction.

Cape of Good Code has developed an analytical, software-based approach to identify indicators that describe the risk of burnout of an individual caused by working circumstances in software engineering.

By using DETANGLE® regularly, project leaders can gain insight about the work-induced stress level within their team. Each indicator gives specific hints of where the stress could come from. This allows project managers to reach out to that employee and discuss individual countermeasures. By speaking with the employee one can definitively clarify how stressful he/she perceives the work circumstances and whether he/she can further handle that stress level.