Are you develop your own burnout?

Image: “The nightmare of the JavaScript programmer.” Author: Victor Sirotin

Recently, a good friend, psychiatrist, came to visit me. In conversation, he mentioned that more and more software developers with the diagnosis of burnout have recently applied to him. My friend admitted that he does not know the essence of the programmer’s work, but it seems to him that there are not more stress factors in it than in many others professions.
“How is your profession different from the others, which so often leads programmers to burnout?” asked he.

Terrible data about burnout in Germany

After our conversation, I rummaged a bit on the Internet, but did not find statistical confirmation of my friend’s empirical assumption that programmers have the burnout more likely than other professionals. However, I found several terrible facts about the extent of the burnout in Germany.
According to data published by one of the largest German insurance companies, 22 percent of working Germans were unable to withstand the stress at work and outside it and asked to specialists for help. And in the age range of 40-59 years, there were as many as 30 percent (https://www.tk.de/centaurus/servlet/contentblob/921466/Datei/3654/TK-Stressstudie_2016_PDF_barrierefrei.pdf)
But this is a stressful state, not a burnout. As the disease the burnout begins with emotional exhaustion and a feeling of fatigue, a decrease in job satisfaction, disappointment and apathy. Experts know up to 130 symptoms, which appear in later stages (depression, insomnia, etc.). If the disease is not cured, it leads even to suicide.
According to official data, 4.2% of Germans are iled with this disease or have had it in previous years (https://de.m.wikipedia.org/wiki/Burn-out#cite_note-5)

What factors cause stress by programmers?

I am very far from psychiatry, but I have been engaged in programming and architecture of software systems for more than 40 years. Several of my colleagues had a burnout. Therefore, I was interested in the question, what specific professional factors can provoke burnout by programmers?
Here is the course of my reasoning.

How do programmers sleep?

Our life is divided into sleep and wakefulness. Let’s start with sleep.
There are many professions where people work shifts at different times of the day, with shifts of different lengths or sleep in constant readiness mode (on-call, German term – Bereitschaft). The profession of system administrators belongs to such category. Programmers of the new type (DevOps) are affected more than the “classical” programmers. And the latter can also experience short periods of sleep in on-call mode during launching a new version of the system.
But in general, the profession of a programmer does not carry the risk of disordered or incomplete sleep. So, a dream is not a risk factor.

Uncommunicative programmers

Time of our wakefulness is divided into working and non-working. We will deal first with non-working time – evenings after work and days off.
This time people spend in a circle of close people either alone, dedicating it to their hobbies, consuming information from the Internet, books, television, as well as sports, walks, etc.
In my estimation, programmers are less sociable people than representatives of other professions. This is clearly visible at conferences, where there are programmers and managers, as well as at IT exhibitions. Representatives of these two groups are just as immiscible as oil with water. During pauses between sessions and at evening events managers establish contacts, renew old ones, flirt or just enjoy life. Programmers immediately and until the end of the event get off into small groups and discuss their professional problems.
I think you will agree with me in this observation. And you will agree that poor communication can not lead directly to burnout.
So, in search of risk factors, we discard it too. Let’s consider now working time.

Working time

I believe we can assume that the work-related risk factors can be divided into two groups – related to colleagues and related to “working material”.

Colleagues as a risk factor

It is clear that in соме developers team can arise all the stress factors that arise in other teams – mobbing, isolation, underestimation, etc., . But in the programmatic collectives there are no special aspects inherent in teams with a statutory hierarchy (military type), staying together for a long time in a limited space (ship crews, drillers team, etc.). In these aspects, the work of programmers does not differ much from other “normal” professions. We also reject this aspect.

Problem with the material

So, there is “material”. For surgeon it is the human body, for teacher it is pupils, for locksmith it is metal and for programmer it is source code.
In relation to the material, I would like to highlight the following aspects:

  • Irreversibility of an error
  • The mistake will inevitably manifest itself
  • Hight concentration during the whole working day
  • Short time up to beginning of “requital”

So, consider these aspects successively.

Irreversibility of an error

Because of its own weak concentration or for reasons beyond his control, the locksmith can irreversibly “screw up” a piece of expensive material. Even more tragic may be the errors of surgeons.

The programmers do not have this problem. He or she can rewrite the wrong lines of code, and the world is again in order.

This aspect is also discarded.

The mistake will inevitably manifest itself

In some professions, mistakes are eliminated themself. The patient’s healthy body can find the strength to recover despite improperly prescribed medications. A student of some bad teacher can learn the material himself or parents can hire him a tutor.
In programming, this does happen almost never.
In most cases, sooner or later, the moment will come when the error manifests itself. Of course, it’s better sooner than later.
So, we found the first risk factor, which is specific to the profession of the programmer and is rarely found in many other professions.

Hight concentration during the whole working day

In some professions, it can even reasonably wait until “the problem is resolved by itself.” Any bureaucrat knows this. And there, where tasks or areas of responsibility are not clearly defined, the employee can simply wait and the work will be performed by someone else.
In modern programming teams, the performance of individual programmers will be very quickly transparent to others team members. Modern tools such as Jira and Git “mercilessly” help the team and managers in this matter.
Any programmer knows that the necessary solution “come in” in a state of high concentration and creative mood. But if there is no creative state, you can torment yourself all day, but the result will not be achieved.
So, in order to produce results, programmers should be the whole working day in high concentration and creative mood sufficient to solve constantly new tasks.

We enter this risk factor in our list.

Short time up to beginning of “requital”

According to this indicator, the profession of a programmer is quite unique and comparable with professional sports. If a football player wrong kicks the ball, he (and also the fans, teammates and opponents) will find out about this in a second.
Modern IDE show the syntax error immediately. When you cover your code with tests, the tests will indicate to you an algorithmic error in a couple of minutes, by the next test run. Unlike a football player, for his “blunder” the programmer will not be booed by spectators. But do not forget that the football player play a hour and a half a week and hits the ball not so many times per game. By programmer it continues a whool working day.

The true story from the 70’s

When I first started my professional activity at the Computing Center of the Siberian Branch of the Academy of Sciences of Russia in Nowosibirsk, the computing resources were shared there between the departments “in the time-sharing” mode. It looked like this. Each department was allocated some time (for example – half an hour) on one of the mainframes. We prepared our tasks in the form of decks of punch cards. When our time window came up, the lab assistant took the first pack from our stack and put it into the card reader. The computer processed it and signaled a light bulb. The printer printed the result on the paper tape. The laboratory assistant took the next deck … and so it was until the time window was over.
When the time window was finished, the current task could be forcibly stopped, and the corresponding deck, like the untreated one, was placed first in the department’s queue of queues for the next window.

The subtlety was that if the decks of the previous department were processed quickly, the packs of our department could go into processing earlier and … longer. This happened very rarely, but once we noticed that we are systematically “lucky”.
It turned out that the department, which was planned to be queued before us, had a lot of computer time planned for development of an interpreter from a language that was remotely similar to a subset of Fortran. (Now it would be called a DSL – Domain Specific Language). The interpreter was developed by one talented developer who argued with his colleagues that he would write the program in such a way that it would work on the first launch. The managers who planned resources did not know about this bet and gave him time windows for several months ahead. Than we involuntarily used.
This talented person wrote, prepared punch cards, checked (we were all then able to read and understand the “hole” language of punched cards) many thousands of lines of code without a single launch. But … he lost the bet. Several errors on the first run were found. And only the second launch, after eliminating the errors, brought the desired result.
For modern programmers, pampered by an abundance of computer resources and fantastic IDE, this is for sure hard to imagine. I program in an incremental way and run the tests after writing a few dozen lines of code. I believe it’s generally more effective than thinking all day, stuffing the code and only running it on the computer once a day. But the advantages of the modern method are not absolute. The ability to quickly check the code disaccustoms us to think deeply.
But back to our aspect. In my opinion, the average short time to beginning of “requital” for their mistake is one of the highest by software developers among all professions. And this can be one of the main professional risk factors for stress.

Let’s sum up the results

So let’s formulate the main specific stress factors for programmers:
Most of their time, programmers spend in the fight against their own mistakes. The newly written code constantly “upsets” them with the presence of errors.
Programmers know that almost any of their errors will sooner or later manifest themselves. The expectation of these manifestations oppresses them.
Programmers are forced to work constantly in the exhaustive mode of high creative impact and psychological concentration.

How to avoid stress?

As I have already noted, I am far from psychology. I do not try to take bread from my friend, his colleagues, authors of numerous books and films on this topic. And still, I’ll risk giving a few simple tips.

  1. Sick heroes do not need anyone. Remember that to achieve the result you need a good physical fitness and a creative mode. If they do not exist, there is no result. You have been unwell all day and the code is written poorly. Do not suffer in the evening about this. Do not try to finish the coding at evening. Better drink tea with honey and go to bed early.
  2. The right mix. Programming can be compared to jumps. Only the jumper in the beginning runs up faster and then jumps, but the programmer has a brainwave and then he completes the necessary routine operations. It is impossible to jump very highly nonstop eight hours. Mix creative flight and routine.
  3. Be able to relax during the working day. Project managers, especially in large projects, tend to overdo with meetings that are not useful for programmers. If you can not avoid them, do not be angry at the lost time and chatty participants in the meeting. Think about something of your own, letting to flow the meeting’s information throught the secondary path of consciousness. Learn to take a thoughtful and interested expressionon on your face 🙂
  4. Plan for everyday success. Break the tasks on parts, about which you can expect that you will be able to complete them in an hour or two. In extreme cases,plan your tasks for the day so that there remains a hope that something “rounded off” before the end of the working day.
  5. Finish the working day with a victory! If you successfully solved some real hard problem in half an hour or an hour before the end of the day, do not start a new one. Most likely, the “batteries” in your head are already “empty”. Can you have a couple of organizational tasks such as a business trip report?
    And when you in 5 minutes have to go out to catch the train, turn off the computer and do not try to write a line of code. The new lines of code probably bring nothing. But because of the skipping of the train you will be angry with yourself. And most importantly – if you stay at work for two or more hours, the decision probably will not come. But on the way home it can very well come. I checked it on myself many times.

I will repeat once more. This text does not pretend to the scientific depth and thoroughness in the selection of materials and arguments. It’s just the author’s reasoning on an interesting topic. Your opinion would also be very interesting to know.

The Russian version of this article can be found here.