Is it true that programmers only care about one acre of land)

In fact, I have been talking about this sentence for a long time and have contact with many colleagues. Sometimes, more or less people may find that they are stuck in their own three-acre land.

Main symptoms

1. The requirement of Pd is the goal. If you do not understand it, you can guess it.

2. Experience overwrites everything. Designing a system must be complete and complex.

From the developer's perspective, most people have their own ideas, a lot of work experience, and may be fascinated by technology. The other type of person is mostly just working or having insufficient experience, or is habitually taking work as a task, not a hobby, writingProgramThat is, a profitable job. However, it seems that they are all playing tricks on their own one acre of land, and they forget the most basic principle as a developer: "meeting customer needs ".

Let's Talk About Type 1 first. We have a team member who has just graduated for more than a year and is very diligent. No matter from study and work, they are real and steadfast. We come to the demand side. Generally, we will go through all the big demands. If there are some small demands, he will just think about them. The system was about to go online that day. After talking about the Design Modification, we found that not only could not meet the original requirements of PD, but also brought about the risk of a sharp increase in cache. Then let's talk about pd. In fact, the functions he wants have already been implemented in the existing system, but only some modifications are required, rather than a new mechanism. In fact, this situation has appeared many times before and after, but it has not been discussed with him. Later, when I went home with him after work, I said, "Many times, PD wants to describe a requirement from the development perspective for your understanding, but he eventually lost what he wanted. Therefore, the first step for you is not to rush to consider how to implement the idea of Pd or argue with him about whether his design is reasonable, but to ask him first: What do you want, what is the ultimate goal of what we want to achieve, and what needs can we meet? When he can clearly understand what he wants and what value he wants to bring to the customer, let's look back at what he should do ?" This is actually the same as every time I share some design steps with my classmates. First of all, why do I need to do this? Then I want to consider how to find action methods from my goals, otherwise, you will find that the things you have discussed with others for a long time have deviated from your goal. Therefore, when doing any requirement or design, the first question is to ask yourself why to do it. Remember what my goal is in the process. This reminds me of talking to Dr. Wang Jian and listening to some of his design concepts when I was away from Asoft. In many cases, the scale is not enough, first, solve the customer's needs. After solving the customer's needs, gradually consider the design of large-scale problems. (Of course, it doesn't mean that the first version can be designed at will, and a good foundation can speed up subsequent improvements ).

there are a lot of Types 2, which is actually a common problem for many developers, including sometimes I will also fall into such a misunderstanding. In general, there are two scenarios that will fall into such a misunderstanding, while the parties are unwilling to change. In the first case, I felt that I had a lot of experience, and I was very persistent in the technology. I hoped that the design would be perfect, and a single release would be able to meet the needs of one or two years, but in fact, from the perspective of design over the years, the system is constantly iterated and evolved, therefore, the one-step statement is basically unreliable (unless it is used repeatedly in the same scenario Code ). Secondly, the system architecture should be flexible enough, in general, we need to first make core functions and reserve enough space and entry points to adapt to future expansion and demand changes. From these two points, in fact, the initial design stage is to find what the customer wants most. expansion can achieve what the customer may want and prevent the customer from failing to estimate. But in fact, we need to have full communication with our product designers. Good product designers won't tell you how to implement it, but they will tell you what I want, what can this bring to the customer? In this case, you can tell him how I can meet your needs. The result of such development and product design exchanges is a technical product. Everyone performs their respective duties and is familiar with the situations in the other field. They can only give suggestions to the other field, not guidance, I am glad to have a very good classmate, and our communication is like this. This is a little far-fetched. I just talked about the first scenario, and then talked about the second scenario, that is, in the early stage, we didn't know the details, however, during the implementation process, developers will choose some technical and architectural designs based on their own contact surface. In the end, they will look very complicated and perfect, however, the more complicated the design, the more hidden risks are. But at this time, because it has been designed, I am not willing to simplify it or listen to anyone's opinions. In fact, this is very dangerous. I have made similar mistakes in the past, but when you calm down and think about the sentence, what is our goal: to meet the customer's needs, will such a complicated system bring more instability and complexity to the customer? In fact, the customer does not care about how you implement the system, but you need to meet the most basic requirements of the customer and make it easy to use, it is efficient and provides a solution to the problem.

This afternoon, I interviewed an external student who had a longer working life than me. After reading my resume, I also went through many projects. At the same time, I wrote a description of high concurrency, distributed and so on are very familiar and enthusiastic. I started to read my resume and worried. Maybe I don't need him here, because I am afraid that he will talk about how to make highly concurrent and distributed content. In my opinion, if you haven't figured out when you want to use a knife, or when you want to use scissors, it's meaningless to talk to you about the structure of a knife, because in my opinion, as long as you are willing to take the time to learn the technology, there is nothing you can't learn, but the work style and project design experience have accumulated for a long time. Fortunately, I spoke to him today about his attitude towards technology and architecture design, which is close to what I thought. It is not for technology but for the process, learn how to simplify and simplify, and then find your own goals. Of course, I talked about a lot of technical details later. After all, it is still a good job to work, and it is terrible if I have no experience or technical accumulation for so many years. Finally, I asked him two questions: 1. What is the process of learning a new technology? 2. If there is a conflict between you and your colleagues in the design scheme, how can you solve it? He told me that he would first consider the characteristics of the technology, the difference between it and other technologies, and what fields he is good at, so that he could use the technology. On the second question, he told me that it was a meeting and discussion, and finally everyone decided. I am very satisfied with his first question, because I need such a colleague. I gave him a suggestion on the second question. In fact, many times, by incorporating the advantages of others' architecture designs into their own designs, and no longer using solutions as boundaries, it is easy for everyone to reach an agreement, because when you accept others' ideas, you can see your own shortcomings and treat others without a negative attitude, which makes it easier for you to recognize and accept them. (In this case, we need to constantly change the strong personality of programmers. At least I am still in the process of change ...)

I remember when I was a child in a political course, my teacher divided us into three types of people: competent people without morality are dangerous people, incapable but ethical people are harmless to society (think that the socially harmless turtle concept, as Ge said ), people who have both the ability and morality are useful to society. I think programmers can also look at the following two dimensions:

1. ability, experience, and pursuit of technology.

2. There is no sense of productization and customers.

Having quality 1 but no quality 2, we can only say that it is the flower of the laboratory at most. It is good to conduct research at the university. Actually, it is possible to make products on paper, so good steel will never be able to use the cutting edge, it is powerful.

Quality 1 is lacking, quality 2 is clear, and you are constantly pursuing your own goals. In fact, sometimes stupid birds fly higher than smart birds.

People with 1 or 2 are of course the best people. You only need to learn to be human and then you can exert your energy. (Sometimes it is difficult for programmers to change their personality and learn how to communicate and understand)
The last category is people who think they have 1 and 2. These people are most afraid of being passed by the examiner during the interview, so the subsequent problems will increase.

After talking about a lot of things, I just want to talk about the experiences of a programmer over the years, from development to basic platform, to business platform. How can I do things practically, when to find your own bottlenecks and when to change your status, you need to calm yourself down and think about it. To build a basic platform, you must be able to withstand loneliness and know that you have customers who are not good at service. Then, the basic component platform is a toy. To build a business platform, you must learn how to analyze and communicate with each other. You must also understand how to collaborate at each level of design and meet the implicit requirements (stability, availability, response speed, scale ). But in the final analysis, what gives developers continuous energy is not the technology itself, but the value that you bring to your customers by using technology. Your recognition is the most basic motivation for long-term work, because when you think that pure technology can help you keep moving forward, you will realize that the process and goal are equally important in the near future. If you leave your land on an acre of land and give yourself more space, you will be able to see it farther and go higher.