Read

arrow pointing down

How did COVID impact software engineers? Programmer's burnout

The workload of programmers increased during the pandemic, which contributed to their feeling of burnout. What does the latest research say about it?

As the COVID-19 pandemic took over our everyday lives we have turned to technology and made it a major part of our daily routine. So, developers took on an even more important role than before. In those changed circumstances, they provided people with connectivity and continuity of work. However, the workload of this occupational group inevitably increased, and they were doomed to suffer from burnout.

If you've enjoyed programming but now feel the passion is going away, you may be starting to burn out 

Creating programming code is one of the most exciting elements of programmers' work. It’s often a passion, and it’s a dream come true when that passion becomes one’s work. However, after several years of spending long hours on it and being overloaded with many simultaneous tasks, it can result in a severe lack of motivation. During the pandemic, developers felt it more than ever. 

Burnout is a physical and mental breakdown caused by overwork or stress.

Some burnout symptoms, causes, and solutions are common to everyone in each industry. However, the reasons may be different among IT specialists, as they simply had more work during the pandemic. How do we know that?

A study on programmers' well-being during the pandemic

In July this year, Haystack released the results of a study examining the well-being of software engineers during the COVID-19 pandemic and how technology teams evolved over time. 

At an extraordinary pace – from 23 to 24 June 2021, the fieldwork was carried out by the research agency Survation. They used top-notch methods to collect accurate data on the work of software engineers.

The study results provide insight into their experience of burnout, reliability, and the development process. The sample of the population included 258 software engineers aged 18+ from the United Kingdom. They were asked about experiences mainly related to burnout. The results turned out to be much worse than expected. 

1. Feeling of burnout – in general and due to Covid

A total of 83% of software engineers reported they feel burnt out; and only 17% reporting no such feeling. 55%, a majority, reported “great” or “moderate” levels of burnout. 

At the same time, 81% of software engineers reported feeling more burnt out of work due to the pandemic. 32% said this was true to a “great” extent and 30% to a “moderate” extent.

Survey on burnout of programmers during the pandemic: 83% reported feeling burnt out and 81% admitted that they feel burnt out because of Covid pandemic.

2. Reasons of burnout – in general and due to Covid

The main reason indicated by responders was increased workload. It was reported as a cause of burnout by 40% of them and was ranked higher than any other factors for experiencing burnout. The respondents were asked about the seasons of their feeling burnt out – in general and because of the pandemic. We present the answers below.

Survey on burnout of programmers during the pandemic: 83% of developers suffer from burnout in the workplace. The main reasons are: high workload (47%), personal life (36%) and inefficient processes (31%).
Survey on burnout of programmers during the pandemic: 81% of developers suffer from burnout due to Covid. The main reasons are: high workload (40%), general anxiety caused by COVID-19 (39%) and uncertainty of the future (37%).

It shows that workload is the leading cause of burnout among developers, wherein the factor has worsened more than any other during the pandemic.

To sum up, as many as 83% of developers suffer from burnout in the workplace. The main non-personal reasons for that are: high workload (47%), inefficient processes (31%) and unclear goals (29%). And 81% of them reported that the feeling increased as the result of the Covid pandemic, still indicating workload as the main cause.

Yet in some organisations, managers believe that more hours mean more productivity. As it turns out, this is not true. In research published in Harvard Business Review, managers could not distinguish between the real work done by employees who work 50 hours a week from when they did 80 hours a week.

3. Software reliability and process efficiency

The survey also shows that, in total, 83% of software engineers are concerned about software reliability at their workplace, out of which 20% are concerned to “a great extent” and 37% to “a moderate extent”. Now, if we take a look at a previous question, 20% said they experienced burnout due to “unreliable software”.

In addition, 55% of them stated that they were frequently delayed in delivering work due to an inefficient process to a “great” or “moderate” extent. Again, that was one of the reasons for burnout indicated by 31% of responders in the previous question. 

4. Cycle time 

The study used “cycle time” as a critical measure to understand the engineering team's productivity. Cycle time measures how quickly an engineering team can implement production ideas to gain user feedback.

The question was as follows: “Thinking about your workplace, on average, how long does it take for you to begin working on a feature and reliably deploy it into production?” Software engineers report the cycle times as listed below: 

  • 9% – less than 1 day; 
  • 50% – 1–3 days; 
  • 35% – 4 days to one month;
  • 4% – exceeds a month.

The results reveal that, with shorter cycle times, teams are better at dividing up and prioritising work while achieving reliability.

How to optimise your workflow 

