The introduction

Eight years ago, my first internship was as a C++ engineer in the wireless search department of an Internet company. At that time, I was high spirited and wanted to do a great job. As a result, I wrote the first Casestudy in my life when I first went online. Due to my ignorance of the deployment environment, I mistakenly sent the configuration file from the SVN database to the online server. After I finished the online service, I went to have dinner. When I came back from the dinner, I found that the master was struggling to roll back the configuration. That outage knocked out a core service for 20 minutes, affecting millions of users. That was just the beginning, but over the next six months, I ran through every mistake a new employee could make. The architect asked me to investigate a capture performance improvement solution, and I worked on it for two weeks without reaching any conclusions. Originally arranged the development plan, because I have to go back to write a paper, make the manager unprepared; Participate in the project symposium, the whole “soy sauce”…… At that time, I was also very distressed, almost every night after 11 o ‘clock, very tired and hard, but still can not get the desired results.

Eight years later, I have gradually grown into a technical Leader from a small white office. I found that many of the students in my team kept repeating the same mistakes they made in their own years. It’s not that they’re not trying. What went wrong? After some time of observation and reflection, I think I found the answer. That is: most of our students lack the guidance of principles in their work. Principles are beacons that guide our actions. They connect our values with our actions. Not long ago, Ray Dario, founder of Bridgewater Foundation, set off an explosion in his book principles. Everyone should have their own principles, when we need to make a choice, must adhere to the principle of the center. But in real life, we often lack the summary of the principle, for many people this is a “can only be understood but not spoken” metaphysics, is a secret belonging to the old driver, in fact, it is not.

“Pursuit of excellence” is the value of Meituan. As a technician, how should we practice it? This article summarizes ten principles of improvement, hoping to give you some inspiration, better guide our actions.

Principle 1: Owner consciousness

“Owner consciousness” is mainly reflected in two aspects: one is a serious and responsible attitude, the other is a proactive spirit.

Conscientiousness is the bottom line of work. First, take responsibility for the results we deliver. Every design document, every line of code in a project needs to be carefully completed and be responsible for its quality. If the design document logic is confused, the code is uncommented, and a bunch of bugs are found during testing, it will not only affect the engineering delivery quality of RD, but also have a bad impact on RD, QA, PM, etc. working together. Over time, the overall quality of the team’s delivery and work efficiency will gradually decline, and even lead to a sense of distrust among team members. Second, we are responsible for the system we develop. Whether the architecture of the system needs to be improved, whether the interface document is perfect, whether the log is complete, whether the database needs to be expanded, whether the cache space is enough, and so on, these are things that need to be implemented. As the Owner of the system, please perform it carefully.

Being proactive is a higher requirement of “Owner awareness”. RD faces a lot of work every day, many of which are not planned, which requires a proactive spirit. For example, we may face a large number of technical consultations every day. If the questions raised by customers are not answered for a long time, it will bring bad customer experience. Many students said that they were too busy to deal with their own work, some students think this matter is not very important, but many students did see, but do not know how to answer, or even see, simply pretend not to see. All these are the reflection of lack of Owner consciousness. The right way is to actively promote the solution of the problem, if the time cannot be arranged or do not know how to solve the problem, you can directly feedback to the students who can solve the problem. There are many more ways to be proactive. For example, many students will spontaneously comb the status quo of the responsible service, put forward improvement suggestions according to the performance problems of the interface and continuously promote the solution. Some students also take the initiative to assume the role of main R in cross-team communication, actively discover and expose problems, promote the progress of the cooperative team, and ensure the smooth progress of the project. All of these students are the backbone of the team. Therefore, while doing our own work, we should also actively put into the “work”. No pains, no gains. Don’t set limits on yourself. Try to become a better person.

Principle two: the concept of time

