Anger at the code: programmers and negative

I am looking at a piece of code. Perhaps this is the worst code I've ever met. To update only one record in the database, it retrieves 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 for variables with obviously the same value, simply named in different styles ( firstName and 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 a different 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 clearly sob through laughter. My colleagues ask what happened, and I colorfully retell 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

Negative plays an important role in programming. It is built into our culture and is used to share what we learned (“you won’t believe what this code looked like!”), To express empathy through frustration (“my God, why do that?”), To show your advantage in light (“I would never do that”) to put the blame on another (“we zafililis because of his code, which is impossible to accompany”), or, as is customary in the most “toxic” organizations, to control others through a sense of shame (“What are you thinking about? Fix it”).
')


Negativity is so important for programmers because it is a very effective way to transfer value. I once studied in a camp for programmers, and the standard practice of inoculation to students of the shop culture was a generous supply of memes, stories and videos, the most popular of which exploited the chagrin of programmers when they were confused with people’s misunderstanding . Well, when you can use emotional tools to refer to the techniques of Good, Bad, Horrible, Never Do It, Generally Never. It is necessary to prepare newbies for the fact that their colleagues, far from IT, will surely understand them mistakenly. That their friends will begin to sniff out ideas for apps "for a million". That they will have to wander in the endless labyrinths of outdated code with a bunch of minotaurs around the corner.

When we start learning 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 can be clearly seen from posts in ProgrammerHumor , in which many new programmers hang out. Many humorous posts in varying degrees, painted with different shades of negative: disappointment, pessimism, resentment, condescension, and others. And if this seems a little to you, read the comments.



I noticed that as they accumulate experience, programmers become more and more negative. Beginners who are unaware of the difficulties that await 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 opportunity to distinguish good code from bad. And when this moment comes, young programmers are frustrated with working with obviously bad code. And if they work in a team (remotely or in person), they often adopt emotional habits of more experienced colleagues. Often this leads to an increase in negativity, because young people can now speak thoughtfully about the code and divide it into good and bad, thus showing that they are “in the subject.” This further enhances the negative: it is easy to get along with colleagues and become part of a group because of disappointment, criticism of a bad code improves 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, fully defines the function for which it is intended (we drop the equipment, the network, etc.), so it is important to be able to express our opinion about this code. Almost all discussions boil down to whether this code is good enough and to condemn the manifestos of bad code in expressions whose emotional coloring characterizes the quality of the code:

• "There are a lot of logical inconsistencies in this module, it 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 a ram, not a module, it didn’t need to be written at all, what the fuck was thinking its author.

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

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

Troubled slippery negative track

A few years ago, I was an informal tmlid and interviewed a single developer. We liked him very much: he was smart, asked good questions, was technically savvy and perfectly fit into our culture. I was especially impressed by his positivity and how enterprising he seemed. And I hired him.

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

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 (including curses). I realized that he would behave differently in another company with a different culture. He only adjusted to the culture that I created. I felt guilty. Because of my subjective experience, I instilled pessimism in the newcomer, which I perceived to be completely different. Even if he really wasn’t that way and only tried to seem to show that he could join the team, I imposed my crappy attitude on him. And everything that has been said, even if in jest or in passing, has a bad manner of turning into what they believe.

Ways of Negative

Let us return to our former novice programmers, who gained a little wisdom and experience: they became better acquainted with the programming industry 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: apparently, modernity does not at all save from bad code).

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



Another scenario is the path of darkness. Instead of accepting bad code as inevitable, developers take it upon themselves to announce bad things in the programming world so that they can beat 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 what a lousy code this is, the whole company will plunge into the ocean,” and so on.

Surely not having the opportunity to realize the changes they want, because, unfortunately, the business must continue to develop and cannot waste time caring about the quality of the code, such people gain the reputation of complainants. They are held for their high competence, but they are forced out to the back of the company, where they will not be annoyed by many, but will also support the work 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 negative turns into bitter bitterness, and as a result, they entertain their ego, arguing with twenty-year-old students about the path traversed by their favorite old technology and why it is still hearty. In the end, they retire and live old age, cursing at the birds.

