Don't you program yourself a burnout?

Are programmers subject to emotional burnout more than representatives of other professions? If so, what are the risk factors and how to deal with them?

This text does not pretend to the scientific depth and thoroughness in the selection of materials and arguments. This is just the author's arguments on an interesting topic for him.
This article is a translation of a post in my English-language blog.

Recently, a good friend of mine visited me. By profession he is a psychiatrist. In a conversation, he mentioned that more and more programmers were being approached recently with a diagnosis of burnout (emotional burnout). My friend admitted that he understands the essence of the programmer’s work a little, but it seems to him that there are no more stressful factors in it than in many others.
“How does your profession differ from others, what so often leads programmers to burnout?” He asked.
')
After our conversation, I rummaged around a bit on the Internet, but did not find statistical support for the empirical assumption of my friend that programmers are more likely to suffer from burnout. However, I found some chilling facts about the extent of the incidence of burnout in Germany. Details you will find in the original post .

Where does the stress from programmers come from?

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

How do programmers sleep?

Our life is divided into sleep and wakefulness. Let's start with a dream.
There are many professions where people work in shifts at different times of the day, with shifts of different lengths, or sleep in constant readiness mode (the English term on-call and German - Bereitschaft). These professions include the profession of system administrators, which is close to us. The programmers of the new variety (the so-called DevOps) are affected more than the "classic" programmers. And the latter can also experience short-term sleep periods in the on-call mode when launching a new version of the system.

But in general, the profession of a programmer does not carry the risk of disordered or inadequate sleep. So, it's not a dream.

Uncommunicative programmers

The time of our waking is divided into working and non-working. We will understand first, with non-working hours - in the evenings after work and days off.

This time people spend in a circle of close people or alone, devoting him to their hobbies, to consuming information from the Internet, books, television, as well as sports, walking, etc.
In my estimation, programmers are less sociable people than representatives of other professions. This is clearly visible at least at conferences where there are programmers and managers, as well as at computer shows. Representatives of these two groups are as immiscible as oil with water. In between meetings and at evening events, managers actively make new contacts, renew old ones, flirt, or simply enjoy life. Programmers immediately and until the end of the event get together in small groups and either collectively keep silent or discuss their professional problems.

I think you will agree with me in this observation. And agree that lack of communication can hardly lead to stress and then burnout.

So, in search of risk factors, we discard free time too. We will understand now with the work.

Just like others

I think it can be assumed that the work-related risk factors can be divided into two groups - those associated with colleagues and those associated with “work material”.

The problem is not in the team

It is clear that in a programmer team all stress factors arising in labor collectives can arise - mobbing, isolation, underestimation, domination of chef's favorites, etc. But in programmer teams there are no special aspects inherent in teams with a statutory hierarchy (such as the military) staying long together in a limited space (crews of ships, watchmen, drillers, etc.). Similarly, in these aspects, the work of programmers does not differ much from other "normal" professions. We also reject this aspect.

The problem is in the material

So, the "material" remains. This implies that which a particular professional deals with in his work. The surgeon has a human body, the teacher has the students, the locksmith has the metal, the programmers have the program code.

In relation to the material, I would like to highlight the following aspects:

• Irreversible error
• The inevitability of error
• The impossibility of "net" work.
• The speed of the onset of "retribution".

So consider these aspects in order.

Irreversible error

Due to his own weak concentration or for reasons beyond his control, a fitter may irreversibly “screw up” a part made of expensive material and in which a lot of manpower and resources were invested in the previous processing phases. Even more tragic may be the mistakes of the surgeons. Programmers do not have this - rewrote the wrong lines of code, and the world is fine again. This aspect is discarded.

The inevitability of error

In some professions, mistakes are eliminated “by themselves”. Rather, without the participation of the erroneous. The patient's body may find the strength to recover in spite of improperly prescribed medications. A student of a bad teacher can independently learn the material or parents can hire him a tutor.

In programming, this is almost never the case. The exceptions are cases when a colleague notices an error and corrects it in between cases, or external conditions change in such a way that the error does not manifest itself.

In most cases, sooner or later the moment will come when the error manifests itself. Of course, better sooner than later. Programmers know this. And it constantly worries them.

So, we have found the first risk factor that is specific to the profession of a programmer and is rarely found in other professions.

Inability to "grab"

In some professions, it is even reasonable to wait until “the problem is solved by itself.” Any bureaucrat knows this. And where tasks or responsibilities are not clearly defined, it is possible to “grab” and someone else will do the work. Some management textbooks even recommend consciously using it. For example: you were sent to lead a new division. You see a lot of people, some of whom obviously have a net. You have a very urgent task to delegate, but you don’t know who. Recipe: find the most busy and productive and give it to him. A landing net can fill up a case, but this one will surely do.

In good programming teams, the performance of individual programmers involved in similar tasks, very quickly becomes transparent to others. Therefore, in the medium and long term, “squandering” negatively affects the attitude towards the employee. Modern tools like Jira and Git "ruthlessly" help the team and managers in this matter.

From a short-term perspective, it is even worse. Any programmer knows that the necessary solutions come in a state of high concentration and creative tone. If they come, the path is clear and then it remains to implement them and write the tests (and it is better to first write the tests and then implement them). But if there is no creative state, you can torture yourself all day long, but the result will not be achieved. I came across statistics that codes written and placed in the versioning system immediately after the holidays are later rewritten with a significantly higher probability than the others. You guessed it, why?

So, in order to produce results, programmers need a significant part of the working day to be in high concentration (which is necessary in some other professions) and creative attitude, sufficient to solve constantly new tasks (which is less necessary in most other professions). We put this risk factor in our list.

