Learn how to respect a programmer

ITInternetThis kind of disrespect for people in the company is not only aimed at expert figures, but also against all programmers. It's just that experts have seen a lot of things and are not surprised by them, so they generally don't like to use superficial things to highlight themselves. However, precisely because of their modesty, they become easy targets for attacks by people who have little knowledge. Due to the universality and extremely harmful nature of this disrespectful phenomenon, I feel it is necessary to talk about it specifically. In the following, I would like to point out the origin of the culture of disrespect for people in the IT industry, and at the same time make some suggestions to tell people how to truly respect a programmer. I hope these suggestions can be of reference to the company's management, and I hope they can give some spiritual encouragement to programmers who are experiencing the same pain.

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

Acknowledge the historical legacy of computer systems

If you understand computer science to a certain level, you will Discovered that we are actually still living in the Stone Age of computers. Software systems, in particular, 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,... often trouble us, which is why you need so much so-called "experience". However, many IT companies don't like to admit this. Their usual style is "everything is the programmer's fault!" and "as a programmer, you should know this!" This creates a kind of "emperor's fault" "New Installation Phenomenon": Everyone doesn't like to use tools with poor design, but they are afraid that others will laugh at or doubt their abilities, so no one dares to point out the designer's mistakes.

I am a counter-example of this "hacker culture". Whenever someone asks me for advice because they don't know a certain tool or language, I always laugh at the designer of the tool easily and tell him that you have no reason to know this crap, but that's what it is. Then I told him straight to the point what this thing is, how to use it, and what design flaws lead to our weird usage now... I think all IT practitioners should have such a ridiculing attitude towards these tools. Only in this way will the software industry make substantial progress instead of being plagued by some poor designs and causing mental shackles.

In short, this is a very important "attitude issue". Although at this stage, it is necessary for us to know how to bypass some poorly designed tools and use them to complete our tasks. However, at the same time, we must face up to and acknowledge the bad nature of these tools, rather than treating them as dogma and blaming programmers. Only in this way can we effectively respect the intelligence of programmers.

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

ITThere are often people in IT companies who think they are proficient in some seemingly complex command lines, or some difficult-to-use commands Programming languages ​​are amazing. These people did not realize that some of their colleagues around them actually possess the essence of knowledge. They are fully capable of deriving all these tools from their existing knowledge (not just using them), and even designing them to be more complete, convenient and easy to use. . People who can design and manufacture better tools often have more important tasks, so when they are confused by the usage of existing tools, they will very humbly ask their colleagues to help solve the problem, and boldly admit their confusion.

If you are this person who is proficient in using tools, you must not regard your colleagues’ humble requests as a time to show off your “qualifications”. This colleague is often really "asking questions without shame". It’s not that he “doesn’t understand”, it’s that he simply doesn’t care and has no time to think about such low-level issues. His confusion often comes from the mistakes of tool designers. He is well aware of this, but out of politeness, he often does not directly criticize the design of the tool, but modestly blames himself. Therefore, colleagues "humbly ask for advice" from you are purely to create a friendly and harmonious atmosphere, which can save time to do really important things. This kind of humility does not mean that he is worshiping 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 lame aspects of the tool design. If you can adopt this kind of humble attitude instead of thinking that you are an expert, your colleagues will be happy to "learn" the superficial knowledge they need from you, and remember it to avoid this kind of problem next time. Boring things bother you. If you adopt the attitude of "I am the only one in the world who knows this amazing skill," your colleagues will often despise you and the tool. He will still be unable to remember how to use this thing next time, but he will never come to you for help again, but will put it off again and again.

Don’t use imperative tone, explain your intention

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

Is there any Emacs user who doesn’t know that Ctrl-k deletes a line of text? Moreover, what you are facing now is actually an experienced Emacs user and a world-class Lisp programmer. I think everyone can see the problem here. Such low-level commands are not only unclear in logic, but also offensive. What do you think I am? 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 in the configuration file should be deleted and changed to..."

Similar techniques can be used at other times in project management. Before asking people to do something, you must first explain why you want to do it and its importance, so that people can understand it. Only in this way can we respect the IQ of programmers, because they are human beings, not just code monkeys who only obey your orders.

Don’t expect newcomers to learn from you

Many IT companies like to treat newcomers as beginners and expect them to "learn" from themselves. For example, Google calls all new employees "Noogler" (meaning Newbie Googler), and even sends them a special propeller hat. The meaning is to tell them that children should be humble and pay tribute to the "great people" Google" study, and you will be able to prosper in the future.

This is actually a very wrong approach. It ignores the existing background knowledge of new employees and makes them succumb to the authority of "the great Google" and become an inconspicuous screw. In fact, is there really a lot worth learning in Google? Is school education really worthless? it's not true. I can honestly say that I learned the most essential knowledge from my professors. I did not learn any skills beyond those essences from Google. Instead, I gave Google many of the most advanced technologies in the world that no Googler could have imagined. Many other PhD students despise Google because Google not only has a lot of messed up technologies, but also 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 giving full play to the special skills brought by newcomers from the outside world and using their unique strengths, rather than blindly expecting them to "learn" from ourselves, can we maintain the edges of these sharp weapons and keep the company standing. The place of defeat.

The workload of programmers cannot be measured in time

Many ITcompany management do not know how to estimate the workload of programmers. If you are very capable and solve the most difficult problems in a short period of time, they will not leave you idle, but will ask you to do other low-level tasks. This is a very unreasonable approach. For example, a highly capable employee is like a F1 racing car, with dozens of times the horsepower and speed of others. Of course, problems that would take ordinary people a long time to solve, or even be impossible to solve at all, were quickly resolved in his hands. It's like a F1car that can cover a distance that takes others a long time in the blink of an eye. If you measure workload by time, then it only takes a short time for this F1 car to complete the entire race, so the workload you calculate is much smaller than that of an ordinary car. Can you say that F1racing is not working hard enough and you should ask him to work harder quickly? This is obviously wrong.

The law of physics is this: Energy = Power x Time. Workload should be calculated in the same way. Wise companies that truly understand programmers will not expect high-level programmers to work non-stop. Because high-level programmers can often find new ways, one can be worth several or even dozens of ordinary programmers. The problems they deal with are much more difficult and require much more mental energy than ordinary people. Of course, they need better rest, maintenance, entertainment,...

Of course, this does not mean that junior programmers should overwork. Programming is an arduous mental activity. Overtime and excessive work coupled with pressure will only lead to low efficiency and reduced quality.

Don’t let other people fix their own BUG

I have discussed this in a dedicated article. Letting one programmer fix another programmer's BUG is not only inefficient, but also disrespects the programmer's personal value and should be avoided as much as possible. If someone leaves the company and someone must fix the BUG he left behind, then you should be particularly careful what you say. You should specifically point out the special reason why you need his help, emphasize that this matter is not his problem in the first place, and he should not have done it, but someone has left and there is no other way, and sincerely apologize for such things happening. .

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

Get freeLAMPBrothersOriginalPHPVideo TutorialCD/"Talk about PHP" Essential Edition, details Consult the official website customer service:

http://www.lampbrother.net

PHPCMSSecondary developmenthttp://yun.itxdl.cn/online/phpcms/index.php?u=5

WeChat development                                                                                                              php?u=5

JavascriptCourse

                                                                                                                                 /yun.itxdl.cn/online/cto/index.php?u=5

The above has introduced how to respect a programmer, including aspects of it. I hope it will be helpful to friends who are interested in PHP tutorials.