I believe everyone has a sense of time, but really can be implemented in place may not be so many. The Internet is a rapidly developing industry, RD research and development efficiency is an important embodiment of a company’s hard power. Project delivery on time is a very important execution ability, which to a large extent determines the evaluation of the leadership and colleagues of their own reliability. You may ask: why do some students often Delay projects of almost the same difficulty, while others can go online on time every time? An important reason for this is that these on-time deliverers tend to have two characteristics: a plan and prioritization.

Work arrangements should be planned. Generally, RD can estimate the exact development time after the design review, and then arrange the development, alignment, and test plan reasonably. If you are in charge of a project, you will be involved in coordinating the work of FE, QA, PM and other students. Anticipation is the key, unpreparedness is the key. During the planning process, try to break down each item as small as possible (at least to PD size). As it turns out, the finer the granularity, the more accurate the plan, and the smaller the margin of error between the actual development time and the plan. In addition, it is important to define clearly verifiable outputs and set key time points in the plan for verification. There are countless gory facts that tell us that many project delays are caused by disagreements over key delivery points. For example, the interface document of background RD is planned to be provided on Friday, FE thinks it is Friday morning, while RD thinks it is submitted before the end of work on Friday, which will bring an error of 1PD to the schedule virtually. Therefore, we need to make the plan granular enough that key time points can be checked.

Prioritize your work. We have to face a lot of things every day, to learn to distinguish the priority of these jobs. Try the Eisenhower rule, which divides work into four quadrants of importance and urgency. Prioritize important and urgent things; Important and not urgent things can be postponed, but continue to push; Urgent and unimportant things can be delegated to the most appropriate person to do; Consider not doing things that are not important or urgent. Many projects fail to be delivered on time because of confusion among executives. For example, if you need to use ES in development, some students who are not familiar with ES may want to systematically learn this knowledge, and they will jump into the sea of ES. It turned out that what should have been a day’s work was being severely delayed. In practice, we should avoid putting the cart before the horse. In this case, “systematically learning ES” is an important but not urgent matter. Learn to identify these distracting items and ensure that important and urgent items are delivered on time.

Principle 3: Start with the end

Begin With The End In Mind is a habit mentioned by Stephen Covey In The 7 Habits of Highly Effective People. It is based on the principle that everything is created twice, first mentally and second physically. The intuitive way to say it is: think about your goal and then work towards it.

At work, many RDS walk with their heads down and rarely look up at the sky. In each quarterly review, many projects are listed and a lot of effort is put into it. But it’s hard to say exactly how much money these projects have made or how they have improved the business. This shows that the principle of “start with the end” is not observed in the work. In addition, many students did not pay enough attention to the goals and benefits in the process of requirements, and after the system was launched, they did not continuously follow up the use effect. This is especially true in technology optimization projects. For example, in an interface performance optimization project, through RD’s efforts, the system TP99 was shortened by 60%, and the support QPS was increased by two times. But just how optimized should the system be? Would it be better to cut it by 60% and increase it by twice? Before optimization, many students often forget to set a preset goal (TP99 less than how much, support QPS greater than how much). There must be a reason for the optimization. For example, traffic is expected to surge during a holiday or the timeout ratio of an interface is too high. If the optimization is not performed, the system may break down. The ultimate goal of technical optimization is to solve specific problems, so the goal should be set according to the problem, and then the optimization.

“Start with the end”, this principle can also be applied to our study. Many students read a lot of technical articles, but always feel that they still know nothing. A very important reason is not to study with a purpose. In this era of information explosion, if only to receive the pieces of public feeds, the effect can be almost negligible. Before learning, we must ask ourselves, what is the goal of this learning? I want to understand the persistence principle of Redis, or understand the master-slave synchronization mechanism of Redis, or I want to learn the architecture of the whole Redis Cluster. If we can carry out relevant data collection and learning with questions and goals, we will get twice the result with half the effort. This mode of learning is much better than fragmented reading.

Principle 4: Closed-loop thinking

Have you ever been to a design (or requirements) review and had a lot of interesting and reasonable comments, only to find that many of the issues raised in the first review had not been improved, and many of the issues discussed had to be discussed all over again? This situation is a typical work not closed loop.

