Programmers are a rather special group. Because they work with computers for long periods, they tend to develop similar personalities and tempers. Of course, since they are human, they naturally have characters and tempers. Now, let me show you ten things that can annoy programmers. On one hand, we can see what programmers have in common; on the other hand, we can also see their shortcomings. Either way, I hope these can be helpful to you in your daily work.

Tenth Place: Code Comments

Code comments are originally a good habit. When experienced programmers mentor newcomers, they always tell them to write code comments. So, of course, newcomers follow the experienced programmers' advice. However, they may misunderstand what code comments are for, and so we often see comments like this in programs:

Whenever you see such comments—commenting only on what, not why—you're sure to be annoyed. Who wrote these comments? You won't feel better unless you find them and give them a piece of your mind. Comments should tell others your intent and thoughts, not explain the syntax of the program. This is for the readability and maintainability of the code. Such comments made for the sake of commenting are not comments at all—they are provocation, and it goes without saying that they will annoy others.

r = n/2;  //r是n的一半
 
 //循环，仅当r- n/r不大于t
 while ((r-n/r) <=t){
     //… …
     r = 0.5 * (r-n/r); // 设置r变量
 }

Ninth Place: Interruptions

Just when a programmer is immersed in thinking about an algorithm or experiencing a sudden inspiration while writing code, being interrupted by others is a very painful thing. If the interruptions continue, it can instantly make someone irritable. The person interrupting is very rude in such a situation. The interrupted person is like a function call—when it returns, they have to restore the context at the point of interruption. Of course, humans are not computers, and restoring context is usually a painful process. In extreme cases, they may need to start from scratch to find their train of thought, then slowly work their way back to the interruption point.

Therefore, I have seen some programmers, when they need quiet without being disturbed, either go to a place where no one can find them, or hang a banner above their desk to warn everyone—"I am currently executing the kernel program, cannot be interrupted, please do not disturb, thank you!" This shows how costly it is for a programmer immersed in work to be interrupted. Naturally, many people are annoyed by being interrupted.

Eighth Place: Requirement Changes

This probably needs no explanation. As long as you are a programmer, you often feel helpless when facing requirement changes. Once or twice might be acceptable, but you can't stand constant changes. It is said that agile development has a methodology that lets programmers enjoy requirement changes—who knows if that's true. But today they ask you to make a desk, tomorrow they ask you to turn the desk into a dining table, the day after into a double bed, the next day into a cabin, and then turn the cabin into a skyscraper. Sigh, anyone would be annoyed. Those people can make any decision in a 30-minute meeting, but the dozens of programmers behind them need to put in hundreds of hours of hard work. If it were me, I might also need some mythical "grass mud horse" to vent my anger.

However, this also shows that programmers don't know how to communicate with users, and users don't know how to communicate with programmers. If a project has no intermediary (such as a PM) to coordinate, then the whole project may be like "a chicken talking to a duck"—both users and programmers will annoy each other. If we were to list a few things that annoy users, the programmer's single-minded, purely technical way of thinking would probably rank in the top five.

Seventh Place: Managers Who Don't Understand Technology

Are there few examples of laymen leading experts? One word from the leader—whether right or wrong—is always right, and we must obey, even if it is the most foolish and mistaken decision. Programmers are not actually afraid of managers who don't understand technology; they are most afraid of managers who don't understand technology but pretend to understand it deeply. The most infuriating thing is when you challenge the leader's authority with sound reasoning, and the leader treats you as an outlier. Sigh, thinking of such a leader, not to mention cursing, the urge to hit them arises.

In fact, a manager is only a supporter of the team; he should help the team and solve its problems, rather than giving orders. Management is really simple: if you understand, help do it; if you don't understand, trust your subordinates and let them do it. The worst thing is a manager who doesn't understand technology and doesn't trust subordinates. Sigh, this is truly a programmer's pain.

Sixth Place: User Documentation

User documentation shouldn't really be so frightening. These documents record all kinds of topics related to the software we develop. Because we don't know what level of computer literacy our users have, when writing such documents, we must assume the user knows nothing. So, we need to write the most comprehensive document in the clearest and most beautiful language. Even a copy-paste operation may need to be broken down into five or six steps; even an IP address configuration operation must be described step by step from the Start menu. For programmers, they use the software they develop almost every day during development, and in the end, they may be sick of it, but they still have to write these documents from the simplest parts. Naturally, this easily irritates them, and having programmers complete such documentation may yield very poor results. Therefore, such user documentation should be completed and maintained by dedicated documentation staff.