The speed of the onset of "payback"

According to this indicator, the profession of a programmer is quite unique and comparable to professional sports. If a football player hits the ball incorrectly, then he (as well as spectators, teammates and rivals) will find out about it in a second. Modern methods and programming tools are such that IDE indicates syntax errors instantly. And if you work correctly, cover your code with tests, then the tests will indicate to you an algorithmic error in a couple of minutes, at the next test run. Unlike a football player, a programmer will not be booed by the audience for his “blunder”. But we must not forget that a football player stands in front of the stands for an hour and a half a week and hits the ball not so many times during the game. At the programmer, this continues the full working week.

Historical retreat: A true story from the 70s

In this regard, I remembered a story. When I was just starting my professional activity at the Computing Center of the Siberian Branch of the Academy of Sciences in Akademgorodok, computing resources were shared there between 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 computers. (Then they were called the computer). We prepared our tasks in the form of decks of punched cards. When our time window approached, the technician took the first deck from our stack and inserted it into the card reader. The computer processed it and gave a signal with a light bulb. The printer printed on a paper tape the result. The lab technician took the next deck ... and this was repeated until the time window was over.

When the window ended, the current task could be forcibly stopped, and the corresponding deck, as unprocessed, was placed first in the department deck queue for the next window.

The subtlety was that if the previous department had few decks or they were processed quickly, the decks of our department could go into processing earlier. This happened very rarely, but once we noticed that we were systematically “lucky.”

It turned out that the department, which according to the plan was put in a queue in front of us, was scheduled a lot of machine time to debug some interpreter from a language that, in complexity, resembles a subset of Fortran. (Now it would be called DSL - Domain Specific Language). The interpreter was programmed by one talented developer who argued with colleagues that he would write the program in such a way that it would work the first time. The bosses, who had planned the resources, did not know about this dispute, and took away the windows for him a few months in advance. What we unwittingly enjoyed.

This talented person wrote, typed on punch cards, checked (we all then knew how to read and understand the “hole” punch card language is not worse than Russian) many thousands of lines of code without a single launch. But ... he lost the argument. A few errors on the first launch were found. And only the second launch, after eliminating errors, brought the desired result.

Modern programmers, pampered and spoiled by an abundance of computer resources and stunning IDEs, are certainly hard to imagine. I myself programmatically and run tests after writing a few dozen lines of code. I think it is generally more effective than thinking through the whole day, filling the code and running it only once a day on the computer. But the advantages of the modern method are not absolute. The ability to quickly check the code teaches to think it through deeply and versatile.

But back to our aspect. In my opinion, the average speed of the “payoff” for its mistake among programmers is one of the highest among all professions. And this may be one of the major occupational risk factors for stress.

Let's sum up

So let's formulate the main specific stress factors for programmers:

Most of their working time programmers spend in the fight against their own mistakes. Just written code constantly “grieves” them with errors.
Programmers know that almost any of their mistakes sooner or later manifest themselves. Waiting for these manifestations depresses them.

As you know, the human brain spends in a calm state 20% of the energy consumed by the whole body. When solving complex intellectual problems, its share rises to 40%. Programmers are forced to work constantly in the exhausting mode of high creative returns and psychological concentration.

So what? How to avoid stress? (Or how to start a new life in the new year)

As I have already noted, I am far from psychology. I also do not try to take away the bread from my friend, his colleagues, the authors of numerous books and films on this subject. And yet, I venture to give a few simple tips. Perhaps woo as I give myself a vow for the New Year to start living more correctly. Then my advice can be useful to you.

1. No one needs sick heroes. Remember that to achieve the result you need a good physical well-being and a creative rise. If they are not, there is no result. You have been unwell all day and the code is poorly written. Do not suffer in the evening about this. Do not try to finish at home not done in the afternoon with a thermometer in the armpit. Better drink tea with honey and go to bed early.
2. The right mix. Programming can be compared with long jumps. Only the jumper first runs faster and then jumps, and the programmer has an insight-solution (jump) and then he finishes the necessary routine operations. It is impossible to jump eight hours in a row. Shuffle your creative flight and routine.
3. Be able to relax during the day . Project managers, especially large ones, tend to go overboard with meetings that are of little use to programmers. If you can’t avoid them, don't be mad at the lost time and the talkative participants of the meeting. Think about your own thing, letting gossip along the secondary path of consciousness. Learn to take a thoughtful and interested facial expression.
4. Plan everyday success. Break up tasks into parts that you can expect to be able to program them in an hour or two. As a last resort, arrange your plans for the day so that there is hope that something will “round off” before the end of the working day.
5. Finish the working day with a victory. If you have successfully completed the task half an hour or an hour before the end of the working day, do not start a new one. Most likely, the "batteries" in your head are already "hooked." Maybe you have accumulated a couple of organizational tasks such as a trip report? And if after 5 minutes you need to go out in order to catch the train, turn off the computer and do not try to write another line. The written line most likely will give nothing, but because of the missed train, you will be angry with yourself. And most importantly, if you stay at work for another two or more hours, the solution most likely will not come. But on the way home it can even come. I checked it on myself many times.

I repeat again. This text does not pretend to the scientific depth and thoroughness in the selection of materials and arguments.

Your opinion would be very interesting to me. Therefore, I beg you to answer the questions below.

And if you didn’t like my arguments, please reflect your objections in the comments, not in the minus of the article. After all, the New Year on the nose.

Author's illustration Nightmare JavaScript Programmer