I once said that programmers are not ordinary people; they possess a kind of superpower. But the problem is that programmers are often unaware of this special ability. In their eyes, they think they are ordinary, just like everyone else. Therefore, what programmers can do, other people—such as their clients/software users—should also be able to do easily. But in fact, because most people—the vast majority (including clients of software development companies and users who purchase software)—are computer novices (people who know very little about computer knowledge/software knowledge). A software operation that is obvious to a programmer, when left to a client to perform, can lead to all kinds of strange things. This makes programmers very miserable.

I remember one time, a client called me and said the big "e" on his computer desktop was missing. I didn't understand—what big "e" was missing? The client explained: it's the icon that looks like a big letter "e" that's missing. I was floored. Finally I realized he meant the IE browser icon on the desktop was gone.

Another time, a client made a request to add a search function to the page. I asked him, "The system already has a search function; why add a new one here?" He said that wasn't the search he wanted; he wanted to search for a keyword on this page. After further communication, I understood that what he wanted was the browser's CTRL+F shortcut function.

Because of these characteristics of clients, the programs that programmers consider perfect become extremely difficult-to-use software in the clients' hands. Complaint calls ring endlessly like a shrew cursing in the countryside. Later analysis found that the root cause is that programmers overestimate users' ability to control the software and underestimate their own ability to create software. As a result, when they watch these clients use the software they developed, it looks like such ridiculous behavior, as shown below:

If a hot-tempered programmer encounters this situation, they will inevitably complain to the client. Moreover, programmers generally are not good-tempered, so when communicating with clients, the project manager usually accompanies them to avoid escalation.

Although clients cause programmers a lot of trouble, in fact all of a programmer's sense of glory comes from clients, because only when clients are satisfied do programmers feel a sense of accomplishment. For example, the expressions on the faces of these clients below when using a new piece of software are enough to make a programmer smile even on a heavy-smog afternoon in Beijing:

Although programmers have bad tempers, they are all thinking about the work and hold no personal grudges. When there is an urgent task in software development, they work overtime without complaint. When a major bug appears in already released software, they deeply blame themselves and rush to produce an emergency bug fix overnight. If they cannot satisfy users at the first opportunity, they lose appetite for tea and food and cannot sleep. Even when there is truly no complete remedy in the short term, they will come up with some unorthodox tricks—but these are effective solutions—to help users get through the difficulty temporarily. For example, below is an emergency fix patch:

Clients should be considerate of programmers. A programmer's life is actually in a very contradictory state. Programming is not like other industries—for example, a bricklayer lays bricks, and each layer makes the wall higher. But programming is different. Sometimes a programmer writes code all day, sweating from anxiety, but development progress may not advance at all, and sometimes even regresses. Software programming is a world that is both virtual and real. Sometimes you can't figure out why a piece of code works, and sometimes you are surprised that software made of such code can actually run, as shown in the picture below:

Finally, let me mention some precautions for dealing with programmers. Because programmers deal with programming logic all day, they are especially sensitive to cause and effect. If the causal relationship in your words is not very clear, it will make them confused; if the causal relationship in your words is incomplete, it will make them do the wrong thing. If there is ...if, it is best to use afterwardthento end, or useelseto give choices. The subject must be clear. If it is not clear, the accident shown in the picture below will occur:

If you are a programmer, you will understand what I say.