[Work Comprehension] Four lessons learned by old programmers

foreword

It has been many years since I wanted to work on the Internet, and I have gradually degenerated from an ignorant teenager to an old fritter. When I first graduated, I was really a stupefied young man who didn't understand anything and couldn't understand anything. I am so busy working overtime all day long, and I have to endure criticism from leaders.

I stepped on many pitfalls during the period, and today I specially summarize four lessons and give them to young programmers.

1. Don't make small demands

When programmers are working, when receiving requirements, they must not make small requirements, small optimizations, and small iterations.
You thought it was just being lazy and reducing your workload, but in fact it greatly increased your workload.

After you have made a lot of small needs, you will come into contact with many people in the business module. Their business, products, operations, testing, development, and users will come to you directly if they have any questions, and you will see DingTalk unread every day Message 99+, everyone replied, you don't have to do anything this day.

You have made a lot of demands, and you are so busy every day that the leader will still not welcome you.

"What? This requirement is so simple, just add a few query conditions, you have to do it for three days?"
"Can you complete these three requirements in one day? Find a way to overcome it yourself."

In the eyes of the leader, what you do is doing odd jobs, which can be done by an individual, and you may be able to do it faster if you hire an intern, and you are a marginal figure in the team.

It’s never your turn to get promoted and raise your salary. If someone needs to recite a C for team performance, the leader will think of you first.

多做多错, there will definitely be situations that you can't consider, and there will definitely be some online problems.

In the eyes of the leader, this kid's ability is too poor, such a simple job can be useless, so hurry up and find a chance to let him go.

2. Make big demands

Programmers have to accept the demand, 大需求preferably lasting for 3 months or more than half a year, involving the core functions and core logic of the team, and developed by themselves as an owner, if not, actively strive for it.

You may say, I am not capable enough to hold, what should I do?

It doesn't matter, no one else is better than you.

You can apply to the leader for any resources needed to meet this demand. Big demand means that there is a lot of space for maneuvering.

"This is a big demand. I am familiar with the product documentation and design technical solutions. It will take two weeks. Is it okay?
"

Others are busy developing and launching, and you are communicating with the brother team in name. I can’t see you at your desk in the morning, and you are the one who speaks the loudest during the remote meeting discussion in the afternoon, creating a scene where the team is the busiest.

When you are designing a technical solution, whether the project working hours are 3 months or 4 months depends entirely on how your technical documents are written. A function of adding a button, no one knows whether the man-hour is one day or three days, because no one knows the whole picture of the whole project except you.

As the key requirement of the entire fiscal year, the highest priority of all the team's requirements, the performance of the entire team depends on you.

You said that the development resources are tight, it doesn’t matter, the leaders will come over and help you personally, and everyone in the team can be mobilized by you.

When the demand seems to be unable to go online on time, everyone will accompany you to work overtime. After you go online on time, you will take the bulk of the credit.

Even in the worst case, if the project fails, you will be graduated. You can also write something on your resume, it's better than writing crud.

Therefore, there must be great demand.

3. Regularly synchronize work progress

If you don’t talk to the leader for a week, the leader thinks you are paddling every day, but in fact you work overtime until 8 o’clock in the evening every day, and you are so busy that the leader keeps assigning you work. For the sake of synchronizing work progress.

Periodic synchronization of work progress has several functions:

  • Let the leader see your work, know what you are doing, and let the leader feel in control of the overall situation.
  • When encountering problems and lack of resources, the leader can help you coordinate and solve them in time.
  • Gain the trust of leaders and build good relationships.

The template for reporting to the leader can refer to the following:

Brother Qiang, I have recently developed a rocket-making requirement, and the current progress is 50%. The stainless steel tripod and aluminum alloy casing for the rocket launch have been built, and the launch fuel has not yet been determined.
I suggest using coal as fuel, preferably anthracite, which is more environmentally friendly, but the fuel group has not given a specific schedule, which may delay the overall progress of the project, or this phase will use corn stalks as fuel, you can see Can you coordinate this issue?

insert image description here

4. When the project is over, take the initiative to review

What? Replay? It sounds very professional, but you don't know how to review it.

Don't worry, other people don't understand either, everyone is rushing to the shelves.

On the one hand, the review is for the leaders to see, so that the leaders can know their hard work and work results. On the other hand, it is to sum up your own gains and losses, so that you can better shake off the blame next time.
You can perform a reset by doing the following:

  • Project goals, and status of completion
  • What did you do well and how do you continue to maintain it?
  • What are the deficiencies in the process and why? Do you have a good solution?
  • What are your reflections and conclusions?

insert image description here

Summarize

what do you think? Welcome to like and comment!

Guess you like

Origin blog.csdn.net/u011397981/article/details/130034413