Humanistic Care for software development

A few years ago, I learned from winberger's "road to technical leadership" that technicians often prefer to deal with machines because they "think" that they are more suitable for dealing with machines. However, excellent technical personnel must (and must) have good communication skills. Therefore, winberger encourages all technical staff to exercise their skills in dealing with others. I strongly agree with this idea from Berger. Good technicians must be "brave" to face others and cannot be limited to the world of machines by self-fulfilling predictions.

However, I also found that the negative effects of "technical personnel (of course I am mainly talking about software developers) are not suitable for dealing with people" are not limited to this, it has also become a stereotype that affects people outside the development team. This problem is actually very serious. It will lead to other people and developers to consciously or unconsciously switch to the "communicate with machines" mode, such as relying solely on emails to avoid communication, for example, "You just need to do this. Don't worry what I do ". Communicate with people in a machine-oriented model. The results are often separated by a complete project (rather than a narrow "software project.

I have been thinking about this situation. The reason is that, on the one hand, the organization is not perfect, and on the other hand, software development lacks humanistic care-software can be inactive, but software development cannot be inactive; programs can be like machines, but programmers cannot. To change this state, we should add more humanistic care (here we need to explain more, "Humanistic" can also be called "human nature ", it has nothing to do with "text", but "Human Nature" is often translated into "humanistic". Developers are treated as living people rather than as programs or tools.

Of course, it is not easy to do this, because many people think that software developers are "boring" (at best, "boring"), which is hard to understand and deal, we can simply treat them as tools, and it is wonderful to avoid talking about difficult processing like "humanization. However, it is not that simple because it is not good at communication and does not mean that developers do not care about humanistic care. On the contrary, most people are willing to accept and accept such care. This topic is worth mentioning because many developers are not good at expressing themselves, so there is not much information to study and discuss humanistic care in software development (or humanistic care that developers really care about.

According to my experience, the following aspects are the concern of software developers, which are often ignored by others. Therefore, to increase the humanistic care of software development, pay more attention to them.

First, the development environment. The "Development Environment" mentioned here is not the IDE, but the software and hardware used by developers. These devices are the only production tool for most developers. Their quality directly determines the production efficiency of developers. Unfortunately, many people do not seem to understand this. Many companies only assign ordinary office computers to developers, so developers can only contribute programs at the level of common office staff. Currently, the hardware has a relatively large memory (8 GB or above) and multiple monitors (preferably one of them can be easily rotated). This is a handy keyboard and mouse (this is very important ), the software should be equipped with lines that provide accessibility to Google and sound open code libraries. To provide these conditions, on the one hand, it can effectively improve work efficiency, and on the other hand, it can greatly improve the working mood of developers. The last point seems insignificant, but shows respect for developers, and its impact is even greater than the previous one.

Second, internal communication. I have seen many developers who don't want to talk to colleagues next to or opposite to each other, but prefer to type on IM, which is very inefficient, what's even worse is that it creates a gap-there is nothing to say during work hours, and there is nothing to say after work hours. To form a cohesive and tacit team, it is always a good wish. Therefore, we must encourage face-to-face communication in our daily work (especially when many people participate in the discussion, we can specially arrange local communication) to gradually form the behavior habits of face-to-face communication. Even if you are bored, many developers do not reject or even desire an active and enthusiastic working atmosphere. I have met a good programmer. Although he is not good at words, he does not like the Technology Department of big companies. He is more willing to stay and talk to everyone, A small team that everyone can talk about. At present, developers in our department often communicate with each other in groups for some issues without affecting others' work. These examples show that for developers, face-to-face conversations are actually very necessary and appropriate communication methods.

Third, work significance. I once said that one of the professional qualities of programmers is their understanding of the business. In reality, there are indeed many programmers who are not familiar with the business, but the programmer's lack of enthusiasm for the business is only one reason. On the other hand, it is also common that the business department is unwilling to let programmers know in detail. When the business departments of many companies need development strength, they neither describe the background of the project nor describe the significance of the project, just a few copies of the document (and many of them are shoddy documents), and the docking is complete. The reason is that sometimes these people regard programmers as simple "coders" and think that they do not need to understand the business, they only need to write code. Sometimes, the programmer's thinking is more rigorous, follow the logic, while many business departments lack such training. If they are not rigorous and meticulous enough to express their ideas and needs, they are more accustomed to the wild path of "One step by one. The former case is attitude disrespect, and the latter case is lack of ability (or laziness ). However, no matter what the situation is, it will have a very bad impact on developers. The final result is that the project is fragmented and everyone is on their own territory. "railway public security, ". In fact, according to my experience, the vast majority of developers do not reject understanding the actual application and significance of the software they develop. Based on this, most people are even interested in proposing improvement solutions, this is actually a very good situation. The premise is that it needs to provide sufficient space and opportunities for programmers to understand the meaning of their work, instead of simply telling them, "You just need to do this. Don't ask me why ".

Fourth, personal growth. "How can I stay in a company ?" One of my predecessors told me that if this person feels that the company has a promising future and he has a promising future, he will stay. I agree with this answer. However, in actual work, the latter "promising" is often ignored. This problem is more serious in software development. On the one hand, developers are often regarded as machines that produce code. Everyone only pays attention to the programs they submit, rather than how they submit the programs. What are the gains in their work? On the other hand, many developers are constantly anxious about the future and cannot solve it. The common result is that the development task is cold and hard-working, and developers also feel that they are doing simple repetitive work, generating a sense of intent or even resistance (I know many people will say, to become a good developer, we should keep improving in simple repetitive work. This is true, but it also requires a proper starting point. In other words, developers should be given the value of excellence and truly appreciate the benefits it brings ). In fact, many developers have plans for their future. For example, some may want to better understand the business and some may want to study the technology in depth. Leaders of technical teams should be able to take time to understand these ideas (if they can give suggestions or give advice) and take care of and focus on new jobs, developers can feel their own growth, feel that their work is promising, and they are more motivated to work.

Many years ago, I read the western humanistic tradition translated by Mr. Dong Leshan. my heart has been deeply branded with "Humanistic" (and thus I know that "Humanistic" actually has nothing to do with "text ). After years of work and thinking, I have determined that software development and other work are not very different. Since other industries can advocate humanistic care and introduce more human factors, this can also be done in software development. Because of the particularity of software development, finding humanistic care recognized by developers may be more difficult, but not impossible and meaningful.