I am looking at a piece of code. Possibly the worst code I've ever come across. To update just one record in the database, it fetches all the records in the collection and then sends an update request to every record in the database, even those that don't need to be updated. There is a map function here that simply returns the value passed to it. There are conditional checks for variables with apparently the same value, just named in different styles (firstName и first_name). For each UPDATE, the code sends a message to another queue, which is handled by a different serverless function, but which does all the work for a different collection in the same database. Did I mention that this serverless feature is from a cloud "service-oriented architecture" with over 100 features in the environment?
How could such a thing be done? I cover my face and sob visibly through laughter. My colleagues ask what happened, and I retell in colors Worst Hits Of BulkDataImporter.js 2018. Everyone nods sympathetically at me and agrees: how could they do this to us?
Negativity: an emotional tool in programmer culture
Negativity plays an important role in programming. It is built into our culture and is used to share what is learned (“you are not believewhat that code was like!"), to express sympathy through frustration ("God, WHY would you do that?"), to show yourself in a favorable light ("I would never so didn't") to put the blame on someone else ("we got fouled because of his unmaintainable code"), or, in the most "toxic" organizations, to control others through shame ("what were you thinking ? correct").
Negativity is so important to programmers because it is a very effective way of conveying value. I used to go to a programming camp, and it was standard practice to inoculate students with shop culture by generously supplying them with memes, stories, and videos, the most popular of which exploited . It's good to be able to use emotional tools to label Good, Bad, Terrible, Never Do It, Never Do It. It is necessary to prepare beginners for the fact that they will certainly be misunderstood by colleagues who are far from IT. That their friends will start pitching them million dollar app ideas. That they'll have to wander through endless labyrinths of obsolete code with a bunch of minotaurs around the corner.
When we first start learning to code, our idea of the depth of the "programming experience" comes from observing the emotional reactions of other people. This is clearly seen in the posts where a lot of newbie programmers hang out. Many humorous ones are to some extent colored with different shades of negativity: disappointment, pessimism, indignation, condescension and others. And if that's not enough for you, read the comments.
I noticed that, as experience accumulates, programmers become more and more negative. Beginners, unaware of the difficulties that await them, begin with enthusiasm and a willingness to believe that the cause of these difficulties is simply a lack of experience and knowledge; and in the end they will face the real state of affairs.
Time passes, they gain experience and gain the ability to distinguish Good code from Bad. And when that moment comes, young programmers get frustrated with obviously 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 negativity, because young people can now talk thoughtfully about the code and divide it into bad and good, thereby showing that they are “in the know”. This further reinforces the negative: on the basis of disappointment, it is easy to get along with colleagues and become part of a group, criticism of Bad code increases your status and professionalism in the eyes of others: .
An increase in negativity is not necessarily a bad thing. The discussion of programming, among other things, is extremely focused on the quality of the code written. What the code is completely defines the function for which it is intended (we leave out hardware, network, etc.), so it is important to be able to express your opinion about this code. Almost all the discussion boils down to whether this code is good enough, and to condemning the very manifestos of bad code in expressions whose emotional coloring characterizes the quality of the code:
- "This module has a lot of logical inconsistencies and is a good candidate for significant performance optimizations."
- "This module is pretty bad, we need to refactor it."
- "This module doesn't 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 didn’t need to be written at all, what the hell was its author thinking about.”
By the way, it's this "emotional release" that makes developers call code "sexy", which is rarely fair unless you work for PornHub.
The problem is that people are strange, restless, emotional creatures, and the perception and expression of any emotion changes us: at first subtly, but over time, dramatically.
The restless slippery slope of negativity
A few years ago, I was an informal team leader and interviewed one developer. We really liked him: he was smart, he asked good questions, he was tech-savvy, and he fit in perfectly with our culture. I was particularly impressed by his positivity and how enterprising he seemed. And I hired him.
At that time, I worked in the 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 I arrived, which led to a lot of rework costs, 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 latest deadline assigned to us by management. And casually cursed when discussing some aspects of the code with my colleagues.
So it was not surprising - though I was surprised - that a few weeks later the same new developer spoke in the same negative way as I (including expletive). I realized that he would behave differently in a different company with a different culture. He just adapted to the culture that I created. Guilt washed over me. Because of my subjective experience, I instilled a pessimism in the newcomer that I perceived as quite different. Even though he wasn't really like that and was only trying to appear to show that he could fit in, I forced my shitty attitude on him. And everything said, even in jest or in passing, has a bad habit of turning into what they believe.
Ways of negativity
Let's go back to our former novice programmers who have gained a bit of wisdom and experience: they got to know the programming industry better 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 tell you, modernity does not seem to save you from bad code).
Good script. Over time, developers come to terms with the fact that bad code is the reality of software and that it is their job to improve it. And that if bad code cannot be avoided, then there is no point in making a fuss about it. They take the path of Zen, focusing on solving problems or tasks that confront them. They learn how to accurately measure and communicate software quality to business owners, write well-reasoned estimates based on their years of experience, and ultimately receive generous rewards for their incredible and consistent business value. They do their job so well that they get paid $10 million bonuses and retire to do whatever they want for the rest of their lives (please don't take it for granted).
Another scenario is the path of darkness. Instead of accepting bad code as inevitable, developers take it upon themselves to announce everything bad in the programming world so they can beat it. They refuse to improve existing bad code for a variety of good reasons: "people should know more and not be so dumb"; "it is unpleasant"; "this is bad for business"; “this 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.
Probably not being able to implement the changes they want because the business unfortunately has to keep developing and can't take the time to care about code quality, such people gain a reputation for complaining. They are held for their high competence, but they are pushed to the back of the company, where they will not annoy many, but at the same time they will keep critical systems running. Without access to new opportunities in development, they lose their skills and cease to meet the requirements of the industry. Their negativity turns to bitter bitterness, and as a result, they feed their egos by arguing with twenty-year-old students about the path their favorite old technology has traveled and why it is still peppy. They eventually retire and live out their old age swearing at birds.
The reality is probably somewhere in between these two extremes.
Some companies have been extremely successful at creating extremely negative, isolated, strong-willed cultures (like Microsoft before its ) - 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 command and control (Apple in the best years of Jobs), where everyone does what they are told. However, modern business research (and common sense) suggests that for maximum ingenuity leading to company innovation and high individual productivity, low stress levels are required to support continuous creative and methodical thinking. And it's extremely difficult to do creative work based on discussions if you constantly worry about what your colleagues will have to say about every line of your code.
Negativity is engineering pop culture
Today, the attitude of engineers is given more attention than ever. In engineering organizations, the rule “". There are more and more jokes and stories on Twitter about people who left this profession because they could not (did not want to) continue to put up with hostility and ill will towards outsiders. Even Linus Torvalds over the years of hostility and criticism of other Linux developers - this has led to a discussion about the effectiveness of this approach.
Someone still defends Linus's right to be very critical - those who should know a lot about the advantages and disadvantages of "toxic negativity". Yes, correctness is extremely important (even fundamental), but if you summarize the reasons why many of us allow the expression of a negative opinion to turn into “toxicity”, then these reasons look paternalistic or adolescent: “they deserve it because they are idiots”, “he he must be sure that they will not repeat this”, “if they had not done so, he would not have had to yell at them”, and so on. An example of the impact that a leader's emotional reactions have on the programming community is the Ruby community's abbreviation for MINASWAN, "Matz is nice so we are nice."
I've noticed that many ardent "kill the fool" proponents are often very concerned about the quality and correctness of the code, identifying themselves with their work. Unfortunately, they often confuse hardness with stiffness. The disadvantage of such an attitude stems from a simple human but unproductive desire to feel superior to others. People who sink into this desire get stuck in the path of darkness.
The world of programming is growing rapidly and rests on the boundaries of its container - the world of non-programming (or is the world of programming a container for the world of non-programming? good question).
As our industry expands at an accelerating pace and programming becomes more accessible, the distance between "techie" and "normal" is rapidly shrinking. The world of programming is increasingly exposed to the interpersonal communication of people who grew up in the isolated culture of "nerds" of the early tech boom, and it is they who will form the new world of programming. And regardless of any social or generational arguments, efficiency in the name of capitalism will show up in company culture and hiring practices: the best companies simply won't hire those who can't interact with others in a neutral way, let alone in a good relationship.
What I learned about negativity
If you allow an excess of negativity to rule your mind and your interactions with people, turning into “toxicity”, then it is dangerous for product teams and expensive for business. I have seen a myriad of projects (and heard of them) that fell apart and were completely re-done at great cost because one trusted developer had a grudge against a technology, another developer, or even a single file chosen to represent the quality of the entire codebase .
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 am unlikely to allow such a person to be near one of my teams (however, who knows, people change).
Finally, the negative .
I think this is how a master class on smiles should look like.
Of course, this is not an argument in favor of beaming with happiness, inserting ten billion emojis into every pull request, or going to a smile master class (no, well, if that's what you want, then it's not a question). Negativity is an extremely important part of programming (and human life), signaling quality, allowing you to express feelings and sympathize with human brothers. The negative testifies to insight and prudence, to the depth of the problem. I often notice that a developer has reached a new level when he begins to express disbelief in what he was previously timid and insecure about. By their opinions, people demonstrate prudence and confidence. You can not discard the expression of negativity, it would be Orwellian.
However, the negative needs to be dosed and balanced with other important human qualities: sympathy, patience, understanding and humor. You can always tell a person that he screwed up, without shouting and swearing. This approach should not be underestimated: if they tell you completely without emotion that you have seriously messed up, it really scares.
At that time, a few years ago, the CEO spoke to me. We discussed the current state of the project, then he asked how I felt. I replied that everything is fine, the project is moving forward, we are slowly working, perhaps I missed something and need to be reviewed. He said he heard me share more pessimistic thoughts with colleagues in the office, and that others noticed it too. He explained that if I have doubts, I can fully express them to the management, but not "bring it down." 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 told me all this in a very kind way, and concluded that if I really feel like that, then I probably need to think about what I want for myself and my career. It was incredibly soft talk in the style of "pull yourself up or get out." I thanked him for the information about how my attitude changed in half a year, imperceptibly for me, affects others.
It was an example of remarkable, effective management and the power of a soft approach. I realized that I only thought I had complete faith in the company and its ability to achieve its goals, but in reality I spoke and communicated with others in a completely different way. I also realized that even though I felt skeptical 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 by leaving the company.
I got a new opportunity when I took the position of Head of Human Resources. As a former chief engineer, I am very careful about expressing my opinion on our (constantly improving) legacy code. You have to be aware of the current situation in order to approve a change, but you won't get anywhere if you wallow in moaning, attacking, or the like. Ultimately, I'm here to get the job done, and don't have to complain about the code in order to understand, evaluate, or fix it.
In fact, the more I restrain my emotional reaction to the code, the more I understand what it could be, and the less confusion I experience. When I expressed restraint (“there should be room for further improvement”), I thereby pleased myself and others and did not take the situation too personally. I realized that I could stimulate and reduce negativity in others by being perfectly (annoyingly?) sensible (“you're right, this code is pretty bad, but we'll improve it”). I'm happy with how far I can go on 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.
Source: habr.com