10 things that make programmers angry

Programmers are a special group. They have a similar character and temper because they have been dealing with computers for a long time. Of course, it is a person, of course there will be personality, there will also be temper. Next, let's take a look at 10 things that can make the program messy. On the one hand, we can look at the common characteristics of programmers, and on the other hand, we can also look at the shortcomings of programmers. In any case, I hope they will be helpful to your daily work.

Tenth program Annotation

Program annotation is a good habit. When a programmer is a novice, he always tells the novice that he must write a program annotation. As a result, newbies will certainly follow the instructions of veterans. However, they may have some misunderstandings about program comments, so we often see the following comments in the program:

Every time you see such a comment-just comment what it is, without commenting on why, I believe you will be furious. Who wrote this program to explain it? If you don't find it, you don't seem to be able to get rid of it. Program comments should be to tell others about your intentions and ideas, rather than to tell others about the program syntax. This is for the convenience and maintainability of the program. Such comments are annotated for the sake of annotation, obviously, it is not in comments, but in provocation. Of course, there is no doubt that it will provoke others.

Ninth interrupt

When the program is immersed in the thinking of programming algorithms, or the inspiration is suddenly writing the program, but it is interrupted by others, it is a very painful thing. If it is interrupted, it may make people get annoyed. It is very impolite to interrupt others. The interrupted person is like a function call. When a person returns a breakpoint, he or she needs to restore the site. Of course, a person is not a computer. Restoring the current scene is usually a very painful process, in extreme cases, you may need to start thinking from the beginning and then return to the breakpoint.

Therefore, when some programmers need to be quiet and not be disturbed, they will either choose a place that nobody can find, or they will put a high frame above their desks to show everyone-"I am running the kernel program and cannot be interrupted. Please do not harass me. Thank you! ", What is the overhead of programs that may be immersed in work being interrupted. Naturally, there are not a few people who are disturbed by the interruption.

Eighth requirement change

I don't need to say much about this. As long as it is a programmer, it may always be helpless in the face of changes in demand. You may have to accept it once or twice, but it cannot be changed frequently. It is said that there is a methodology in Agile development that allows programmers to enjoy the changes in needs without knowing whether it is true or false. However, let you create a desk today, change the desk to a dining table tomorrow, change the dining table to a double bed the day after tomorrow, and change the bed to a cabin the day after tomorrow, then change the cabin to a tall building. Ah, people will be provoked. Those people can make any decision at a 30-minute meeting, but the dozens of programmers who need to work hard on hundreds of hours later. If it is me, I may also need the animal's grass mud/horse to help solve the problem.

