From May 31, 2018 to May 31, 2019, IT was a wonderful journey. I spent a year in Ali, during which I had happiness, anxiety, confusion and more thinking, thinking about my past shortcomings, thinking about some wrong ideas now, and thinking about how to become a better technical person. Share these thoughts with everyone who reads these words.
How should exceptions/faults on the line be handled
It seems to be a meaningless problem, how to face online abnormalities/faults, troubleshooting solved is not good, but this is really only the first layer.
It’s interesting to think about the word “fire protection” recently. It actually means two things:
- To eliminate is to eliminate the problem
- “To prevent” means to prevent problems
The word “firefighting” is supposed to mean eliminating problems before preventing them from happening again. In fact, the same is true for online abnormalities/faults. We should stop bleeding in time and deal with the problems, then dig into the problems and explore the root causes. Here are a few examples:
- Assuming it’s a null-pointer exception in some Code, would you consider enhancing Code Review or using the FindBugs plugin to automatically scan your Code for possible exceptions?
- Assuming it was caused by a configuration change online, do future changes have to be double-checked?
- If some values in the local memory are lost due to system restart, do you want to introduce a scheduled task to periodically write the values into the local memory?
- Assuming that some code logic is not tested, can you reflect on why this logic is not tested, and how to improve future testing?
In my experience, too many companies and too many teams dealing with problems online are content to simply deal with them and forget to fix them, which is bad for the team/company.
What is true technical competence
Before adding several technical wechat groups, I saw a lot of technical friends in the happy discussion of various source code, SPRING source code I thoroughly polished, recently in-depth study of dubbo low-level implementation, of course, I used to be such, remember learning volatile has been dug in the hardware level of volatile implementation, But is this really a sign of technical competence? Looking at it from today’s perspective, I think it reflects more on a person’s ability to learn, research and passion for technology than much else.
This topic, could be the year up to a point, to think study is a good thing, but in fact, most of the time delving into is not useful in the practical work, and study the deeper, the faster you forget, because the deeper research, so at this point associated technology, the more detail of forget, core of things is not easy to string together. So what is the real technical ability, let me draw a picture to summarize:
In short, technical ability = problem solving ability, so the same problem solving, what is the difference between high and low skills? I think there are the following levels:
- Level one: solve the current problem
- Level two: solve current problems in an elegant and reusable way
- The third tier is solving problems that are not just for the present, but for some time to come
In fact, from this point of view, the difference between different technical abilities in the work process is obvious:
- Whether written code is at risk of exceptions, whether there are thread safety issues when running in multiple threads, whether a piece of code can cause memory leaks
- Whether the code is elegant and reusable, whether the framework is sufficiently open and closed, and whether the structure of the code is clear
- Whether the technology selection and library table structure design are reasonable enough for a particular scenario, whether the framework you design today will last for one year, or will last for the next three or five years
- There is a big demand, for example, to build the membership system function of an App. Can we accurately divide the demand into several specific sub-modules and clarify the relationship between the modules after fully analyzing the demand
The more powerful people, in the process of code design and development, the more can see and think of some other people can not see the unexpected problems, this is called strategically; When there is a problem in the code operation, one hour to troubleshoot the problem, one minute to find the problem, this is called the weight of light.
So I think the ability to solve the problem is the real embody of technical ability, on technology to explore this year I also more shift from the source to learn design patterns, to study various no selection under distributed environment, to learn to use the Lambda make the code more concise, to really solve the problem in the practical work.
In addition, aside from this point, I have been thinking about it for two days. There is another point that reflects technical ability, which is learning ability. There are very few full stacks in reality, and programmers in the Internet industry usually have several directions:
- The service side
- The front end
- The mobile terminal
- AI
- The embedded
- Big data
In the same category, the basic knowledge, basic concepts and thinking direction are the same, but there may be more differences in development tools and languages. I am proficient in Java, but if there is a demand tomorrow that nodeJS, Scala and GO are better, can I quickly learn and get started? Even tomorrow there is a need to write front-end code, can it be developed quickly and bug-free online?
So, the ability to solve problems plus the ability to learn, I think, is the real technical ability, but at the end of the day, the ability to learn is, to some extent, just for solving problems.
Don’t build a wheel easily
Once upon a time, when we looked at so many excellent source code on Github, we silently vowed that I would write an awesome framework in my life, open source online.
Once upon a time, when a company was hiring, the head of technology would enthusiastically talk about how many systems the company had developed in-house and put into use online.
A lot of technology is the pursuit of a friend, enter a company could always looking for opportunities to do something make the wheels, but as said earlier, measure of really good technology is truly, truly, can solve the problem, to make the wheels high risk, long cycle, and need long time of validation, exhaust hole can achieve better effect.
To name just a few examples, in the development of the Internet today:
- Database connection pools include DBCP, C3P0, and druid
- The local cache is ehcache, and the central cache is Redis and Tair
- Servitization has dubbo, cross-language thrift
- Schedulex can be considered for distributed task scheduling
- The search options are ES and solr
- More advanced picture storage can be done with qiniu, IM can be done with Rongyun/Huanxin, audio and video this sound network is more mature, all of these provide various development versions of the SDK, easy access
As long as you have technical requirements, the vast majority of the industry already has a mature solution, there is no need to make a special set of their own. Therefore, I think it is easy not to build a wheel, if you must build a wheel, then please think about the following questions:
- Is there a solution to what you’re doing that already exists?
- If so, what’s the difference between your own set of things and similar solutions? Assuming you don’t have to do that, can you just tweak an existing solution?
- If not, then why not before? Is your company unique in this scenario? Or is the solution to this scenario simply not feasible and therefore not being worked on before?
If you think about it, go ahead and do it.
Focus on soft skill growth
It is a great pity that I did not write this point before, and I have been wanting to add it after the article was published, because my focus on the growth of soft skills is the biggest growth in this year except for the transformation of technical thinking.
We are technical people, yes, technology is what we are all built on, but we don’t just work with code:
- We have PD and need to talk to them about the overall interaction of requirements
- We have a business and need to fully understand the background of the requirements
- Within the technical team, we need to communicate with each other about progress, technical plans and design plans
- Outside the technical team, we need to promote the interaction between each other and the progress of upstream and downstream is not ideal
- If something goes wrong, we need to know what to say externally and what to do internally
- I have an idea, how do I get it to the ground in the right way, instead of just saying it and not saying it, talking about it and not doing it
All of these require experience and growth. I used to think that programmers only need to write good code, but when I came to Ali, I realized that writing code is really only a part of the job (maybe 50%?). And nothing more.
I believe that whatever you in 50 people of a small company or in big companies for 5000 people, in the technical team of three people or technical team of 30 people, no one is normal, the industry demand for technical people from pure technical requirements already more and more to the overall quality, therefore, focus on soft skills on their own, Believe that it is good for the present and the future.
To raise the level of perspective
In the past, too many people have reported a problem on my official account or blog: in this company, all the work of adding, deleting, revising and checking is not improving me at all.
To this view, the ugly word is —- shortsighted. We see:
A tree is just a tree when viewed from a normal perspective, but when viewed from a higher perspective, it is actually part of the forest. Your manager is not your boss because he should be more forward-looking than you. He is your boss because he sees things higher, thinks farther, and works deeper than you.
To put the question in practical terms:
- Suppose you were in charge of a system today. Did you just understand the fundamentals of the system? Or is it possible to sort out how many systems are upstream and downstream, how they are called and how they depend on each other?
- Suppose you were responsible for a piece of business today. Did you only identify the function points you were responsible for? Or can you start at the top, go to the system you’re responsible for, and think through it all the way down?
Today, instead of complaining about the lack of opportunities and the company’s failure to improve your ability, why not think about why opportunities happen to others and not to you? Why can other people write the same add, delete, change check in small company to BAT while you still write add, delete, change check in small company year after year? When you can really change your thinking mode, jump out of the current circle to a higher level to see the problem, to improve yourself, I believe there will always be a shining day.
Also in alibaba, ma teacher think nature, thinking about the development of environmental protection, human thinking, you think, the director of the team in the future direction and style, we are thinking about how to put a customer demand complete fall to the ground, this is the height, you may not want to teacher ma, but you can for higher standard level, step by step, try to go to their height.
To sum up: vision determines height. Look more, think more, be more curious and ask why more, and you will naturally reach a new level as time goes by.
Learn to summarize
The review of requirements and projects is a very important part. However, too many teams and leaders I have seen before only focus on iteration after iteration and version after version, only satisfied with the requirements and ignoring the importance of summary.
In my opinion, from large projects to small requirements, if there is no summary after completion, it is a failure to some extent. There are many points that can be summarized:
- Through this project/requirement, is the business understood, understand the context
- Through this project/requirement, the usage of one of the company’s technical frameworks/underlying components has been fully understood
- In the design of the whole project, what did not do well
- In the development of the whole project (for programmers), whether to step on the hole, made a low-level mistake
- Whether there is any deficiency in the progress control, personnel arrangement and upstream and downstream coordination of the whole project
- Experienced a big promotion of duty, whether can skillfully use the company’s monitoring tools, emergencies, quickly and effectively solve
Any job must be personally uplifting, but for those who don’t summarize, the things that grow in each project/requirement are scattered and forgotten over time. After a full summary, we will not repeat the mistakes we have made. We will remember the ins and outs of the business clearly, which is a kind of improvement for ourselves, and sharing it with others is also a great help to others.
Losers fail for different reasons, successful people always do things in the same way, from a macro point of view, I think the conclusion is that successful people can succeed, a very important reason.
Choice over effort
Ok, I admit to being naughty, but this part of me is also very sincere!
People, effort is the most important, but choice is also very important. It is very good to have ability. At the same time, a good Leader and a good team will make you feel very comfortable in your daily work, make you feel warm like home, and maximize your ability!
Cainiao international logistics technology team is such a team!
Finally, very important: Don’t be afraid of interviews. Only through the interview can you find your shortcomings and know what aspects you need to improve in the future. At the end of the interview, you can ask the interviewer what shortcomings you have, and the interviewer will certainly give you the most sincere advice!
Combine this article with your own summary:
1, learning ability affects skills, exploration ability affects height;
2, repeat wheel = time cost waste;
3. Solidifying knowledge is important (projects, documents, blogs, summaries…) ;
4. Control your own choices (in most cases, don’t choose);
5. The environment is important