Fifth Place: No Documentation

As mentioned in the previous item, programmers don't like writing documentation in the first place, and because technical people generally aren't very good at expression and writing, the documentation they write is also poor. You can probably tell from the documentation in the open source community. However, on the other hand, our dear programmers are most annoyed by the lack of documentation. Of course, the previous one was about user documentation; here we are talking about development documentation, such as design documents, functional specifications, maintenance documents, and so on. But basically, they are all the same. Anyway, on one hand, our programmers don't like writing documentation; on the other hand, our programs get complained about for having no documentation, too little documentation, or documentation that is hard to understand. Heh, it seems recursion exists in complaining too. It is said that agile development can reduce documentation in software development; they say they can write code that looks like documentation and diagrams—who knows if that's true. However, I have heard too many programmers complain about too little documentation or poor documentation. In this regard, programmers only have themselves to blame.

Fourth Place: Deployment Environment

Although programmers develop software, we don't know what environment our program will be deployed or installed in—for example, differences in networks, differences in RAID, differences in BIOS, differences in operating systems (WinXP vs. Win2003), whether antivirus software is present, compatibility with other programs, whether the system has rogue software or viruses, and so on. Of course, as long as your software has an error, whether it's your program's problem or the environment's problem, it's all your problem, and you have to solve it all. Therefore, programmers are not just simply coding; many times they also need to be a decent system administrator. Whenever it is finally confirmed that the cause of the problem is the environment, programmers may feel resentment.

Third Place: Problem Reports

"My software doesn't work," "The program has an error." Whenever we hear problem reports like these, programmers always feel pain, because such reports say nothing at all, yet programmers still have to deal with the error. There is no clear problem description, no explanation of how to reproduce the problem, and it can feel a bit like being interrogated. Even worse, sometimes it comes with a condescending, scolding tone. Of course, programmers are generally strong-willed people who respond to neither carrot nor stick, so whenever someone reports a problem in such a tone, they usually talk back, and then some unpleasantness naturally occurs. So, we still need a customer service department to help bridge communication between our programmers and users.

Second Place: Programmers Themselves

What annoys programmers may still be programmers themselves. Programmers "despise each other." They are basically arrogant and conceited, always feeling that they are the best. Among programmers, they almost argue every day, and once they start, they argue until their faces turn red and their necks thicken. They constantly annoy each other.

• Different technical opinions. For example: Linux vs. Win, VC++ vs. VB, Vi vs. Emacs, Java vs. C++, PHP vs. Ruby, and so on, and so on. They argue about everything.
• Experienced programmers look down on newcomers. There are always some programmers who look down on others, speaking with arrogance and reprimand. When newcomers ask questions, the experienced ones often act indifferent and unresponsive.
• They don't save face for others on technical matters. I don't know why, but programmers never give others face. Whenever they hear someone misunderstand a certain technology, they like to loudly point it out in public, using others' "mistakes" to show off their own "erudition" and prove others' "ignorance."
• They love to despise. In fact, nothing in this world is perfect; there are advantages and disadvantages, and finding faults is too easy. Programmers particularly like to look down on others. No matter what it is, they always prefer to see others' shortcomings rather than strengths. Their common catchphrases are "too poor," "no good," and so on.

Programmers, dealing with computers for a long time, write code that the computer always executes seriously. Over time, they develop a personality of looking down on everything, not realizing that many things in this world are not like a computer, where simply giving the correct instruction makes it run correctly. When will programmers mature...

First Place: A Programmer's Code

No matter how beautiful and classic you thought your design and code were at the time, after a while when you look back, you will inevitably feel that you were foolish. Of course, when you need to maintain someone else's code, you must curse their code while maintaining it. Do you still remember how proudly you discussed your design and code with others and how perfect you claimed it was? Yet within two years, a fresh graduate maintaining your code can point out flaws in it and make you completely lose face. Hehe. Of course, some people always think their own design and code are the best, but that is looking at things from a relatively static perspective. The world of programming changes very quickly. Many things only become familiar to us after we have done them, and only after becoming familiar do we know what better methods are—this is a gradual process. So when you become more and more familiar with things, and you look back at the designs and code you wrote before, you will inevitably feel how shallow and foolish they were. Of course, when looking at other people's designs and code, you may also start cursing.