Recently, I had a conversation with a friend of Ali about how programmers can do things better. He mentioned a lot about his experience in Ali, which helped me a lot.

“How to do things better” is about getting beyond coding to do our jobs better, achieving more personal growth, getting better performance reviews, and standing out from the crowd.

Under the collision of thinking, I have obtained a lot of effective information, which is summarized as “management” ability in three aspects: management by objectives, process management and upward management.

I believe that everyone can be inspired after reading.

1. Management by objectives

The so-called management by objectives is divided into two stages, proposing objectives and managing objectives.

1.1 Propose objectives

The premise of management by objectives is to put forward a sufficiently valuable goal and then achieve it.

If the goal itself is worthless, or has little value, it doesn’t matter if you put a lot of effort into it and then achieve it.

Like Moscow, programmers don’t believe in tears. No amount of hard work is worth any credit.

So how do you come up with a worthy enough goal?

1) Task dismantling from top to bottom.

It is common to see people teasing Huawei’s “latong Alignment” in various communities. But in fact, regardless of the specific executive level issues of some managers, “laton alignment” can be very valuable in and of itself.

The managers of the company are in a higher position, using more information to make decisions, and then get the company’s goals and direction for the next year. The next step is to break the goal down into different departments, which need to work together to achieve the goal. As an individual, I will also undertake sub-tasks within the department. At this time, I can put forward some of my own ideas for discussion, reach consensus on the basis of full communication, and then resolutely implement them.

Your goal, then, is to be consistent with the department’s goals and the company’s broader goals.

You will be more valuable to your department and company if you achieve your goals well, or exceed expectations.

2) Bottom-up problem discovery and solution

It is common to see people in various communities ask, how can CRUD be improved every day?

In fact, one way to solve this problem is to find the problem at work and give the solution.

Let me give you a real case of our company.

A backend developer found that business needs in his group often had a lot of offline tasks to do. Some people use Spring Async annotations directly, some people create a new thread pool block task, some people use Redis blpull/ BLpush queue for production consumption.

There is no uniform solution, there is a lot of duplication, and it is easy to fail for a variety of 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.

When the goal was achieved, it was promoted throughout the company.

You can guess what the result will be, promotion and salary increase to the peak of life.

Some people say, you this affirmation is small factory, big factory all kinds of tools are very mature, do not have what to do. This is half true. There are many mature tools and frameworks in big factories, but they are also discovered and implemented by others. I believe that no company or department has achieved perfection in everything, and there are always problems and deficiencies waiting to be solved.

1.2 Management Objectives

Now that we have a worthy goal, how do we get there?

This is where we need to manage our goals.

I personally think the best way to do this is with the milestone mode of “reverse time”. Reverse the time according to the target deadline, split the milestone nodes in different stages, then check the current progress on schedule, and finally achieve the goal.

In fact, it is not a new thing. Many companies are doing it, but when it comes to specific departments, groups and individuals, it is not the same.

And especially I want to talk about individuals and groups.

During my time as SM (Scrum Master) in an Agile team, I found that many of my classmates lacked the ability to plan in this way.

There are two main problems.

1) Estimation problem

If today is just an SQL writing task, many students can accurately estimate that it will take a few minutes. But if it’s a half-year project or one or two months, let you break it down in monthly or weekly granularity, many students are more difficult to grasp. In fact, this is not a big problem, mainly due to lack of experience, unable to deeply understand the granularity and technical difficulty of module dismantling in the project.

So how do you do that? There are three suggestions

• If in doubt, do more granular task breakdowns for milestones
• Reserve buffers to give yourself room to turn around and face unexpected situations
• Ask a more experienced colleague in the group or TL for review

2) Awareness of progress

With clear milestones and timelines in place, we also need to check progress during execution.

For example, on a weekly or monthly basis, check your progress or follow up with a partner’s progress.

If it is found that there is a risk of delay, then risk exposure should be carried out in advance to find a way to solve the problem and speed up the schedule. As mentioned above, it is easier to turn around if you have a buffer, otherwise you have to work overtime to achieve your goal.

In the past, the roles of product, front end, back end and test were closely related to each other in business development. Therefore, in the process of agile development, it was necessary to communicate the progress through daily station meetings and timely expose risks.

Now when you’re doing infrastructure-related work, it’s likely that the project will take longer, much longer than the agile iteration cycle of business development, and as a result, progress will be shared on a weekly basis.

Only by completing each milestone on time can we have confidence to complete the delivery of the entire target on time.

For specific implementation, each company may have its own management system by objectives. Here I make a simple table to more intuitively reflect how to manage objectives and milestones.

2. Process management

If management by objectives is the basic requirement for us to accomplish tasks, process management may be an important part of our ability to achieve “exceed expectations” evaluation.

I think the best way to do that is to have your own set of procedural DOD, based on Definition of Done.

Generally, the DOD of our tasks is to complete what functions and what requirements are on-line according to certain time requirements. Some may include performance metrics such as how low the interface response time is, how low the number of offline failures is, and so on.

So if you just fulfilled the requirements, what’s the difference between you doing it today and someone else doing it today?

Even if a project, for some reason, doesn’t go live, or gets killed in the middle of it, is all your work for nothing?

