Recently, I chatted with a friend of Ali about how programmers can do things better. He mentioned a lot of feelings in Ali, which benefited me a lot.
The so-called "how to do things better" is to go beyond writing code, how to do our job well, get more personal growth, get better performance appraisal results, and stand out from others.
Under the collision of thinking, a lot of effective information has been obtained, which can be summarized into three aspects of "management" ability:
-
management by objectives
-
Process management
-
Manage up
Hope everyone can be inspired after reading it.
1. Objective management
The so-called management by objectives is divided into two stages:
-
propose goals
-
management goals
propose goals
The premise of management by objectives is to first be able to put forward a sufficiently valuable goal, and then to achieve it. If the goal itself is worthless, or the value is very small, then even if you spend a lot of effort to achieve it, it is meaningless. Like Moscow, programmers don't believe in tears. No amount of hard work can compare to credit.
So how can you come up with a sufficiently worthy goal?
①From top-down task dismantling
I often see people complaining about Huawei's "pull alignment" in various communities. But in fact, aside from the specific executive level of some managers, "pulling through alignment" itself is very valuable. The managers of the company are in a higher position, use more information to make decisions, and then get the company's development goals and direction for the next year. Then it is to disassemble the goal into various departments, and each department needs to cooperate with each other to achieve the goal. As an individual, you will also undertake sub-tasks within the department. At this time, you can put forward some of your own ideas for discussion. On the basis of full communication, you should reach an agreement and then resolutely implement it. Then your goal at this time is consistent with the department's goal, and it is also consistent with the company's big goal. If you can achieve your goals well, or exceed expectations, the greater your value to the department and the company.
②From bottom-up problem discovery and solution
You can often see people in various communities asking questions, how can CRUD be improved every day? In fact, one solution to this problem is to find the problem at work and give a solution.
Let me give a real case of our company: a back-end development student found that the business needs of his group often have many offline tasks to do. Some people use Spring's Async annotation directly, some people apply for a new thread pool plugging task by themselves, and some people use Redis' blpull/blpush to do queues for production and consumption. There is no unified solution, there is a lot of repetitive work, and it is easy to cause failures for various reasons (such as no resource isolation).
Therefore, he proposed a goal to make a distributed unified task scheduling framework to solve these problems within the group. After the goal was achieved, it was also promoted throughout the company. Everyone should be able to guess the results later. Promotion and salary increase have reached the pinnacle of life.
Some people say that you must be a small factory. The tools of the big factory are very mature, and there is nothing to do. This is half right, there are indeed many mature tools and frameworks in big factories, but they are also discovered and implemented by others, and I believe that no company or department has been perfect in everything, and there will always be problems and problems. The deficiencies are waiting to be resolved.
management goals
We already have a worthy goal, how can we achieve it? At this time, we need to manage the target.
I personally think the best way is the "reverse time" milestone mode. Reverse the time according to the target deadline, split the milestone nodes in different stages, and then check the current progress regularly, and finally achieve the goal.
In fact, it is not a new thing. Many companies are doing it, but when it is implemented in specific departments, groups, and individuals, it is not the same. Especially I'm talking about individuals and groups. During my tenure as the SM (scrum master) of the agile team, I found that many of my classmates lacked the ability to plan in this way. There are two main problems:
①The problem of time estimation
If today is just a task of writing SQL, many students can accurately estimate that it will take a few minutes. However, if it is a half-year or one or two-month project, it will be difficult for many students to grasp the project at a monthly or weekly granularity.
This is actually not a big problem, mainly because of lack of experience, unable to deeply understand the granularity and technical difficulty of module disassembly in the project. How to do it? There are three suggestions:
-
If you are not sure, then do a finer-grained task splitting of milestones.
-
Reserve Buffer to give yourself room to turn around and be able to face emergencies.
-
You can ask more experienced colleagues in the group or TL to review.
②Progress awareness
With clear milestones and timings, we also need to check the progress in time during the execution process. For example, on a weekly or monthly basis, to check on yourself or follow up on the completion progress of your collaborators. If it is found that there is a delay risk, then it is necessary to carry out risk exposure in advance, find a way to solve the problem, and speed up the progress. As mentioned above, if there is a certain buffer in the estimated time, it is easier to turn around, otherwise, the goal can only be achieved by working overtime.
In the past, when doing business development, the roles of product, front-end, back-end, and testing were closely related. Therefore, in the process of agile development, it was necessary to communicate progress through daily stand-up meetings and expose risks in time. When doing infrastructure-related work now, the project cycle may be longer, which is much longer than the agile iteration cycle of business development. Therefore, the progress is often shared on a weekly basis. Only by completing each milestone node on time can we be confident that the entire target will be delivered on time. For specific implementation, each company may have its own goal management system. I will make a simple table here to more intuitively reflect how to manage goals and milestones.
2. Process management
If management by objectives is a fundamental requirement for us to accomplish our mission, process management may be an important part of our "beyond expectations" rating.
I think the best way is to have your own set of " procedural DOD" based on the task DOD (Definition of Done) . Generally, the DOD of our task is to complete what functions and to go online according to certain time requirements. Some may bring some performance indicators, such as how much the interface response time is lower than the number of offline faults, and so on. So if you just fulfill these requirements, then what is the difference between you doing this thing today and another person doing this thing? Even if a project does not go online for various reasons, or is terminated in the middle, is everything you have done in vain? So, you must have your own set of "procedural DODs".
Below, I will introduce some of my experience and the experience of the big guys I have met. You can use it as needed (business development and infrastructure development are still very different, especially in terms of iterative pressure and way of doing things, so you can't in general).
①Complete research report
For any task, there are regular plans and high-quality plans. Just like the distributed scheduling system I mentioned above, ordinary students may just come up with a solution that can be used according to their own understanding. But a high-quality solution is definitely the result of jumping out of one's own horizons and learning from others' strong points. Therefore, before deciding on a technical solution, it is best to research the mainstream solutions in the industry to see if others already have better solutions. Then document your research results, which can not only increase your technical vision, but also reflect your good technical thinking ability, which is a very important procedural content.
②Complete technical design documents
After confirming the technical scheme, it is generally necessary to make a more detailed technical design scheme. Database programming? Programming for SQL? Object-Oriented Programming? Domain-oriented programming? These are all things that need to be carefully considered when designing technical solutions. A good technical solution can exercise your technical thinking ability, can guide you to develop quickly and with high quality in the later stage, and can also tell you why you think so when you maintain it in the future. Only through continuous technical design, development and reflection can we apply what we have learned and rapidly improve the technical level.
③Problem accumulation and solutions
There are generally two types of problems:
A technical problem: including problems encountered in the development process, online troubleshooting, etc. After you solve these problems, you will record the troubleshooting process and solutions to form a BP (Best Practice, best practice) document. Then you can share and promote it with other students. In this way, you can not only precipitate your own experience, but also gradually form a certain technical influence.
The other is business problems: students who are working on infrastructure often feel that they are caught in a vicious circle of operation and maintenance and customer service. A good solution is to accumulate and record the daily tedious operation and maintenance and customer service problems, and then strive to improve efficiency through technical means to automatically solve similar problems. To give an example: In the past, our company's database upgrades were all carried out by human flesh. The business side submitted a work order application, approved it, and then went to the DBA for communication to confirm the upgrade time. Then when the time is up, everyone needs to communicate again to confirm whether the business is at a low traffic peak and whether the upgrade can be started. Then, after the upgrade is completed, it needs to be checked and communicated to confirm that it has been completed. Later, someone proposed an automated solution. By connecting the work order system, database management system, and internal notification system, the entire process was automated and the efficiency was improved dozens of times.
④ Methodological output
After a project is launched, it means the end for many people, but for many people, it is only a staged victory, and more importantly, the output and promotion of the scheme theory. If a resource input and exploration can only produce one result, the cost performance is not high. However, if there is a complete replicable methodological output, then the process of this investment and exploration can provide countless future explorations. Guidance and suggestions, and even can be quickly replicated, that is, a very high input-output ratio. For some better people, after the methodology is produced, they can find commonalities and characteristics from them, and precipitate them into platform-based products, which is more niubility.
To give an example: before, the company made a project of sub-database and sub-table. After the project was launched, the project members wrote a complete methodological guide to promote and share in the company. The data verification tools used in the project process are also platformized into technical products, so that other business lines can quickly use similar functions. This is a very good example.
The output of the methodology, both for the company and for the personal growth, is an excellent way.
The product of process management can be well reflected in the results. In the same year, you have completed dozens of requirements. When you review at the end of the year, you only completed the requirements, while others have accumulated dozens of design documents, best practices, methodologies, and established a certain technical influence. You may be B , others are A, such a gap is caused by process management.
And more importantly, it can precipitate your own learning and thinking, which is a very important part of personal growth. Even if in the end for various reasons, there is no good result in the result orientation, the results of these process management are your most important assets. Does a five-year programmer have five years of experience, or a five-year experience? Process management can often tell you what to do.
3. Upward management
This part is not much, but it is probably more important than all of the above, and it is also a way of thinking that most programmers are prone to missing.
The so-called "upward management" does not mean flattering the boss. It is an effective way of communication, a scientific way of cooperation between superiors and subordinates.
With good "target management" and "process management", some people may fall into the trap of working behind closed doors and keep working hard according to plans or iterations, which is absolutely undesirable.
Many students are prone to fall into a misunderstanding. I can concentrate on completing the work at hand. But it's often the most dangerous.
Because even if you have finished all of them, you may only meet the requirements without any bright spots, or even you did not get it in time due to external changes, and you did it in the wrong direction.
We still need to take the initiative to communicate with the boss in a timely manner to communicate our current progress, difficulties and plans. Let your boss know your current progress in time.
A lot of times, when your boss comes to you, it's often not a good thing. Either you did something wrong or he wanted to know what you were doing and how far. In either case, it's not good.