Ten things that annoy programmers

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, since it is a person, of course there will be personality, there will also be temper. Next, let's take a look at ten 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:

R = n/2; // r is half of n

// Loop, only when r-n/r is not greater than t
While (r-n/r) <= t ){
... ...
R = 0.5 * (r-n/r); // set the r variable
}

Every time you see such a comment-just comment what it is, without commenting why, I believe you will be angry. Who wrote the program comment? 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 for 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 feel annoyed at once. It is very impolite to interrupt others. The interrupted person is like a function call. When it returns, it needs to restore the site when the breakpoint is restored. Of course, a person is not a computer. It is usually a very painful process to restore the site, 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, you can either put a high bar above your desk to show everyone-"I am executing 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 set of 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 those 10 programmers need to spend several hundred hours of hard work. If it is me, I may also need the animal, grass, and mud 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 of the users we are facing is, 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. Even if we want to copy and paste an operation, we may have to divide it into five or six steps. Even if we want to configure an IP address, we also need to describe it step by 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. 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 document. Here we talk about development documents, such as design documents, functional specifications, maintenance documents, and so on. 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 and too many programmers complain that there are not too few documents, and the documents are too bad. In this regard, it is still strange to blame the programmers themselves.

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 errors, whether it is your program or the environment, it 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, because such a problem report is nothing to say, But programmers need to handle such errors. 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 upon and reprimand, of course, programmers basically have their own personality and are the masters who are not hard to eat. Therefore, when such a tone reports problems, they usually send the words back to the top. Of course, some unpleasant things happened later. 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. This is a step-by-step process. 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.

This article from the CSDN blog, reproduced please indicate the source: http://blog.csdn.net/haoel/archive/2009/04/06/4053048.aspx