Read a sentence before: whether a person is reliable, see whether he can do everything has account, everything has landed, everything has echo. This is the importance of closed-loop thinking. It emphasizes an immediate feedback loop. If we are assigned a task, we must give clear feedback within the specified time, regardless of the result of completion. For example, in a cross-departmental communication meeting, although all parties have reached an agreement, the initiator of the meeting has already made the final record known to everyone. However, there is no real closed loop at this point, and there are likely to be some potential problems during the landing execution. For example, have the minutes of meetings been carefully checked and confirmed by all parties? What is the clear progress To Do in the meeting? Is there a mechanism to Check the completion result? If they fail to do so, they will fall into a vicious circle of “communication-problem-discovery – re-communication-re-discovery”. A real closed loop requires us To develop good habits of thinking about things at work, with conclusions for communication, feedback for notification, and acceptance for doing.

Closed-loop thinking also requires the ability to proactively provide periodic feedback. When I first started working, I was assigned a two-month project. The whole project needs to be completed alone, and the development should be carried out in an orderly way according to the plan every day. About two weeks later, the Leader asked about the progress of the project, although I had told him that it was ok. However, the Leader told me that I did not talk to the computer every day, which made him very unsure. At this time, I realized a very important problem: there was information asymmetry between me and the Leader. Since then, I have had to update him on my progress from time to time, and even if it is only a short sentence, it is obvious that his confidence in me has increased a lot. Especially after I became a Leader, I have a more profound understanding of this closed-loop feedback. From the Leader’s point of view, he just wants to know whether the project is progressing normally and whether any problems need his assistance to solve.

Principle 5: Be in awe

“A gentleman’s heart is always in awe.” Being in awe will help us to make fewer mistakes. There are various specifications at work, such as code specifications, design specifications, online specifications, and so on. We must understand that the formulation of these norms must be based on some objective reasons, and they are all accumulated experience from countless cases in history. Every member of the team should learn and follow the rules, especially if you’re new.

When we enter a new team, please temporarily forget the previous habits, as soon as possible to learn the team’s existing norms, and make yourself consistent with the team. Taking coding style as an example, many students are accustomed to their own code writing style before. When doing the first project of a new company, they also follow their own habits to name variables and packages. As a result, in the process of code Review, I was proposed many changes, and had to rework. This problem can be avoided if you stay in awe and know the coding specifications ahead of time. Similar problems also include not understanding the online process, not familiar with the rollback operation, not understanding the SRE online change process and so on. In addition to these obvious norms, there are some established rules. Personal advice: If in doubt, ask other colleagues, don’t follow your gut.

Being in awe doesn’t mean being “old school.” After we fully understand these norms and conventions, if we think there is something wrong, we can discuss with the whole group of students whether to adopt new suggestions, and then update and iterate in time. In fact, keeping norms and conventions up to date is another form of awe.

Rule 6: Never do more than two things

Our team always adheres to the principle of “no matter what happens in two ways”, which can be interpreted as two meanings.

One meaning is ** “all reviews and issues are discussed, no more than twice” **. This requirement is due to the fact that many RDS spend much of their time in endless reviews and discussion of problems, rather than in actual development. In the actual work scenario, we often encounter some requirements review is not very mature. These requirements documents are either ambiguous in their background and objectives, or are not detailed enough in their product solution descriptions, or are ambiguous. RD and PM are forced to go back and forth. I once had a requirements review that went through three times and got knocked back. The same problem is common in design reviews. It is true that the plan needs to be discussed repeatedly, but if the agreement is not reached, it will consume a lot of precious time of RD and PM, which runs counter to the idea of improving r&d efficiency. Therefore, our team stipulated that: ** all reviews should be at most two times. ** In this way, stakeholders are forced to do as much as possible with requirements and solution design. Before the review meeting is organized, try to reach an agreement with all relevant personnel, ask their opinions, and conduct targeted discussions, which can greatly improve the efficiency and quality of the review meeting. If you fail the first review, you have only one chance to review. Once they fail twice, a Casestudy is required.

