Java programming--How to respect a programmer

Recognize and recognize the remnants of history in a computer system

Many people do not respect the origin of the phenomenon, because some people are paranoid that some technology is the best in the world, everyone must know, otherwise he is not a qualified programmer. This phenomenon is particularly prevalent in the Unix world. The Advocates of UNIX systems (I used to be one of them) like to preach around and tell you how stupid other systems are designed, and you should follow Unix's philosophy. They seem to think that UNIX is the world's ultimate operating system, but the reality is that UNIX is a poorly designed system. It seems deliberately designed to be difficult to learn, easy to make mistakes, but the United States its name is "strong", "flexible." An open-minded programmer knows that UNIX designers do not really understand the design, they are not the best programmers in the world, but one thing is very successful, that is, they will make religion, incite people's obedience mentality. UNIX designers put their own design errors on the user, so that users feel that learning or wrong is their own fault.

If you understand a certain level of computer science, you will find that we are still living in the Stone Age of computers. Software systems, in particular, are built on a pile of historically bad designs. A variety of crappy brain remnants of the operating system (such as Unix,linux), program language (such as C++,javascript,php,go), database, editor, version control tools, ... Often bothers us, which is why you need so many so-called "experience" and "knowledge". However, many IT companies do not like to admit this, they have always been the style is "everything is a programmer's fault!" "As programmers, you should know these!" "This has created a" Emperor's new phenomenon "-people do not like to use some of the design of poor tools, but are afraid of others ridicule or suspicion of their ability, so always like to show themselves" will use "," can learn ", and no one dare say it difficult to use, dare point out the designer's mistakes.

I am this person, is this "xxx culture" a counter-example. The diversity of education I have received has allowed me to jump out of these extreme blindly obedient, dogmatic psychology. Whenever someone doesn't ask me for a tool or language, I always make fun of the designer of the tool and tell him that you have no reason to know it, but that's what it is. Then I sharply tell him what's going on, how to use it, and what design flaws are causing us to use it now ... I think all it practitioners should be such a joke about these tools. Only in this way can the software industry get substantial progress, rather than being plagued by some self-inflicted designs that cause the shackles of thought.

In short, this is a very important "attitude problem". Although at this stage, it is necessary to know how to bypass some crappy tools and use them to accomplish our tasks. At the same time, however, we must face up to and acknowledge the harsh nature of these tools, without being dogmatic and blaming programmers for everything. Only by distinguishing between the mistakes of the tool designers and the mistakes of the programmers, and by blaming the programmers for the design mistakes of the tools, can we effectively respect the IQ of the programmers and encourage them to make simple, elegant and perfect products.

Distinguish the essence of knowledge and superficial knowledge, do not take the experience seriously.

In any field, only a small number of knowledge is the essence, and most of the other is superficial, superficial, is derived from the essence of knowledge. The essence of knowledge and surface knowledge are useful, but their weight and importance are not the same. Therefore, we must distinguish between the essence of knowledge and superficial knowledge, not to confuse, the attitude towards them should be different. Because the surface knowledge is basically dead, and it is easy to derive from the essence knowledge derivation. We should not because we know a lot of superficial knowledge, we think more than the mastery of the essence of knowledge of the people to be stronger. should not because others do not know certain superficial knowledge, think oneself superior.

It companies often have people who think they are proficient in seemingly complex command lines, or that some hard-to-use programming language is great. If they hear you don't know the use of a command, it's like the French don't know Napoleon, and Americans don't know Washington. These people do not find that some of their colleagues have the essence of knowledge, they are fully capable of from their own knowledge, derived from the production of all these tools, and not just use them, even designed to be more perfect and easy to use. People who can design and create better tools tend to have more important tasks, so they tend to be very modest when they are confused by the usage of existing tools, and ask their colleagues to help solve them boldly and admit their confusion.

If you are a tool-savvy person, you must not use your colleague's humble request as a time to show off your "seniority." This colleague is often really in the "fools". He did not understand it, but he had no time to think about the low-level problem. His confusion often stems from the failure of the tool designer. He knows that, and he is aware that his skill level is actually higher than the designer of the tool. However, in order to be polite, he often does not criticize the design of the tool directly, but humbly blames himself. So colleagues to you "humbly consult", is to create a friendly and harmonious atmosphere, so that can save time to do the really important things. This modesty does not mean that he is worshipping you, admitting that his technical ability is inferior to yours.

