A few days ago, I was swiped by an article "I, Ali P7, can't find a job". 34-year-old Awei is a data expert at Ali with an annual salary of one million. After Ah Wei left the company, he thought it would be easy to find a job, but unexpectedly, he searched for a job for four consecutive months and interviewed more than 30 companies. suitable offer. Ah Wei suddenly fell into self-doubt. Is it because his skills are not good enough, or is the market demanding too much?
When Ah Wei mentioned this, he realized that although he had been in Ali for the past three years, he had been stagnant in terms of technology and architecture, without any progress. Most of the time, I am actually doing ETL, developing reports and other screw-like work. It seems very busy every day, but the value of what I do is limited, and my growth is also very limited.
1024 is 2 to the tenth power, one of the basic units of measurement in binary counting. 1024, like all made festivals, became Programmers' Day. Today, major factories/communities will hold celebrations such as conferences, live broadcasts, etc. On the day of 1024, Brother G borrowed "I, Ali P7, Can't Find a Job" to talk about a few days of hot spots that are no longer hot.
Make an unusual "screw"
Regardless of writing java code or engaging in ETL to produce reports, they all follow some of the same thinking paths.
From the point of view of reducing duplication:
1. Realize the first requirement.
2. Realize the Nth requirement.
3. Can the repetitive work be completed by configuration without writing code.
4. Can there be a product that allows users to do it by themselves?
From a user job perspective:
1. The user raises a demand for data retrieval
2. Development and processing into reports
3. User use
Do you know what processing the user did after getting the report?
What problem does the user want to solve?
Are there any delivery timeliness (SLA) requirements for these reports?
From a stability point of view:
1. Little A receives a request and produces a wave of reports, which will be reviewed by xx supervisor at 9:00 am every working day, and then sent to the boss.
2. How to ensure that the goal can be achieved at 9 o'clock in the morning?
3. How many task dependencies does the link have?
4. What should I do if there is an error in the dependent task, and what is the SLA requirement for the corresponding task?
5. When the number of dependent tasks reaches 500, how can the dependent link be simplified under such complexity?
6. How many indicators does this report have, and can the corresponding data processing be grouped and divided and conquered in parallel?
.....
I often see some "teachers" "advising" graduates not to go to a mature factory to be a "screw". In fact, there are indeed various options, but if you know how to make a screw and make a screw that is different from others, it may be the path that most people can imitate.
Choose a good platform
To choose a platform that suits you, Brother G recommends that novices go to a mature company to see how to do things. Just because you see one doesn't mean you have to stay forever. Lao Chi's article "I suggest you go to a big factory once in your career" shared his own experience.
I first worked in iHuman Software for three years. It was a very vigorous company and it helped me a lot. Then I went to UFIDA and worked in UFIDA Software Park for many years. In 2015, I joined the start-up company Hammer Technology. Later, I worked as a geek and established Mowen Xidong and so on. I think that if a person is not the type of genius who is born to start a business, then he should work for others first, go to various types of companies, especially large companies, and then go independent when he has the opportunity If you make products and then start your own business, you will have fewer detours. This is one of my feelings.
I suggest that you must go to a big factory once in your career
If you choose a good platform, there are also college students who do well in starting a business. But "seeing a good system" is of great help to "building a good system".
Brother G suggested to go to a mature platform, which should be in the first half of life. If your development path is small company-mature company-own company, or mature company-small company-other mature company and so on. It depends on whether the company is an active choice or a passive choice.
How much do you know when you grow up
Lying flat is definitely not suitable for the career of programmers. Some time ago, a classmate named Mou Wu approached Brother G for advice on career development. He works for a mobile phone company, and what he does is to modify bugs, including solving some environmental problems, compatibility problems of different versions, and so on. Just looking at these things, I can't see the problem. But he said that he only wrote 1000 lines of code in 1 year, I was shocked. After locating the problem, the more complicated group leader makes changes, and he is doing all kinds of chores, and he is not settled in a specific subsystem or module. He wanted to leave the job, but he had a chat with hr at the end of last year, and was persuaded to stay. HR probably said that there is no technical content in writing code, and a team can get things done together. Now we should focus on innovation. We have to keep up with or think differently about what happens to the competing mobile phone manufacturers.
From the perspective of an organization, what HR said is correct, but from a personal perspective, you have to plan your own growth path. A win-win situation is that organizational development and personal development fit together, and if the individual is really not growing, you must decisively say Bye.
Continuously improve professional ability
According to the common understanding, with the growth of age, the accumulation of knowledge and experience, the professional ability of the individual should become more and more perfect. No matter what, the 35-year-old should be more powerful in professional ability than the stunned young man who has not worked for a few years. ? The truth is, not necessarily...
The following quotes a piece of thinking from Mr. Qu, a veteran driver who sits in the technical trivia.
This picture purely shows that there is no huge amount of questionnaire data to support it, and it is by no means accurate, but it is indeed based on my few life experiences as evidence.
The baseline is interpreted from the perspective of a company or a manager. As employees grow older and more experienced, their salary requirements will become higher and higher. Then companies or managers can completely require employees' professional ability to be linear or even exponential. increase in magnitude.
The actual line is not so optimistic. Young people who have just entered the workplace are like dry sponges, with a strong water absorption capacity. If there is no accident, they can grow into the core backbone or even the management team at the age of 30. This also means that the ceiling, the bottleneck period or the comfort zone will follow, and if one is not careful, it will slowly slide from the high point with an extremely subtle range.
The former Ali P10 Abai has a paragraph in " Guo Dongbai's Architecture Class " to remind everyone very sincerely.
For practitioners in our software industry, value creation is always a process of decay. Because our experience will quickly depreciate in the diffusion of information. If you don't measure your incremental value, you can't keep yourself at the forefront of value creation.
Due to space limitations, let's talk about these first. Brother G also has a few small points: talk about learning methods, how to persist, knowledge transition, lifelong learning, etc., I will talk about it next time when I have a chance.
Attached is "Guo Dongbai's Structure Lesson", introduce it to those who are destined.
To join the reader group of technical trivia, please reply in the background of the official account: reader group
Past recommendations:
Long press the QR code to follow
Based on distributed design, architecture, and system thinking, it also discusses bits and pieces related to R&D, not limited to code, quality system, and R&D management.