Programmers get annoyed with ten things

Programmers should be 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. Whatever the case, I want them
Daily Work is a help.

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 annotation should be
Tell others about your intentions and ideas, instead of telling others about the syntax of the program. This is for the convenience and maintainability of the program. Such a comment for annotation is clearly not in annotation, it's a provocation.
Of course, there is no doubt.

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 be a bit confusing.
The child gets annoyed. It is very impolite to interrupt others. The interrupted person is like a function call. When it returns, it needs to restore the scene when the breakpoint is restored.
The field 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 bar above their tables to show everyone-"I am executing
Line Kernel Program, cannot be interrupted, please do not harass, 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 methodologies allows programmers to enjoy the changes in needs without knowing whether they are real or false. However, I want you to create a desk today, change your desk to a dining table tomorrow, and change the dining table to a double bed the day after tomorrow.
Change it to a cabin, and then change it 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 build hundreds of small
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, so neat
A 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 the problem is only from the technical implementation.
You can also enter 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. Programmers are not afraid of managers.
Managers who do not understand the technology are the most afraid of being technical-savvy. 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 a leader like this.
Now, everyone has the impulse to fight.
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 don't know what the computer operation foundation we are facing is.
Therefore, 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. I am afraid of a copy and paste operation.
You may need to divide the configuration into five or six steps. If you want to configure an IP address, you must start from the Start menu and describe it step by step. For programmers, they develop almost every day.
They are all using their own software. At the end of the day, they may all get a little spof, 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 a document.
Okay. Therefore, such user documents should be completed and maintained by dedicated persons.

Fifth place
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. Look at the documentation possibilities of the open-source Society
You will know. 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 are talking about development documents, such as design documents and 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 viewed.
Yes. 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, no on BIOS
Different Operating Systems (WINXP and win2003), anti-virus software, compatibility with other programs, and rogue software or viruses in the system. Of course, as long as your software encounters an error, no
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. In many cases, they need to be a good system administrator. Each
When we finally confirm that the cause of the problem is environmental problems, programmers may be angry.

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
The sequencer handles such errors. There is no clear description of the problem, but it does not mean that if the problem is reproduced, The feeling will certainly be a bit of a feeling of being asked by a hostage, or even sometimes it may be a bit of a word of contempt and reprimand.
Gas, of course, programmers are basically very personal, and they are all hard-pressed masters. Therefore, whenever such tone reports problems, they usually send the words back to the top, of course, there will be one in the future.
Some unpleasant things. 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.
• Different 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 do not give the recipient 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 ".
• Contempt for preference. 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
Wait, you must scold others' Code while maintaining it. Do you still remember how to discuss your design and code perfectly with others? However, it takes less than two years.
Students who have graduated from school can point to your code while maintaining your code. Your face is completely blurred. Haha. Of course, some people always think that their design and code are the best,
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 sequential process.
Progressive. 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 looking at the design and code of others
Starting to swear.