The reality is probably somewhere in the middle between these two extremes.

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

Negative - it's engineering pop culture

Today, engineers are paid more attention than ever before. In engineering organizations, the “ No Ovniuk ” rule is becoming more and more popular. On Twitter, there are more and more jokes and stories about people who have left this profession because they could not (did not want) to continue to put up with hostility and malevolence 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 upholds Linus’s right to be very critical - those who should know a lot about the advantages and disadvantages of “toxic negative”. Yes, correctness is extremely important (even fundamental), but if we summarize the reasons why many of us allow the expression of a negative opinion to turn into “toxicity”, these reasons look paternalistic or adolescent: “they deserve it because they are idiots”, “he I must be sure that they will not repeat it, ”“ if they had not done so, he would not have to yell at them, ”and so on. An example of the impact that a leader’s emotional reactions have on the programmer community is the abbreviation MINASWAN in the Ruby community - “Matz is nice so we are nice” (Matz [language creator] is good, so are we 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 hardness. The lack of such a 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 programming world is growing rapidly and abuts the boundaries of its container — the non-programming world (or is the programming world a container for the non-programming world? A good question).

As our industry expands at an increasing rate and programming becomes more accessible, the distance between “techies” and “normal” is rapidly decreasing. The world of programming is increasingly exposed to the interpersonal communication of people who have grown up in the isolated culture of the “nerds” of the beginning of the technoboom, and it is they who will form the new world of programming. And despite any arguments about 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 will simply not hire those who cannot interact with others neutrally, not to mention good relations.

What I learned about the negative

If you allow a surplus of negative to control your mind and communication with people, turning into "toxicity", then it is dangerous for food teams and expensive for business. I saw a myriad of projects (and heard about such) that collapsed and were completely reworked at great cost, because one of the developers who were trusted sharpened a tooth on the technology, another developer or the only file chosen 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, it upset me and did not allow me to collect my thoughts for several days. And in the future I will hardly allow such a person to be close to one of my teams (however, who knows, people change).

Finally, the negative literally hurts your health .


It seems to me that a smile class should look like this.

Of course, this is not an argument in favor of radiating happiness, inserting ten billion smilies into each pull request or going to a master class in smiles (no, well, if you want this, then no question). Negative is an extremely important part of programming (and human life), signaling quality, allowing you to express feelings and help people to brothers. Negative evidence of insight and prudence, the depth of the problem. I often notice that the developer has reached a new level, when he begins to mistrust what he was shy and unsure about. With their opinions, people demonstrate prudence and confidence. It is impossible to discard the expression of the negative, it would be Orwellian.

However, the negative must be dispensed and balanced by other important human qualities: sympathy, patience, understanding and humor. You can always tell a person that he screwed up, without shouting and swearing. Do not underestimate this approach: if you are completely without emotion they say that you are seriously nosyachil, it really scares.

That time, a few years ago, CEO talked to me. We discussed the current status of the project, then he asked how I felt. I replied that everything is fine, the project is moving, we are slowly working, perhaps I missed something and need to be reconsidered. He said that he had heard me share 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 “lower them”. As a lead engineer, I have to remember how my words affect others, because I have a lot of influence, even if I don’t realize it. And he said all this to me very kindly, and in conclusion he said that if I really have 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 in six months, imperceptibly affects others.

It was an example of a wonderful, efficient management and the power of a soft approach. I realized that it only seemed to me as if I completely 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 of his leadership. And if I felt that they were not listening to me, I could have expressed my disagreement by leaving the company.

I received a new opportunity when I took the post of head of personnel evaluation. Being a former chief engineer, I watch very closely the expression of my opinion about our (constantly improving) legacy code. , , , , - . , , , , , .

, , , , . (« »), . , , (?) (« , , »). , .

, : , .