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 . The following list of some symptoms are consistently cited in How Not to Burnout: Guide for Software Developers [2]: consequences of burnout are severe for the individual developer, the team, and the company “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: Category Example Lack of focus (A) Too many varying tasks. The developer e.g. works on the development of many new features but just a few will be completed. Or the developer constantly switches between maintenance/bug fixing and feature development often without finishing previous tasks. High workload and/or unbalanced distribution of tasks (B) High workload for some top developers, as only they have the skill to handle complex parts of the software. A single developer has to coordinate the work of many (new) developers. Unrealistic deadlines coupled with notorious understaffing. Significant share of “non-value” work (C) A high share of maintenance work and a low share of the development of new features/innovations becomes frustrating in the long run. Bad collaboration within and between development teams (D) Lack of onboarding/training of new colleagues. Experienced developers who do not delegate or share their knowledge. Lack of communication about work progress and best practices within the team or between teams. Table 1: Work condition categories and their influence on burnout of software developers Of course, it also depends on very individual circumstances whether the employee suffers from burnout. But since it is a very serious and long-lasting disease, it is even more important to measure the known causes and their impact on the individual developer as early as possible and to implement prevention concepts. In the following sections, we show that many causes of burnout can be extracted by investigating the work on the software code. 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 [6] and [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. Software Due Diligence – Developers and their Cooperation in Focus The Diffusion of Responsibility Phenomenon Analyzed: Unravel the Truth Conclusion: Developing software is challenging and the risk of burnout is real Developing software is an intellectually challenging process for many brilliant minds. 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. Software companies are, therefore, “people” companies. The risk of burnout is real and present 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, . Each indicator gives specific hints of where the stress could come from. This allows project managers to . 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. project leaders can gain insight about the work-induced stress level within their team reach out to that employee and discuss individual countermeasures Links [0] Photo by Nataliya Vaitkevich from Pexels [1] Burnout Prevention for Software Developers [2] How Not to Burnout: Guide for Software Developers [3] Beware Burnout [4] 7 Reasons why programmers burn out [5] Only You Can Prevent Tech Burnout [6] Software Due Diligence – Developers and their Cooperation in Focus [7] The Diffusion of Responsibility Phenomenon Analyzed: Unravel the Truth Also published at: https://capeofgoodcode.com/2021/09/10/burnout-syndrome-why-it-hits-software-developers-so-often/

Timely

The Diffusion of Responsibility Phenomenon Analyzed: Unravel the Truth

Try out DETANGLE®

Why Burnout Syndrome Is More Common Among Software Developers

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

The Diffusion of Responsibility Phenomenon Analyzed: Unravel the Truth

10 Great Articles On Data Science And Programming!

10 FinTech Trends in 2021 [Part II]

10 Financial Predictions for 2021 to Protect Your Wealth

13 API Metrics That Every Platform Team Should be Tracking

The Diffusion of Responsibility Phenomenon Analyzed: Unravel the Truth

10 Great Articles On Data Science And Programming!

10 FinTech Trends in 2021 [Part II]

10 Financial Predictions for 2021 to Protect Your Wealth

13 API Metrics That Every Platform Team Should be Tracking

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps