Anger over code: programmers and negativity

I am looking at a piece of code. Perhaps this is the worst code I've ever met. To update just one record in the database, it extracts all the records in the collection, and then sends a request to update each record in the database, even those that do not need to be updated. There is a map function that simply returns the value passed to it. There are conditional checks of variables with obviously the same value, just named in different styles ( firstNameand first_name). For each UPDATE, the code sends a message to another queue, which is processed by another serverless function, but which does all the work for another collection in the same database. I did not mention that this serverless function is from a cloud-based “service-oriented architecture” containing more than 100 functions in the environment?

How could such a thing be done? I cover my face and sob through the laughter. My colleagues ask what happened, and I retell in color the Worst Hits Of BulkDataImporter.js 2018 . Everyone nods sympathetically to me and agrees: how could they do this to us?

Negative: an emotional tool in programmer culture

Негатив играет в программировании важную роль. Он встроен в нашу культуру и используется для того, чтобы поделиться узнанным («ты не поверишь, на что был похож этот код!»), для выражения сочувствия через расстройство («господи, ЗАЧЕМ так делать?»), чтобы показать себя в выгодном свете («я бы никогда так не сделал»), чтобы взвалить вину на другого («мы зафейлились из-за его кода, который невозможно сопровождать»), или, как принято в самых «токсичных» организациях, чтобы управлять другими через чувство стыда («ты о чём вообще думал? исправляй»).



Negativity is so important to programmers because it is a very effective way of conveying value. I used to study in a programmer camp, and the standard practice of vaccinating students with guild culture was to generously supply memes, stories, and videos, the most popular of which exploited the sadness of programmers when they were confused by people . It’s good when you can use emotional tools to denote the Good, Bad, Horrible, Never Do This, Never at all. It is necessary to prepare beginners for the fact that their colleagues, far from IT, will probably understand them erroneously. That their friends will begin to push them ideas of applications "in a million." What they have to wander in the endless mazes of outdated code with a bunch of minotaurs around the corner.

When we begin to learn programming for the first time, our understanding of the depth of the “programming experience” is based on observations of other people's emotional reactions. This is clearly seen in the posts in the ProgrammerHumor subwoofer , in which many new programmers hang out. Many humorous posts, to one degree or another, are colored with different shades of negative: disappointment, pessimism, resentment, indulgence, and others. And if this doesn't seem enough to you, read the comments.



I noticed that, with the accumulation of experience, programmers are becoming more and more negative. Beginners, unaware of the difficulties awaiting them, begin with enthusiasm and willingness to believe that the reason for these difficulties is simply a lack of experience and knowledge; and in the end they will face the real state of things.

Time passes, they gain experience and gain the ability to distinguish Good code from Bad. And when this moment comes, young programmers are upset by working with apparently bad code. And if they work in a team (remotely or in person), they often adopt the emotional habits of more experienced colleagues. Often this leads to an increase in negative, because young people can now thoughtfully talk about the code and divide it into bad and good, thereby showing that they are “in the subject”. This reinforces the negative even more: because of disappointment it is easy to meet with colleagues and become part of a group, criticism of the Bad Code raises your status and professionalism in the eyes of others: people who express a negative opinion are often perceived as more intelligent and competent .

Strengthening the negative is not necessarily a bad thing. The discussion of programming, among other things, is extremely focused on the quality of the written code. What the code is, completely determines the function for which it is intended (we discard the equipment, the network, etc.), so it is important to be able to express your opinion about this code. Almost all discussions boil down to whether this code is good enough and to condemning the manifest itself of the bad code in expressions whose emotional coloring characterizes the quality of the code:

• “There are a lot of logical inconsistencies in this module, which is a good candidate for significant performance optimization.”
• “This module is pretty bad, we need to refactor it.”
• "This module does not make sense, it needs to be rewritten."
• "This module sucks, it needs to be patched."
• "This is a piece of ram, not a module, it did not need to be written at all, what the hell was the author thinking."

By the way, it is this “emotional release” that forces developers to call the code “sexy,” which is rarely fair - unless you work in PornHub.

The problem is that people are strange, troubled, filled with emotions of creation, and the perception and expression of any emotions changes us: at first, barely noticeable, but over time - dramatically.

Restless slippery track of negativity

A few years ago I was an informal team lead and interviewed one developer. We really liked him: he was smart, asked good questions, was technically savvy and fit perfectly into our culture. I was particularly impressed by his positivity and how adventurous he seemed. And I hired him.