So the right approach should be to be sincere in the understanding of this confusion, and frankly recognize the design of the tool unreasonable, crappy. If you can take this humble attitude, rather than think of yourself as an expert, colleagues will happily "learn" from you what he needs, superficial knowledge of death, and remember it, and avoid bothering you again for this boring thing next time. If you make a "the world only I know this artifice" attitude, colleagues tend to you, along with this tool to produce contempt of sentiment. He will not remember the use of this thing next time, but he would never come to you for help, but a drag and drag.

Don't be smart, don't judge other people's intelligence and abilities.

In IT companies, there are always a lot of people who think they are smart and want to show that they are smarter than others. This kind of person seems to be judging at any time (judge) Others, whatever you say, serious or joking, will be taken as a basis for evaluating your IQ and ability.

Sometimes you write some code, you know the time is not enough, but there are more important things to do, so plan to improve later. If you are seen by such a person when you submit your code, they will firmly believe that you can only write that code for the rest of your life. This is called "wishful thinking", people can only see what he wants to see. Such people are always hoping that they are smarter than others, so they are always listening to others when they are not as clever as he is, and ignoring others better than him. They can only see when others are negligent, because that is a proof of their superior.

Of course, who would like such a person, but they are quite common in IT companies. You dare not talk to them, especially if you are not joking, because they will use all your silly jokes as evidence of your low IQ or inexperience. You dare not ask them questions, because they will think you ask a question, stating that you do not understand! I found that people with this kind of mentality, the general unconscious of the existence of inferiority. They have some aspects (including intelligence) inferior to others, so they always look for opportunities to appear superior. I haven't come up with an effective way to correct this psychological problem, but as I said in the last section, realizing that the whole industry, including the fathers you admire, does not know a lot of things, it is bread where to eat, is an effective way to relax this psychological.

Sometimes I like to laugh at myself and say to people, "our ancestors in this industry have done so many bugs to get us patched up." Now you have made a piece of excrement, I have also made a piece of excrement, my excrement seems to be more fragrant than your excrement. "In this way, not only show the psychological equality and respect, but also to avoid because of modesty and let the other side of the superior mood." To be honest, doing this does not require a high level of intelligence, so it is best to completely abandon the judgment of human intelligence. You are no wiser than anyone, and you are no more foolish than them.

Explain advanced intent, do not use low-level commands

Keep in mind that colleagues and subordinates are people who are equal to your intellect. They are reasonable people, but they do not simply obey your lower orders. Like my teammates at Google, it's a good example. In fact, this googler just wanted to tell me: "Delete this line of text, and then change to this ..." It is such a simple thing, but she is a trick, not directly tell me this "advanced intent", but the use of very low-level instructions: "Press ctrl-k! ......" Tone like in a not sensible pupils speak, as if they know a lot, others do not know.

Which Emacs user does not know ctrl-k is to delete a line of words, moreover you now face is actually a senior Emacs user. I think we all see the problem here. Such a low-level command is not only logically unclear, but also a serious insult to the intelligence of another person. What do you mean I am? Monkey? If the Googler shows his high-level intentions, it will be easy psychologically and logically acceptable, such as she can say: "This line of configuration files should be deleted, changed to ..."

You also need to be aware of the project management. Before someone can do something, it is important to explain why and why. This will make people understand and respect the IQ of programmers.

Don't expect new students to learn from themselves

Many IT companies like to bring newcomers to the original scholar, expecting them to "start from the new starting line" and "learn" to themselves. For example, Google called the new employee "Noogler" (newbie googler meaning), even to send them a special propeller hat, the implication is to tell them that the child to be modest, to the great Google Learning, in the future can be prosperous.

This is actually a very wrong approach, because it does not respect the background knowledge that new employees have already had, and imposes their position on them. It's not that you say "new starting line" that you can really erase people's past. New people do not understand your code structure and engineering methods, does not mean that your way will be more advanced. Is there really a lot of things in Google that are worth learning? Is school education really worthless? Actually the opposite. I can frankly say, I learned from their professors the most essential knowledge, and from Google, just a few very superficial, rote learning skills can be mastered, and many of them are actually dross. All the innovations I've made at Google are a derivative of the essence of the knowledge that I get from school. Many PhD students despise Google, because Google is not only its own technology mediocre, but rather to packaging themselves into the most advanced, beyond other companies and schools, and arrogant expectations of others to their "learning."

