How can programmers be respected?

[[129683]]

I learned that an old classmate I hadn't seen for a long time had come to the Bay Area. However, when I met him, he was in the most painful period of his life. He complained to me that the company he worked for was like two different people before and after he joined. When he was admitted, the company told him that they were very satisfied with his performance and academic background during the internship. He didn't need to interview or even graduate to get a degree. He could directly join our company as a formal employee. However, today, just one year later, this classmate no longer feels the company's respect for his skills. The manager asked him to do some messy and unskilled things, complained that he was too slow, and wrote a lot of comments on his evaluation. Under the double blow of personal dignity and life security, this classmate was under great pressure. He often secretly worked overtime on weekends, but still could not satisfy the manager.

I know this classmate's ability very well, and he is definitely more than qualified to work in any first-class company. Of course, I will keep his name confidential, but I have to point out the company he works for - this is the place that many people worship as heaven, Google. The experience described by this classmate is exactly the same as my internship experience at Google a few years ago. I still remember that my teammates at Google watched me use Emacs and said to me in a tone like an elementary school teacher: "Press Ctrl-k!" I still remember that when I submitted a difficult and high-level code that my teammates could not write at all, I was accused and ridiculed for not knowing how to use Perforce. I still remember that during dinner, my colleagues were envious of the so-called "Google geniuses"...

Even if you have received the best education in the world and can accomplish work that no one else in the world can accomplish, you are still nothing compared to the so-called "big shots" in the minds of Googlers. Every day at Google, I feel like I am performing "The Emperor's New Clothes". I am making a beautiful dress for the emperor, and stupid or incompetent people cannot see this dress. The emperor's ministers come to inspect from time to time, but they find that they cannot see the fabric I weave... I am also like performing "Ye Gong Hao Long". There is a man named Ye Gong who claims to be looking for the world's top, most creative, and unconventional talents. But when he really saw such a person, he was afraid. He could not understand this ability, and did not know how to respect it, protect it, and use it. He was angry and embarrassed, how could someone be smarter than me! He closed his eyes and silently said, I am the most powerful, smartest, and greatest in the world! He was nitpicking and used superficial and stupid standards to judge the value of dragons...

My classmate is a top expert in his field. Google is not the only company that tramples on the value of experts and judges and treats them with superficial standards. Almost all the companies I worked for before had similar problems to a greater or lesser extent. Sometimes this may not be a problem for the entire company, but just some ignorant people. However, I am sure that this phenomenon is a company-wide atmosphere and behavior at Google. There are too many so-called "experts" (just so-called) at Google, so they don't care about you at all.

This phenomenon of disrespecting people in IT companies is not only aimed at experts, but also at all programmers. It's just that experts have seen a lot of things and are used to it, so they generally don't like to use superficial things to highlight themselves. However, it is precisely because of their modesty that they are easily attacked by people who have only a superficial understanding. Due to the universality and extremely harmful nature of this phenomenon of disrespecting people, I think it is necessary to talk about it specifically. In the following, I would like to point out the origin of the culture of disrespecting people in the IT industry, and at the same time give some suggestions to IT companies around the world, telling them how to truly respect a programmer. I hope these suggestions will be of reference value to the company's management, and I also hope that they can give some spiritual encouragement to programmers who are experiencing the same pain.

I think a company culture that respects programmers should always pay attention to the following points:

Acknowledge the legacy of software systems

If you understand computer science to a certain extent, you will find that we are still living in the Stone Age of computers. Compared with hardware, software systems are built on a bunch of bad designs left over from history. Various poorly designed operating systems (such as Unix, Linux), programming languages ​​(such as C++), databases, etc. often bother us, which is why you need so much so-called "experience". However, many IT companies do not like to admit this. Their style has always been "It's all the user's fault!", "You should know this!" This has created a kind of "Emperor's New Clothes Phenomenon": No one will use some poorly designed tools, but they are afraid of being laughed at or doubted by others, so no one dares to point out the designer's mistakes.

I am a counterexample of this "hacker culture". Whenever someone asks me for help because they don't know a certain tool or language, I always tease the designer of the tool and tell him that there is no reason for him to know these crap, but that's actually how it works. Then I tell him what this thing is, how to use it, and what design flaws have led to our weird usage now... I think all IT practitioners should have the same teasing attitude towards these tools. Only in this way can the software industry make substantial progress, instead of being troubled by some bad designs and being shackled by thinking.

In short, this is a very important "attitude problem". Although at this stage, we need to know how to bypass some poorly designed tools and use them to complete our tasks. However, at the same time, we must face and acknowledge the bad nature of these tools, and not blame the programmers. Only in this way can we effectively respect the IQ of programmers.

Distinguish between essential knowledge and superficial knowledge, and don’t take “experience” too seriously

IT companies often have people who think that being proficient in some seemingly complex command lines or some difficult programming languages ​​is great. These people don't realize that some of their colleagues actually have the essential knowledge, and they are fully capable of deriving and creating all these tools (not just using them) from their existing knowledge, and even designing them to be more perfect and convenient to use. People who can design and create better tools often have more important tasks, so when they are confused by the usage of existing tools, they often humbly ask their colleagues for help and boldly admit their confusion.