At that time, I worked in the company for a couple of years and felt that the culture adopted in our country was not very effective. We tried to launch the product twice, thrice, and a couple of times before I arrived, which led to large expenses for rework, during which we had nothing to show except for long nights, short deadlines and type-working products. And although I still worked hard, I was skeptical about the last deadline assigned to us by the management. And he cursed casually when discussing with my colleagues some aspects of the code.

So there was nothing surprising in the fact - although I was surprised - that a few weeks later the very same new developer spoke in the same negative way as I did (including swearing). I realized that he would have acted differently in a different company with a different culture. He only adjusted to the culture that I created. Guilt overwhelmed me. Because of my subjective experience, I instilled pessimism into the novice, whom I perceived as completely different. Even if he really wasn’t like that and just tried to seem to show that he could join the team, I imposed my shitty attitude on him. And all that has been said, even as a joke or in passing, has a bad manner of transforming what one believes in.

Ways of negativity

Let us return to our former novice programmers who gained a little wisdom and experience: they got to know the programming industry more closely and understand that bad code is everywhere, it cannot be avoided. It is found even in the most advanced companies focused on quality (and let me note: it seems that modernity does not save us from bad code at all).

Good script. Over time, developers begin to put up with the fact that bad code is the reality of software, and that their job is to improve it. And what if bad code cannot be avoided, then there is no point in making noise because of it. They embark on the path of Zen, focus on solving problems or tasks that confront them. They learn how to accurately measure and deliver the quality of software to business owners, based on their many years of experience, write perfectly justified estimates, and ultimately receive generous rewards for their incredible and unchanging value for the business. They do their job so well that they are paid bonus bonuses of $ 10 million, and they retire to do what they want for the rest of their lives (please do not take it on faith).



Another scenario is the path of darkness. Instead of accepting bad code as inevitable, developers take on the responsibility of announcing all the bad in the programming world so that they can defeat it. They refuse to improve the existing bad code for many good reasons: “people should know more and not be so stupid”; "it is unpleasant"; “This is bad for business”; “It proves how smart I am”; “If I don’t tell you what a lousy code this is, the whole company will fall into the ocean,” and so on.

Surely not having the opportunity to implement their desired changes, because business, unfortunately, must continue to develop and cannot spend time caring about the quality of the code, such people gain a reputation as complainants. They are held for high competence, but are driven out to the backyard of the company, where they will not annoy many, but at the same time they will support the operation of critical systems. Having lost access to new opportunities in development, they lose their skills and cease to meet the requirements of the industry. Their negativity turns into fierce bitterness, and as a result they amuse their ego, arguing with twenty-year-old students about the path that their beloved old technology has followed and why it is still crisp. In the end, they retire and live old age, cursing at birds.

Probably, the reality is somewhere in the middle between these two extremes.