A truly talented company will understand, respect and play the special skills that new people bring from the outside world, and use their unique strengths rather than just expecting them to "learn" from themselves. Only in this way can we keep the edges and corners of these sharp weapons and keep ourselves invincible in the fierce competition. If you blindly let the new people "learn", and ignore their unique strengths, and eventually become mediocre.

Don't be a teacher, distinguish between "learning" and "understanding"

As mentioned above, many of the so-called "knowledge" in the IT industry are merely artifice to circumvent previous design mistakes. So when you meet others don't know something, please don't think you "church" something else, don't think you can be a teacher. To be a teacher, to use some kind of language like "Learn from me" is a kind of condescending, not respect for human behavior.

People like to use the word "learning" when they get the information, but I think the word has been abused. We should distinguish between two situations: "Learning" and "understanding." The former refers to you through the guidance of others and their own understanding, to obtain the essence of the knowledge can not be easily produced. The latter only refers to the fact that you "know" something that you did not know. For example, if someone puts an item in a place you don't know, you can't find it, ask him, and he tells you. The acquisition of this information is obviously not called "learning", and this information is not called "knowledge".

However, many times the IT industry so-called "learning" is similar to this situation. For example, someone wrote some code and designed some framework modules. Someone didn't know how to use it, and then someone told him. Many people refer to this situation as "learning", which is in fact disrespectful to people. This is the same nature as someone told you where he put the stuff. Such code and design, I can also do, even better, why do you say I am learning from you? I just learned a little bit about it.

The so-called learning, must be more advanced knowledge and skills, there must be a "harvest", "have improved" feeling. Simple information acquisition is not called "learning", but is called "understanding". To distinguish between "understanding" and "learning" and not acting as a teacher is an important expression of respect for people.

Clarify your own requirements, don't use the tone of accusation

Some people are weird, he never told you what he wants, there are special requirements, but he subconsciously assumes that you have been told. Later, he found that your practice did not meet the requirements, and then severely accused you did not follow his "desire" to do business. This phenomenon is not confined to programmers, but includes ordinary people in everyday life. For example, my mother is typical of this kind of person, so I used to live at home often very hard. She has a "right" way of doing things, and if you don't guess you'll be scolded. You don't do anything to avoid being scolded, and then she says you're lazy, so you're not human:)

It companies also have a lot of such people, they assume that some information he has told you, and actually did not tell you. By then, they began to accuse you of not doing what was required. Some of the most wonderful companies, the programmers not only like to be a teacher, and they "teach" your "knowledge" the main way is to blame. They don't tell you any rules beforehand, and then blame you only when you violate them. I've been in a company like this before, and I don't mention the name.

Now give a concrete example of the scenario:

A: Did you push to master?

B: Yes? What's wrong?

A: no push to master! Only pull request! can be used

B: But you didn't tell me before ...

A: Now you know?!

Have you noticed? This is not a technical problem, but a ritual (etiquette) problem. You shouldn't talk to people in a tone of blame without telling others beforehand, and your rules aren't always right. So I now remind you that some of the technical requirements of the IT company must be presented in advance to ensure that programmers know and understand. If not, do not blame others for not doing as required, because it is very hurtful to people's self-esteem practices. In fact, at any time should not use the tone of accusation, it not only to solve the problem has no positive effect, and will worsen interpersonal relationships, and ultimately lead to more serious consequences.

Programmer's workload not available time measurement

Many IT company management do not know how to estimate the workload of programmers, so they are sitting in their own position to work time to estimate. If you have a strong ability to solve the most difficult problems in a short time, then they will not let you idle, but will let you do other very low-level work. This is a very unreasonable approach. For example, a highly capable employee is like a F1 car, with dozens of times times the horsepower and speed of the other person. Of course, it takes a long time for the average person to solve, or even to solve, a problem that is quickly dissolved in his hand. It's like a F1 car, and in a blink of an eye, it takes a long time for someone else to get away. If you take the time to measure the workload, it will take a short time for the car to run, so you can work out a lot less than a regular car. Can you say that the car is not working hard enough to get him to whip the horses? This is obviously wrong.

