Learn how to respect a programmer

: This article mainly introduces how to respect a programmer. if you are interested in the PHP Tutorial, you can refer to it. IT Internet companies do not respect people, not only for experts, but also for all programmers. However, experts usually don't like to highlight themselves with superficial things. However, because of their modesty, they are easy to be attacked by people who know and know each other. I think it is necessary to talk about the universality and dangers of this phenomenon of disrespect for people. In the following sections, I would like to point out that the IT industry does not respect people's cultural origins, and at the same time give some suggestions to tell people how to truly respect a programmer. I hope these suggestions can be used for reference by the company's management, and they also hope to give spiritual encouragement to programmers who are suffering the same pain.

I think a company that understands how to respect programmers should pay attention to the following points at any time:

Recognize historical issues of computer systems

If you understand computer science to a certain extent, you will find that we still live in the computer Stone Age. Especially software systems are built on a pile of poor designs left by history. Various poorly designed operating systems (such as Unix and Linux), programming languages (such as C ++), databases ,...... This is why you need so much experience ". However, many IT companies do not like to admit this. Their style has always been "everything is a programmer's fault !", "As a programmer, you should know this !" This leads to the "Emperor's new installation phenomenon": everyone does not like to use some bad design tools, but is afraid that others may laugh at or doubt their abilities, no one dared to point out the designer's mistakes.

This is a counterexample of hacker culture. Whenever someone asks me for advice on a tool or language, I can easily ridicule the tool designer and tell him that you have no reason to know these things, but in fact it is. Then I told him exactly what was going on, how to use it, and what design flaws led to our current usage ...... I think all IT practitioners should be so ridiculed about these tools. Only in this way can the software industry make substantial progress, rather than being troubled by some bad design, resulting in the shackles of thinking.

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

Distinguish between the essence of knowledge and the surface of knowledge. do not take "experience" too seriously.

IT companies often have such people who think they are proficient in seemingly complex command lines or some difficult programming languages. These people did not find that some of their colleagues have mastered the essence of knowledge. they have the ability to derive all these tools from their existing knowledge (instead of using them ), it is even better designed and easy to use. This kind of person who can design and manufacture better tools often bears more important tasks. Therefore, they are very modest and ask their colleagues to help solve problems when they are confused by the usage of existing tools, boldly admit your confusion.

If you are a tool-savvy person, you should not consider your colleagues' modest requests as being able to show your qualifications. This colleague is often "not ashamed to ask ". He doesn't "don't understand", but does not have time to consider this low-level problem. His confusion often comes from mistakes made by tool designers. He knows this clearly, but for courtesy, he often does not directly criticize the design of this tool, but modestly blame himself. Therefore, my colleagues ask you with an open mind 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 worshipping you and acknowledges that his technical skills are not as good as yours.

Therefore, the correct approach should be to express sincere understanding of this confusion, and frankly admit that the tool design is unreasonable and lame. If you are able to take this kind of modest attitude, rather than the attitude of self-thinking experts, colleagues will happily "learn" what he needs, superficial dead knowledge, and remember it, avoid disturbing you for this kind of chat next time. If you make an attitude that "only I know this is an amazing thing in the world", your colleagues will despise you, along with this tool. He will not be able to remember the usage of this item next time, but he will never come to you for help, but will drag on.

Do not use the command tone to explain your intention

Keep in mind that colleagues and subordinates are not slaves, not code monkey. they do not have to work for you! They are reasonable people, but they will not simply obey your low-level commands because they get their wages. Like my Google teammates, it is a good negative textbook. In fact, this Googler just wants to tell me to "delete this line of text and change it to this ......", However, she did not directly express this "advanced intent", but used a very low-level command: "Press Ctrl-k !......" And the tone is like talking to a nonsensible pupil.

Which Emacs user does not know that Ctrl-k is used to delete a line of words? Besides, you are actually facing a senior Emacs user, a world-class Lisp programmer. I think everyone can see the problem here. Such a low-level command is not only unclear but also objectionable. What do you think of me? Code monkey? If Googler shows her advanced intentions, it will be easily psychologically and logically acceptable. for example, she can say, "this line of configuration file should be deleted, changed ......"

Similar skills can be used in other aspects of project management. Before people do something, they must explain why they want to do it and its importance. Only in this way can we respect the IQ of programmers, because they are human beings, not the code monkey that will only obey your command.

Do not expect new people to learn from themselves

Many IT companies like to treat new people as beginners and expect them to "learn" from themselves ". For example, Google calls all new employees "Noogler" (Newbie Googler) and even sends them a special propeller hat. The implication is to tell them that they should be modest, to learn from the "great Google", we will be able to fly in the future.

This is actually a very wrong practice. it ignores the background knowledge of new employees and gives them the authority of "great Google" to become an inconspicuous screw. Is there actually a lot of things worth learning in Google? Is school education really worthless? This is not the case. I can honestly say that I learned the most essential knowledge from my professors. I have not learned any skills from Google that can surpass those Essence. Instead, I gave Google many of the world's most advanced, any technology that Googler could not think. Many other PhD students despise Google because Google is not only a mess of its own technology, but instead packs itself as the most advanced, surpassing other companies and all schools, and he is arrogant to expect others to "learn" from them ".

Only by understanding, respecting and giving full play to the special skills that new people bring from the outside, and displaying their unique strengths, rather than simply expecting them to "learn" from themselves can they maintain the edges and corners of these sharp weapons, keep the company undefeated.

The workload of programmers cannot be measured by time

The management of many IT companies do not know how to estimate the workload of programmers. If you solve the most difficult problems in a short period of time, they will not let you idle, but will let you do other very low-level jobs. This is unreasonable. For example, a strong employee is like an F1 racing car. the force and speed are dozens of times that of others. Of course, it takes a long time for an ordinary person to solve the problem, or even the problem that cannot be solved at all, and the problem is quickly resolved in his hands. This is like an F1 racing car. it takes a long time for others to finish the race in the twinkling of an eye. If you use time to measure the workload, it only takes a short time to complete the F1 race, so the workload you calculate is much smaller than that of a normal car. Can you say that the F1 racing car is not working hard enough? This is obviously incorrect.

The physical law is as follows: energy = power x time. The workload should also be calculated in the same way. Wise, companies that really understand programmers will not expect high-level programmers to keep working. High-level programmers are often able to find another path, so they can reach several or even dozens of common programmers. They are dealing with a lot of problems than ordinary people, and have a lot of brains. of course they need better rest, maintenance, entertainment ,......

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

Do not let others fix their own bugs

I have discussed this in a special article. To allow a programmer to fix the BUG of another programmer is not only inefficient, but also a practice that does not respect the personal value of the programmer and should be avoided as much as possible. If someone leaves the company and has to fix the bugs left by him, he should be especially careful when talking. In particular, you should point out the special reasons for his help, and emphasize that this is not his problem. he should not have done it, but someone has gone and there is no way to do it, we sincerely apologize for the occurrence of such incidents.

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

Get the LAMP brother's original PHP video tutorial CD/detailed PHP Essentials edition for free. for details, contact the customer service on the official website:

Http://www.lampbrother.net

PHPCMS secondary development http://yun.itxdl.cn/online/phpcms/index.php? U = 5

Develop http://yun.itxdl.cn/online/weixin/index.php? U = 5

Mobile internet server development http://yun.itxdl.cn/online/server/index.php? U = 5

Javascript http://yun.itxdl.cn/online/js/index.php course? U = 5

CTO training camp http://yun.itxdl.cn/online/cto/index.php? U = 5

The above introduces how to respect a programmer, including some content, and hope to help those who are interested in PHP tutorials.