Another implication of the principle is that the same mistake should not be made twice. After each failure, Casestudy must carry out a profound summary and review, analyze the cause of the failure for 5 reasons, and give a clear executable To Do List. At each quarterly review meeting, we reflect on what the problem is, and we must improve in the next quarter, so that we cannot make similar mistakes again. Kong Ziyun: “No anger, no mistake”, in the mistakes of reflection and growth, can make us a better person.

Principle 7: Design first

The principle of “design first” is more specific. It’s a separate list because the architectural design is so important. Uncle Bob has said, “The goal of software architecture is to minimize the human resources required to build and maintain systems.”

Architectural design is not only about the quality of the system, but also about the effectiveness of the team. Many teams also specify that projects with a development cycle of more than 3PD must have a design document, and projects with a development cycle of more than 5pd must have a design review. In the specific implementation process, due to various reasons, the design often can not achieve the desired effect. Investigate its reason, some is because the project cycle is tight, not enough detailed design; Some are because RD subjectively thinks the project is simple and the design is done in haste. Numerous facts have proved that neglecting the early design often leads to a large extension of the subsequent development cycle, which brings great Delay risk to the project. And the most terrible thing is that improper design will bring huge maintenance costs to the project, so we have to spare time to optimize and refactor the project. Therefore, keep the principle of “design first” in mind at all times. Good design in the early stage will bring great benefits to the project development and later maintenance.

The principle of “design first” requires writing designs that others can understand. The most direct way to learn about a system is to combine design documents with code. In the actual work, many students design documents let you look at a head of confusion, the whole down, can not see the overall design idea of the system. In fact, the design process is a kind of intellectual creation, we hope it can become the crystallization of individual and collective wisdom. How can we make our designs easy to understand? Personally, I think design should be as logical as possible to organize the points in the design. For example, materials can be organized from the abstract to the concrete, from the total to the sub-structure. In the design process, we should take the requirements as the starting point, simplify the problem through reasonable abstraction, explain the relationship between each module, and then detail the module implementation details. After the design is finished, it can be sent to a more senior RD or PM for review and improvement according to their feedback. A good design must be logical and easy to understand, and the details can be implemented.

Principle 8: P/PC balance

“P/PC balance” principle, namely output and capacity balance principle. Aesop’s fable tells the story of the Goose that laid the Golden eggs. Output is like “golden eggs” and productivity is like “the goose that lays golden eggs”. A person who puts the egg before the goose may end up losing the assets that produce the eggs. Those who put the goose before the egg may end up starving to death. Output and capacity must be balanced to achieve true efficiency. To make this principle clearer, here are two examples.

From the perspective of systems, each system achieves its output by continuously adding functions, and the capacity of the system is characterized by a series of characteristics such as the scalability and stability of the system architecture. In order to achieve the balance between output and capacity, continuous optimization at the technical architecture level is required while continuously supporting business requirements. If we blindly meet the business requirements, the system will become slower and slower after a certain period of time, which will eventually affect the stability of the business. Conversely, a system with no business output will eventually die.

From the perspective of RD, RD creates value for the company by doing demand and realizes its own output. The capacity of RD refers to technical ability, soft quality and health condition. Only with these capital can we carry out continuous output. In my daily work, I find that many RDS tend to focus only on output. They are also working hard on projects, but each project uses the same approach as before. You end up not only doing mediocre projects, but complaining that you’re not growing at all. This is the P/PC imbalance. If I can continuously improve my technical ability and soft quality through learning and summarizing during the project process, and apply them to the project implementation and delivery, I believe that win-win results will be achieved.

The “P/PC balance” principle can be applied to many other areas, such as teams, families, etc., and I’m a big believer in this principle myself. I hope you can also take it as a basic principle of your own, and try to find a balance between output and capacity.