If you are the person who is proficient in the use of the tool, you must not take your colleague's modest request as an opportunity to show off your "qualifications". This colleague is often really "asking questions without shame". It's not that he "doesn't understand", but he simply doesn't bother and has no time to consider such low-level questions. His confusion often comes from the mistakes of the tool designer. He is very clear about this, but for the sake of politeness, he often does not directly criticize the design of the tool, but humbly blames himself. So your colleague's respect for you is entirely to create a friendly and harmonious atmosphere, and it does not mean that he is worshipping you and admitting that his technical ability is not as good as yours.

So the correct way to deal with it is to sincerely express your understanding of this confusion, and frankly admit the unreasonable and poor design of the tool. If you can adopt such a humble attitude, instead of the attitude of self-righteousness, your colleague will be happy to "learn" the superficial dead knowledge he needs from you, and remember it, so as to avoid bothering you for such boring things next time. If you act like "I am the only one in the world who knows this trick", your colleague will often despise you and the tool. He will still not remember how to use this thing next time, but he will never come to you for help again, but will procrastinate again and again.

Don't use an imperative tone, explain your intentions

Always remember that your colleagues and subordinates are not slaves or code monkeys, and they don’t have to work for you! They are reasonable people, but they will not simply obey your low-level orders just because they get paid. The behavior of my teammates at Google is a good negative example. In fact, this Googler just wanted to tell me to "delete this line of text, and then change it to this...", but she did not directly express this "high-level intention", but used very low-level instructions: "Press Ctrl-k!..." And the tone was like talking to an ignorant elementary school student.

Which Emacs user doesn't know that Ctrl-k deletes a line of text? And you are actually facing a senior Emacs user and a world-class Lisp programmer. I think everyone can see the problem here. Such low-level commands are not only illogical, but also offensive. What do you think I am? A code monkey? If this Googler expresses her high-level intentions, it will be easy for people to accept psychologically and logically. For example, she can say: "This line of the configuration file should be deleted and changed to..."

Similar techniques can be used in other aspects of project management. Before asking someone to do something, explain why you are doing it and why it is important, so that they can understand. Only in this way can you respect the IQ of programmers, because they are human beings, not code monkeys who only obey your commands.

Don't expect new people to learn from you

Many IT companies like to treat new employees as beginners and expect them to "learn" from them. For example, Google calls all new employees "Noogler" (meaning Newbie Googler) and even gives them a special propeller hat, which means that children should be humble and learn from "the great Google" so that they can be successful in the future.

This is actually a very wrong approach. It ignores the background knowledge that new employees already have and makes them succumb to the authority of the "great Google" and become an insignificant screw. Is there really a lot of things worth learning in Google? Is the education in school really worthless? Not really. I can honestly say that I learned the most essential knowledge from my professors. I did not learn any skills from Google that could surpass those essentials. Instead, I gave Google many of the most advanced technologies in the world that no Googler could have thought of. Many other PhD students despise Google because Google not only has a lot of messed up technologies of its own, but it packages itself as the most advanced, surpassing other companies and all schools, and arrogantly expects others to "learn" from them.

Only by understanding, respecting and leveraging the special skills that newcomers bring from the outside world and exerting their unique strengths, rather than blindly expecting them to "learn" from themselves, can we maintain the edges of these sharp weapons and make the company invincible.

The workload of programmers cannot be measured in time

Many IT company managers do not know how to estimate the workload of programmers. If you are very capable and solve the most difficult problems in a very short time, they will not let you sit idle, but let you do other low-level work. This is a very unreasonable approach. For example, a capable employee is like an F1 car, with horsepower and speed dozens of times that of others. Of course, problems that ordinary people need a long time to solve, or even cannot be solved at all, are quickly resolved in his hands. This is like an F1 car, which can complete the distance that others need a long time in the blink of an eye. If you use time to measure the workload, then this F1 car only takes a short time to complete the journey, so the workload you calculate is much smaller than that of an ordinary car. Can you say that the F1 car is not working hard enough and ask it to work harder? This is obviously wrong.

The law of physics is this: Energy = Power x Time. The workload should be calculated in the same way. A wise company that truly understands programmers will not expect high-level programmers to work non-stop. High-level programmers can often find new ways to do things, so one can do the work of several or even dozens of ordinary programmers. The problems they deal with are much more difficult than those of ordinary people, and they require much more brainpower. Of course, they need better rest, maintenance, entertainment, etc.

Of course, this does not mean that junior programmers should work too much. Programming is a hard mental activity. Overtime and excessive work plus pressure will only lead to low efficiency and reduced quality.

Don't let others fix your bugs

I have discussed this in a special article. Asking a programmer to fix another programmer's bug is not only inefficient, but also disrespectful of the programmer's personal value. It should be avoided as much as possible. If someone leaves the company and someone must fix the bug he left behind, you should be very careful when speaking. You should point out the special reason why you need his help, emphasize that this matter was not originally his problem and should not have been done by him, but someone left and there was no way, and sincerely apologize for the occurrence of such a thing.

Only in this way will programmers be willing to fix another person's BUG at this rare and special moment.