Some companies have been extremely successful in creating extremely negative, discrete, strong-willed cultures (like Microsoft before its lost decade).) - often these are companies with products that perfectly match the market and the need to grow as quickly as possible; or companies with a hierarchy of management and control (Apple in Jobs's best years), where everyone does what they command. However, modern business research (and common sense) suggests that for maximum ingenuity, leading to the innovativeness of the company, and high productivity of individuals, a low level of stress is required to maintain continuous creative and methodical thinking. And it’s extremely difficult to do creative work, which is based on discussions if you are constantly worried about what your colleagues will have to say about every line of your code.

Negative is engineering pop culture

Today, more attention is paid to the attitude of engineers than ever. In engineering organizations, the “ No Ovuk ” rule is becoming increasingly popular . On Twitter, there are more and more jokes and stories about people who left this profession because they could not (did not want) to continue to put up with hostility and hostility towards outsiders. Even Linus Torvalds recently apologized over the years of his hostility and criticism of other Linux developers - this led to a discussion about the effectiveness of this approach.

Someone still defends Linus' right to be very critical - those who need to know a lot about the advantages and disadvantages of “toxic negativity”. Yes, correctness is extremely important (even fundamental), but if we summarize the reasons why many of us allow the expression of negative opinions to turn into “toxicity”, then these reasons look paternalistic or adolescent: “they deserve it because they are idiots”, “he I must be sure that they won’t repeat it, "" if they hadn’t done that, he would not have to yell at them, "and so on. An example of how the leader’s emotional reactions affect the programmer community is the MINASWAN abbreviation in the Ruby community - “Matz is nice so we are nice” (Matz [creator of the language] is good, so we are good).

I noticed that many ardent supporters of the “kill the fool” approach often take great care of the quality and correctness of the code, identifying themselves with their work. Unfortunately, they often confuse hardness with stiffness. The disadvantage of this position stems from a simple human, but unproductive desire to feel superior to others. People who are immersed in this desire are stuck in the path of darkness.



The world of programming is growing rapidly and abuts the boundaries of its container - the world of non-programming (or is this the world of programming a container for the world of non-programming? Good question).

As our industry expands at an increasing pace and programming becomes more accessible, the distance between “techies” and “normal” is rapidly decreasing. The world of programming is increasingly exposed to interpersonal communication between people who grew up in an isolated culture of “nerds” of the beginning of techno-boom, and it is they who will form the new world of programming. And regardless of any arguments regarding the social sphere or generations, efficiency in the name of capitalism will manifest itself in the culture of companies and approaches to hiring: the best companies simply will not hire those who can not interact with others neutrally, not to mention good relations.

What I learned about the negative

If you allow an excess of negativity to control your mind and communication with people, turning into "toxicity", then this is dangerous for product teams and expensive for business. I saw a myriad of projects (and heard about such) that fell apart and were completely redone with great expense, because one of the trusted developers sharpened their teeth on the technology, another developer, or even the only file selected to represent the quality of the entire code base .

Negativity also demoralizes and destroys relationships. I will never forget how a colleague scolded me for putting CSS in the wrong file, this upset me and prevented me from gathering my thoughts for several days. And in the future I’m unlikely to allow such a person to be close to one of my teams (however, who knows, people are changing).

Finally, negativity literally harms your health .


It seems to me that a master class on smiles should look like this.

Of course, this is not an argument in favor of being happy, inserting ten billion smileys into each pull request or going to a master class with smiles (not, well, if that is what you want, then no question). Negativity is an extremely important part of programming (and human life), signaling quality, allowing you to express feelings and condolences to people-brothers. Negative evidence of insight and reasonableness, the depth of the problem. I often notice that a developer has reached a new level when he begins to express distrust in what he was timid and unsure of. With their opinions, people demonstrate prudence and confidence. One cannot reject the expression of negativity, it would be in Orwellian style.

However, the negative must be dosed and balanced with other important human qualities: empathy, patience, understanding and humor. You can always tell a person that he screwed up without screaming and cursing. Do not underestimate this approach: if you are completely without emotion they say that you seriously messed up, it really scares.

At that time, several years ago, CEO spoke to me. We discussed the current situation of the project, then he asked how I feel. I replied that everything was fine, the project was moving, we were slowly working, perhaps I had missed something and needed to be reviewed. He said that he heard me sharing more pessimistic considerations with colleagues in the office, and that others also noticed this. He explained that if I have doubts, I can fully express them to the leadership, but not to "lower them down." As a lead engineer, I must remember how my words affect others, because I have great influence, even if I don’t realize it. And all this he told me very kindly, and in the end said that if I really feel such feelings, then I probably need to think about what I want for myself and my career. It was an incredibly soft conversation in the style of "pull yourself together or get out." I thanked him for the information about how my attitude, which has changed over the past six months, imperceptibly affects others for me.

This was an example of wonderful, effective management and the power of a soft approach. I realized that it only seemed to me that I totally believed in the company and its ability to achieve goals, but in reality I spoke and communicated with others in a completely different way. I also realized that even feeling skepticism about the project I was working on, I should not have shown my attitude to my colleagues and spread pessimism like an infection, reducing our chances of success. Instead, I could aggressively broadcast the real situation to my leadership. And if I felt that they were not listening to me, I could express my disagreement with leaving the company.

I got a new opportunity when I took the position of head of staff assessment. As a former chief engineer, I carefully monitor my opinion on our (constantly improving) legacy code. To approve the change, you need to imagine the current situation, but you won’t come to anything if you get bogged down in moaning, attacking or something like that. Ultimately, I am here to complete the task, and should not complain about the code in order to understand, evaluate, or correct it.

In fact, the more I restrain my emotional reaction to the code, the better I understand what it could become, and the less confusion I feel. When I expressed myself with restraint (“there should be room for further improvements”), I was thereby pleasing to myself and others and not taking the situation too close to my heart. I realized that I can stimulate and lower the negative in others, being perfectly (annoyingly?) Prudent (“you are right, this code is pretty bad, but we will improve it”). I'm glad how far I can go along the path of zen.

In fact, I am constantly learning and relearning an important lesson: life is too short to be constantly angry and suffering.