Rule 9: Ask questions

“Good at asking questions”, the first thing to be diligent in asking questions. Curiosity stems from curiosity and is a human instinct. In the work to develop a good habit of questioning, do not understand to ask, do not give up the opportunity to ask because of their laziness or due to the face. Ask politely for different points of view when they come across. Bock’s Theorem tells us that the best ideas and best decisions arise only from arguments.

In collective intelligence activities like design reviews and code reviews, be sure to raise issues. I often see that many students do not say a word during the review, which is a waste of everyone’s time. The purpose of design review is to let everyone put forward improvement opinions and reach an agreement on the scheme. If the whole process is “soy sauce”, it will lose the significance of the review. We encourage people to ask questions, express their inner doubts, and then get answers through communication.

“Good at asking questions”, but also know how to ask questions. Why is it that some students can ask good questions while others can’t ask any questions in the same design review? In addition to the differences in knowledge, expertise, experience, and so on, there is another important point: critical thinking.

Critical thinking advocates rational thinking through critical thinking, that is, the cognition and mastery of the essence of things. For information on how to think critically, you can consult some classic books such as Critical Thinking and Learning to Ask Questions. When faced with a decision at work, there will be a variety of opinions in front of you, so we must learn to use critical thinking to analyze whether everyone’s argument is reliable, whether the argument is reasonable, and whether there is an implied position. Similarly, when reading a tech blog, use critical thinking and ask why, is the author’s conclusion reasonable? Is the argument strong? Only in this way can we continuously acquire real knowledge.

Rule 10: Empty cup mentality

The “empty cup mentality” is the last principle. I think this is also the premise of a person can continue to grow. Technical people usually have a certain amount of pride in their bones, which increases with seniority and achievement. As a beginner in the workplace, he may be very modest, but after a few years of work, he will gradually improve his professional skills and may have made some small achievements, so he will become more and more confident. At this point, if you do not always maintain the “empty cup mentality”, this confidence will gradually evolve into complacency. Complacent people, often manifested in the work of others’ suggestions as criticism, do not accept any opposition, learning also lack of motivation to seek knowledge, always take their own strengths to do with the shortcomings of others. In fact, everyone will have some complacency, the terrible thing is that they do not know or even do not want to admit complacency.

The principle of the “empty cup mentality” requires constant self-examination and reflection. At work, we should talk with students of different levels or make a 360-degree evaluation, which will help us to evaluate ourselves more objectively. In the horizontal comparison, more to those outstanding students, learn the advantages of others. In the process of design review or code review, many students tend to adopt an antagonistic attitude towards the questions and suggestions raised by others. The mistake of thinking that others are picking on you is to take it personally. It’s true that in some ways, we may think more deeply than others, but that doesn’t mean we think deeply about everything. Use the critical thinking principle of “Be good at asking questions” to analyze other people’s suggestions carefully, and be open to absorbing the good suggestions.

Work and study are like “practicing to fight monsters”. The more skills you have, the easier it is to go to the end. With an empty cup mentality, we can discover a lot of new abilities that we didn’t notice before. All we have to do is work hard to learn them and make them part of our ability pool.

conclusion

Above are the ten basic principles of my work and study. Some of them focus on individual methods of doing things, such as “Owner consciousness”, “concept of time”, “start with the end”, “closed-loop thinking”; Some focus on team work standards, such as “be in awe,” “Do things in second place,” and “design first.” Some focus on team or individual effectiveness, such as “P/PC balance,” “good at asking questions,” and “empty cup mentality.” These principles are my years of work and study, constantly summed up the experience. I hope these principles can help and guide you as you make choices.

Work and live around principles to make yourself and your team stronger.

The authors introduce

Yun Peng, who joined Meituan in 2014, has participated in the construction of meituan hotel supply chain system and distributed scheduling system. Now he is responsible for the construction of Meituan travel customer relationship management system and basic information service.