The law of physics is this: energy = power x time. The workload should also be the same calculation method. A wise, real understanding of the programmer's company will not expect high-level programmers to keep working. A high-level programmer can reach several or even dozens of ordinary programmers because they can often find a better alternative. They deal with problems more difficult than ordinary people, the cost of a lot of brain, of course, they need better rest, maintenance, entertainment, ... If you let the high-level programmers too busy, a moment of endless, interesting and challenging things to do to let them do some low-level boring things, they realize this truth, will deliberately slow down, sometimes obviously finished soon will also say not finished. Instead of just expecting them to work a little shorter, it's time to get things done.

Of course, this is not to say that novice programmers should work too much. Programming is a hard mental activity, overtime work plus pressure, will only bring low efficiency, lower quality.

Don't let others fix their bugs

I have already discussed this in a special article. Having a programmer patch up another programmer's bug is not only inefficient, but also a practice that does not respect the individual value of the programmer and should be avoided as much as possible.

In the software industry, it is common to see some company management that allows one person to fix bugs in another person's code. Sometimes someone writes a piece of code, throws it away, and then the company manages to let other engineers fix it. I want to tell you that this approach will fail.

First, having one person fix another person's bug is not respecting the performance of the engineer's personal skills. Over time, engineers are less motivated to lose valuable employees. Code is written by the heart of the work, like the artist's work, its quality is concerned about a person's personality and dignity. If a person a write code, they do not want to fix the bug inside, it means that a himself think his own code is garbage, hopeless. If you let another person B fix the bug in the a code, it's the equivalent of letting B pick up the trash that someone else left behind. It is conceivable that B in the company's eyes is what kind of status, received what kind of respect.

Second, it is inefficient to have a person fix another person's bug. Everyone has their own style and skill of writing code, and the code contains a person's way of thinking. It is difficult to understand other people's thoughts without explanation, so it is difficult to understand the two people's programming skills. Cannot understand the code of others, does not explain any aspect of this person's programming technology. So let one person fix another person's bug, no matter how clever this person's technology, will lead to inefficiency. Sometimes the higher the technology, the less efficient the bug fixes, because the person could not write such a bad code, so he could not understand, feel better to overturn rewrite again.

When I was working as a program assistant at the university, I found that if the student's code was out of the question, you couldn't simply fix it. My level is obviously much higher than the student's, but I often do not understand at all, do not want to see their code, not to mention the fix inside the bug. As mentioned above, some people do not even know what they are writing, and make a lot of rubbish. Look at this kind of code like eating crap. For this kind of code, you can only tell them that this is not true. As to why they are not correct, you can only let them change themselves, or suggest that they overturn the rewrite. Perhaps you can point out the general directions and ideas, but it is impossible to go deep into specific details, and it should not be your responsibility. This is what my professor told me: if the code does not run, just hit a fork, no explanation, no elaboration, and so on they have to change the program, or there is no way to office hours to find you, to explain their thoughts to you.

If you understand what I'm talking about, take responsibility for your code from now on, and don't let anyone else fix their bugs or fix them. If someone leaves the company, someone has to fix the bug that he left behind, so talk should be especially careful. You have to point out the special reasons for his help, stressing that it was not his fault, that he should not have done it, but that someone had gone, there was no way, and sincerely apologized for the occurrence of such a thing. Only in this way can the programmer willingly fix another person's bug at this special juncture.

Don't yell at people to write tests.

In the brains of many programmers, the so-called "process" and "test" are more important than the code that really solves the problem. They talk to you about these, it is really called serious, righteous words Ah! So sometimes you're confused, and these people know nothing but to follow these rules. People who may not have the ability to pursue all kinds of rules, so that they can appear to "Lau". These people write their own code is very mediocre, do not know how to solve difficult problems easily and effectively, but like when others submitted the code to let him review: "The test is very important!" Coverage is important! You need some more tests to get through my review!. "