This study concludes that technology teams that are more workflow-oriented (focusing on reducing cycle times to deliver business value to production) are less likely to perform poorly on developer’s health. By optimising the flows, not the amount of work delivered, they prevent them from burnout. So the big question is – how to do that?

In large projects, you should always follow an iterative development process. You should develop a few modules, compile and test them, then try to run it. Then, develop more modules. Defer from coding an entire program without compiling or debugging modules. 

Other possible aspects of developers’ burnout: 

1. Physical health 

Programming requires you to be in front of the screen and seated (often in an unhealthy position) for long periods at a time. And many tasks and responsibilities simultaneously force programmers to work long hours, which significantly affects their physical health. It is one of the most common causes of burnout. 

2. Mental fatigue 

Programming is very cognitively intensive, requires a high level of focus, and can be very stressful. A developer's brain has to work extremely hard to solve complex problems.

Sometimes their mind is pushed to its limit for many hours each day without interruption. When something like this happens continuously for weeks, mental fatigue can take its toll.

3. Monotony of work 

Even if a programmer's work is mentally stimulating, doing the same type of job every day is dull and can reduce one’s effectiveness.

When a programmer has to write similar types of code or use the same technology every day, their motivation and passion for programming slowly runs out. 

4. Chasing deadlines 

You may be chasing deadline after deadline. Perhaps you will miss a few others along the way. You are expected or expect from yourself to generate the highest quality and deliver the job for yesterday.

But, such a pace of work is not good for your health in the long run – you may start feeling burnt out. As a result, when you think about work, you don't feel joy or fulfilment. Pressure can drain all your passion for coding.

5. Poor programming culture 

In many cases, developer burnout is caused by a poor programming culture or some form of unsuitable project management. Your coworkers may have a different approach to process flow or code quality standards. And misunderstandings resulting from these differences can worsen work relationships.

It is important to quickly clarify any otherness in work styles so that an unhealthy situation does not burn out someone. However, it is generally not the fault of a single worker. 

6. Unclear tasks 

Sometimes, instead of coding, a programmer is dealing with managerial responsibilities, customer relations, etc. Or it may be that they are working on a project that seems beyond their skills, and a manager has overestimated their abilities. Sometimes they have been working on a project for several months and get lost in their goals.

It is usually due to mismanagement which can have many reasons, e.g. a deadline is too short, there are insufficient resources to meet it. Therefore, it is always worth communicating your needs clearly, setting your limits, and any additional resources, workforce, and money needed to achieve the goal.

Software programmers' burnout – how to fix it? 

The best is to try acquiring some new skills. First of all, you can try using a different language/stack and work with other databases or tools. A good idea is also to change your coding environment. If you are from Windows, move to Mac or Linux. Use a different text editor.

Learning new things will help regain your passion and decrease burnout feeling

Whatever you choose to do, each change or side project will give you a sense of fulfilment that you may be lacking. So go ahead and organise an activity on the side, preferably one that doesn't involve sitting in front of a computer. It can be sports, music, cooking or interior design. Find something that interests you and do it regularly.

Hobbies have a vast positive impact on our mental health so that a crisis at work does not turn into a life crisis. You can read more about our methods to avoid burnout at WEBSENSA.

Commitment and burnout 

Gallup has published an interesting report on what it calls the Wellbeing-Engagement Paradox of 2020

Usually, when employees are engaged, burnout goes down, and productivity and well-being go up. However, during the pandemic, well-being and commitment diverged and went in opposite directions. 

Commitment and productivity are never sustainable without mental well-being

Some expected employee engagement to decline as a result of tensions and uncertainties over Covid-19. In fact, the opposite happened. At least temporarily, engagement increased, hitting a new high of 40% (and 41% for remote workers) in June and July.

However, this spike in commitment was short-lived because it was built on fear and anxiety, not prosperity. Employees were happy that they had a job and did not want to lose it, and leaders did not want their companies to collapse.

Fear can motivate people to act, however, as proven, it’s not a long-term solution, and it's a stress factor that can push people to burnout.

Summary 

IT business leaders must learn to look out for “red flags” of developer burnout, especially during the pandemic.

For example, are those who work long hours motivated by fear and worry? If they are still working from home, do they need support related to any personal or mental health issues affecting their efficiency? Is economic anxiety preventing them from taking the necessary free time?

These are the questions they need to ask themselves to keep their developers healthy, content and thus – effective.

You may also like

IT project management methods – traditional, called cascade

Project management methods in IT are divided into traditional (cascade) and modern (agile). Read about traditional methods such as Waterfall or PRINCE2.

Web Content Accessibility Guidelines – digital products following WCAG

What is Web Accesibility? What guidelines are included in WCAG? How can we make internet use easier for people with disabilities? Read in the article.