Go yourself on ... or the rules of communication in a team

Post-response to the article "Come on! @ # With your" toxicity "" .

If I followed the advice from this article, it would be enough for me to show emotion and tell the author "Go yourself on ... you don’t understand anything!".

However, this would not help to convey my point. So let's take a closer look.

Quote 1:

If a person is incompetent, it is necessary to give him a clear understanding of this, and not to take care of his tender feelings to the detriment of everything else.

I do not agree with the basis of this statement. I believe that a person can not be competent or incompetent. Such a generalized black and white approach does not work in practice. Even the most pumped senior may not know any things. Conversely, juniors sometimes have great ideas.

Getting personal ("you are not competent!") To the review code instead of specific arguments is too easy. If you are so smart senior, work hard, explain why it is in this place of the code that everything should be different. You can not explain - better not write anything, because it is possible and you do not fully understand.

At the same time, it is certainly necessary to talk about specific problems in the code.

A normal person is happy to discuss a reasoned position. And take hostile negative emotions. Who would ever want to work with a toxic team member?

Quote 2:

A person can send you a review code with the same mistakes again and again and you need to respond to this with politeness and a smile?

If a person makes mistakes time after time and does not try to grow somehow, then he should be fired. Talk with team lead on this. But hysteria is not necessary anyway. Well, just because it does not help.

Negative emotions can generate only negative emotions. And errors in the code will not fix it.

Quote 3:

The greater the responsibility in the profession, the greater should be the resistance to stress.

I worked with the production environment and used to fix some problems at night. Often, it was stress (especially when you head those department and are responsible for the whole collective farm).

And I want to state with full responsibility: no one likes stresses, even if he is able to withstand them. Everyone always tries to make stress less.

For example:

• set up monitoring, timely alert from servers, that there are any problems
• code check automatic and manual testing
• database backups check for recoverability
• etc.

In short, reducing potential problems as much as we can.
Those. stress is bad in general . Even for the most "stress-resistant" people.

Just the same person who does not like stress, most likely will do everything right, will double-check everything, spread straw and will not allow fatal mistakes.

Quote 4:

Undoubtedly, it is unacceptable to insult a colleague because of a lack of knowledge, but the obvious format “Your code is bad, I will now explain in detail the reasons and give advice” is already considered toxic behavior.

Well, yes, it is. "Your code is bad" - IMHO is a meaningless phrase, one could immediately begin with advice, or even better clarifying questions, why it was done this way and not otherwise.

Afterword

Stress interferes with performance. When an employee is afraid to give the code for review, he will not work with enthusiasm, will not generate ideas, will not be loyal to the company, etc.

It is easy to googling studies that show that when a certain level of stress is exceeded, working capacity decreases sharply.

In general, politeness when working in a group was invented not now, long before the code review and programming in general has become fashionable. A bunch of articles about "teamwork skills", not related to IT any side.

The best ideas are born in a favorable atmosphere.

Take, for example, the rules of brainstorming: first, everyone throws in ideas, and cannot criticize them at all. And only then is a detailed discussion.

Well, that is, we are all people. People do not like it when someone points out their mistakes. Even the most correct revision code often looks like a public spanking. Well, no need to aggravate!

In those teams where I was Timlid, I introduced the code of conduct for code review (even before this herd is fashionable). Namely: politeness, the ban on the mandative tone, the ban on the discussion of personal qualities, only reasoned comments are allowed, etc. In controversial situations decides the majority.

By the way, it is the majority, not the timlid / technical leader. Since the readability of the code and other things is important for the whole team, the team will work with this code in the future. And not the one who considers himself the most intelligent.

These simple measures have significantly improved the atmosphere in the team.

Why in general now everyone started talking about CoC and teamwork? Because in general, the time of single geniuses passes. A cohesive team through synergy will solve any problem. I talked with one, talked with another - and the problem was solved. Soft skills become more and more important every day.

There are people who have never worked in a close-knit team, and do not know what a thrill it is.

Yes, actually that I crucify here, go, you yourself on ...

(PS The emoticon at the end of the last phrase was removed by the moderators. I do not want to offend anyone, this is just a joke)