The code review was meant to help them find possible problems, and some people seemed to use it as a chance to judge (judge) other people's abilities, experiences, and even IQ. They do not understand the real value of other people's code, they know that some superficial phenomenon to judge. I internship in Google, and finally submitted a very high quality and difficult code, but some completely incapable of writing such code, not only did not show the most basic affirmation, instead of a dull roar: "Fast-write-test-test!" "Do you think I'll be happy?"

I do not deny the usefulness of testing, but when many people mention these things, the tone and attitude are very disrespectful and offensive. Not only did these people not make any tangible contribution to the problem, but when someone submitted a solution, they did not express respect and affirmation for the person who really contributed, instead blaming others for not writing the test. It seems that the person who is better than him solves the problem, he is the one who has the say, can judge your code quality like: "I control your code to write much good, I have no ability to write, but you do not write test is not professional." You do not understand the importance of testing Ah, but also to do the programmer! "

The problem of interpersonal communication is often not in what you say, but in what you say. So I'm not saying that you shouldn't suggest writing tests, but the advice should have a suggested tone and attitude. Because you did not do the actual work, so some polite language, such as "Please", "can" ... is a must. Often some people do not pay attention to the tone and attitude, people are disgusted, but they are engineers, not good at talking to people as an excuse. Always remember, you do not do things, talk should be tactful, must not use the bare imperative, said as if the other people must do, do not do is not understand the rules.

A polite language has absolutely nothing to do with a person's profession. Being an engineer is no excuse for not being polite.

About the etiquette of git

Git is now the most popular code versioning tool. In layman's terms, git is a "repository" or "custodian" of code, so that many people change the code to know who changed it. In fact, no matter what tools, whether it is the editor, programming language, or version control tools, compared to the core of the programmer's ideas, are secondary things, are playing an auxiliary role. But the Git tool seems particularly annoying.

Git is not as good as many people boast, and there are obviously crappy designs. With the traditional UNIX same strain, Git does not have a good packaging, the designer of their own internal implementation of the details of the relentless disclosure to the user, so that users need to figure out how the designer inside the end, or many times do not know how to do. Users are forced to remember a lot of wacky commands, and the command line design is not very reasonable, and sometimes you need to add-f parameters, the location of the parameters may not be consistent, but also does not necessarily play the desired effect. All sorts of strange phenomena, such as "head detached", force the user to understand how it is designed internally. As the git version updates, new features and commands continue to grow, and then you finally see that foreach appears in the command line, only to find that its command line is fast becoming a (bad) programming language. If you understand Ydiff design ideas, you will find Git and other text-based version control tools, in fact, belong to ancient things. However, many people make git sacred because it is designed by Linus Torvalds.

The most annoying part of git is not the trouble it uses, but the psychological shadow that its "senior users" have to give you a commanding attitude. Many people think that superior is a professional attitude because they are "proficient in git". As users increase, the initial design of Git is becoming more and more useless, so some of the rules seem more and more and can be written in a book! With Unix's traditional same strain, Git gives you a lot of "mechanics" that you can hold on to, and then you don't know what's wrong. So you often listen to someone say: "Not git allows you to do this, you can do it!" The philosophy of UNIX is not to stop stupid people from doing stupid things ... " If you do not know some of the rules of GIT users when you submit your code, someone will yell: "Rebase again!" "Don't push to master!. "Don't merge!. "" Squash commits! "If you don't use git submodule and stuff like that, someone might despise you and say," You should know that! "

For example, this kind of shouting to people's feeling is that after you have won the Olympic gold medal, the practice of equipment back to the equipment storage section, the result of the administrator yelled at you: This put this way! Put that over there! You don't know the rules, do you? "Did you see the problem?" The programmer submitted a high-value code (the Olympic gold Medal), and the result was snapped by some of the people who thought git was very familiar (the equipment keeper).

A company culture that respects the programmer, should put the programmer as the athlete, put the programmer's code in the Honorable position. Other tools should be the same as the equipment storage section. We respect these equipment custodians, but if the athletes do not understand the equipment you set up the rules, you should also show respect and understanding, talk should be polite, should not ride on their heads. So, for some of the commands and usages of git, I suggest that when you introduce yourself to newbies, it starts with this: "You shouldn't have known that, but now we don't have any better tools, so we have to do this ..."

Write at the end: Welcome message discussion, add attention, continue to update!

Java programming--How to respect a programmer