So you have to have a procedural DOD of your own.

Below, I’ll share some of my experiences and those of the big guys I’ve met, which you can use on demand (business development and infrastructure development are very different, especially when it comes to iteration pressure and the way things are done, so it’s not a generalization).

1) Complete research report

For every task, there are conventional plans and good ones. Just like the distributed scheduling system I mentioned above, ordinary students may be according to their own understanding, to make a workable scheme on the line. But the quality of the program, is certainly out of their horizons, the result of learning from others.

Therefore, before determining the technical solution, it is best to research the mainstream solution of the industry to see whether others have a better solution.

Then document the results of your research, which will not only increase your technical vision, but also show your good technical thinking, which is very important process content.

2) Complete technical design documents

After confirming the technical scheme, it is generally necessary to make a detailed technical design scheme.

Database oriented programming? Programming for SQL? Object oriented programming? Domain oriented programming?

These need to be carefully considered in the design of technical solutions.

A good technical solution can exercise your technical thinking ability, guide you to develop quickly and with high quality in the later stage, and tell you why you think so when you carry out maintenance later.

Through continuous technical design, development, reflection, can learn to apply, quickly improve the technical level.

3) Problem accumulation and solutions

There are two kinds of questions.

A technical problem. This includes problems encountered during development, troubleshooting online, etc. After you solve these problems, record the troubleshooting process and the solution to form a BP (Best Practice) document. Then we can share and promote it with other students. Not only will you be able to leverage your experience, but you’ll also be able to make a technical impact.

The other is business. Students who are engaged in infrastructure often feel trapped in the vicious circle of operation and maintenance and customer service. A good solution is to accumulate and record the daily tedious operation and customer service problems, and then try to improve the efficiency of technical means to solve similar problems automatically.

Let me give you an example. In the past, the database upgrade of our company was carried out by human flesh. The business side applied for work order and then approved it, and then communicated with the DBA to confirm the upgrade time. Then, when the time is up, we need to communicate again to confirm whether the service is at a low traffic peak and whether the upgrade can be started. Then the upgrade should be checked after completion, communication and confirmation have been completed.

Later, someone put forward the automatic solution, through the work order system, database management system, internal notice system, the whole process automation, improve efficiency dozens of times.

4) Methodological output

After a project goes online, it means the end for many people, but for many people, it is only a periodical victory. What is more important is the output and promotion of scheme theory.

If a resource input and exploration can output a result, the price is not high, but, if there are reproducible methodology of complete production, so this time investment and exploration process can provide a guideline for the future of countless exploration, and even can quickly copy, the input-output ratio is very high.

For some people who are more excellent, they may be able to find commonalities and characteristics from the methodology and deposit them into platform-based products. That is more niubility.

Let me give you 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 methodology guidance for promotion and sharing in the company. In addition, the data verification tool used in the process of the project is platform as a technical product, so that other business lines can quickly use similar functions. This is a very good example.

Methodological output is an excellent way to grow both for companies and individuals.

The product of process management can be well reflected in the results. In the same year, you complete dozens of requirements, but at the end of the review, you only complete the requirements, while others have accumulated dozens of design documents, best practices, methodologies, and established A certain technical influence. You may be B, while others are A. Such A gap is caused by process management.

And more importantly, you can cultivate your own learning and thinking, which is a very important part of personal growth. Even if, in the end, for a variety of reasons, you don’t get a good result on results, the results of process management are your most important asset.

Does a five-year programmer have five years of experience, or five years of experience? Process management often tells you what to do.

3. Manage up

This isn’t much, but it’s probably more important than all of the above, and it’s the mindset most programmers tend to miss.

By “managing up,” I don’t mean sucking up to the boss. It’s an effective way of communicating, a scientific way of working with superiors and subordinates.

With good “management by objectives” and “process management”, some people may fall into the trap of working behind closed doors, according to the plan or iteration, which is not desirable. Many students are easy to fall into a mistake, I concentrate on the completion of the work at hand, it is ok. But this is often the most dangerous. Because even if you get it all done, it might just be all there is to it, with no highlights, or even if you don’t get it in time and go in the wrong direction because of external changes.

We still need to timely and actively communicate with the boss about our current progress, difficulties and plans. Keep your boss up to date on your progress.

A lot of times, when the boss comes to you, it’s not a good thing. Either you’ve done something wrong, or he wants to know what you’re doing and how far you’ve gone. In either case, it’s not good.

Ali’s friend shared some of the better forms with me.

• Organize the task progress regularly, summarize the task progress, difficulties encountered, solutions and so on, and report
• Talk to your boss about technical planning, discuss what can be done, what needs to be cut, and put together a plan to implement what can be done
• Pay more attention to the weekly reports of classmates and bosses in the group. If you find any difficulties, offer help in time and solve them together

The way we do things is really important, especially as we programmers, who may spend too much time with computers, tend to lack the non-technical thinking outside of technology. Good non-technical thinking can help us grow better and stand out better.

Share with you ~

See the end, the original is not easy, point a concern, point a like it ~

Reorganize the knowledge fragments to construct the Java knowledge graph:
Github.com/saigu/JavaK…(Easy access to historical articles)