However, this also shows that programmers do not know how to communicate with users, and users do not know how to communicate with programmers. If a project does not have a man in the middle (such as PM, the whole project may be "talking to the duck", and both the user and the programmer will be provoked by the other party. If you want to cite a few cases where users are being provoked, it is estimated that the programmer's approach to thinking about problems only from technical implementation can also be ranked among the top five.

The seventh manager is not technical

Are there still few examples of external leaders? A sentence from a leader is right, no matter whether we are right or not. We must do what we do. Even if we are so stupid and wrong, we have to do what we do. In fact, programmers are not afraid that managers do not understand technology. The biggest fear is that managers who do not understand technology are very knowledgeable. The most annoying thing is that when you choose to stand for the authority of your leadership, the leadership also regards you as a different type. Ah, think of such a leader, don't say it's a curse, and the impulse to beat people is there.

In fact, a manager is only a supporter of a team. He should help the team to solve problems for the team. Instead of issuing orders to the team. In fact, management is really simple. If you understand it, you can help. If you don't understand it, you can trust your subordinates and let them do it. The biggest fear is that they do not understand the technology and do not trust their subordinate managers. Ah, this is really a programmer's pain.

Sixth user document

User documents should not be so scary. These documents record all the topics related to the software we developed. Because we do not know what the computer operation foundation we are facing is like, when writing such a document, we must assume that this user does not understand anything. Therefore, you need to write the next rich document in the clearest and most beautiful language. We may have to divide the copy and paste operations into five or six steps. We also need to describe one step from the Start Menu. For programmers, they are using their own software almost every day during the development process. At the end of the process, they may be a bit spam, but they have to write these documents from the simplest part, of course, it is easy for them to get bored. It may be very difficult for programmers to complete such documents.
Okay. Therefore, such user documents should be completed and maintained by specialized document personnel.

Fifth, no documentation

As mentioned in the previous article, programmers do not like to write documents, but because the technical staff's expression and writing skills are generally not very good, the writing of documents is also very bad. You may find out the documentation of the open-source community. On the other hand, our lovely programmer is most angry because there is no document. Of course, let's talk about the user's documents. Here we talk about development documents, such as design documents, functional specifications, and maintenance documents. However, they are basically the same. Anyway, on the one hand, our programmers do not like to write documents, on the other hand, our programs will be complained that there are no documents, there are too few documents, or the documents cannot be understood. Haha. It turned out to be recursive in terms of complaints. It is said that agile development can reduce the document in program development. It is said that they can write the code like a document and a diagram, and they do not know whether it is true or false. However, I have heard
Too many programmers complain that there are too few documents, and the documents are too bad. It is strange to blame the programmers themselves for this.

Fourth deployment Environment

Although programmers develop software, we do not know the environment in which our programs will be deployed or installed. For example, the network and raid are different, different bios, operating systems (WINXP and win2003), anti-virus software, compatibility with other programs, rogue software or viruses in the system, and so on. Of course, as long as your software encounters an error, whether it is a problem with your program or an environment is your problem, and you have to solve it all. Therefore, programmers are not simply programming, and often have to be a good system administrator. When the final cause of the problem is environmental problems, programmers may feel resentful.

Third-party issue report

"My software is no longer working" and "my program is wrong." Every time we hear such a report, programmers always feel very painful, this is because such a problem report is nothing to say, but it also needs a programmer to handle this error. There is no clear description of the problem, and there is no explanation of how to reproduce the problem. In terms of feeling, it will certainly seem a bit of a feeling of being asked by a hostage, or even sometimes it may look down, reprimand, of course, programmers are very personal, and they are hard-to-eat masters. Therefore, whenever such tone reports problems, they usually give back their words. Of course, some unpleasant things happen in the future. Therefore, we still need a customer service department to help our programmers communicate with users well.

Second programmer himself

Mao programmers may be programmers themselves. Programmers are "light". They are basically arrogant and always feel that they are the best, they have to quarrel almost every day, and they have to blush and have a rough neck. Between them, they are always provoked by themselves.

Technical insights. Such as Linux and win, VC ++ and VB, VI and emacus, Java and C ++, PHP and Ruby, etc. Make a noise.

Veterans despise new users. There are always some programmers who look down on other programmers and speak with an arrogant and reprimand. When a newbie asks a question, the veteran will always ignore it.

Technically, the recipient is not given a face. I don't know why, programmers always don't give faces to each other. Whenever they hear people mistakenly understand a technology, they always like to speak out in public, use others' "mistakes" to show their "erdition" and prove others' "Ignorance ".

Dislike. They prefer to despise it. In fact, nothing in this world is perfect. If it is good, it is too easy to pick up the problem. Programmers especially like to despise others. No matter what they are, they always like to look at short people rather than long people. The mantra that often hangs on their lips is "too bad", "no", and so on.

Programmers, who have been dealing with computers for a long time, write code, and run the computer seriously. For a long time, programmers have developed an empty character, but they do not know, A lot of things in this world are not as simple as computers, as long as we enter the correct instructions, it runs correctly. When can programmers become mature ......

Code of the first programmer

No matter how beautiful and classic you think your design and written code are, after a while, you will surely feel stupid. Of course, when you need to maintain others' code, you must scold others' Code while maintaining it. Do you still remember how to discuss your design and code perfectly with others? However, in less than two years, a student who just graduated from a school can point to your code while maintaining your code, so that your face will be completely blurred. Haha. Of course, some people always think that their design and code are the best, but this is a relatively static view of the problem. The world of programming is always changing fast. Many things, we only get familiar with it when we have done it. After we get familiar with it, we know what a better method is.
In ascending order. So when you get familiar with things and look back at your previous design and code, you will surely feel superficial and stupid, of course, when you look at others' designs and codes, you may start to swear.

Original article: http://blog.csdn.net/haoel/article/details/4053048