Learning back-end technology is not that different from learning other technologies. Therefore, it makes sense to change the topic to how to learn technology. To sum up, there are the following suggestions:

  • Solid basic knowledge of computer
  • To know why is to know why
  • Hands-on practice
  • Frequent practice
  • Continuous learning
  • Self summary
  • Learn to plan

Solid basic knowledge of computer

  • Data structures and algorithms: Programs are made up of data and algorithms, so these two things are the basis of computer software. Such as B tree, hash table, stack and seven sorting algorithms, search algorithms, in a lot of software code can be seen. Sometimes, the difference between a good engineer and an average engineer is the ability to use the right data structures and algorithms.
  • Computer operating system: The operating system can be said to be an integrated software program. Resource scheduling, task scheduling, IO scheduling, process communication and so on, each design is very essential, but also a lot of other application software design ideas.
  • Computer network: at present, as long as there is data transmission function of the vast majority of procedures are inseparable from the network. The design of the layer 7 or 4 protocol stack is very elegant. Knowing how network connections are established, disconnected, and what each connection state means can help you troubleshoot network problems.
  • Computer composition principle: this is the lowest level of computer design, but also the basis of all computers. Knowing this will help dispel the mystery of computers, which are von Neumann computers that store data and run programs in sequence.

The above are some of the more common basic knowledge courses for computer majors. What I have to say here is that although the computer courses in universities are relatively backward, these basic courses need to be mastered in any case because they have not changed much for many years. Maybe you don’t feel so useful when you go to school. However, in the actual development work, whether one can master solid basic knowledge often determines the upper limit of a development engineer, which is also the reason why many large Internet companies focus on the investigation of some basic knowledge, no matter in school recruitment or social recruitment. After all, what you can use only determines your lower limit, and your basic knowledge and ability to learn determine your upper limit.

In addition, in fact, many peacetime development of some technology can be analogous to some basic knowledge. For example, the Cache technology we often use to improve query performance is the same thing as the CPU Cache designed to accommodate CPU and I/O speed mismatches; The same goes for interprocess communication in operating systems and asynchronous synchronous communication between services. And so on. In fact, the computer science foundation condenses a lot of the essence of design, whether it is computer hardware architecture, computer operating system or computing network.

To know why is to know why

It’s not uncommon for engineers to come in for an interview with a resume full of projects and experience with technology, making them excellent candidates by any measure. But as soon as the interview gets down to principles or optimization, many engineers, even senior architects in some companies, will falter, answer questions that aren’t relevant or don’t pay attention. The most common explanation I hear is that I’m too busy with business pressure to study this. In fact, my own experience, business is busy, but no time is certainly an excuse, after all, read a project source code although more time-consuming, but to go online to see the existing principle of analysis is not too much time. In the final analysis, there is still no basic sense of knowing what is more important than knowing why. A lot of things that you learn to use will be exciting, but have you ever wondered how such exciting features are implemented? The simplest example, the Java HashMap, is widely used, but how does it work? A lot of people don’t even know what this has to do with a hash table in a data structure class, let alone how to resolve conflicts.

This can also be reflected in the current phenomenon of many development engineers working for a long time, looking very experienced, but basically taking one year of experience to repeat n years. Basically every job, every project is duplicating, and there’s no thinking about how to avoid duplicating.

Furthermore, in addition to looking at the source code and digging into the bottom line when encountering problems, actively reading the source code of classic class libraries, high-quality open source projects, and other code written by colleagues, learning good architecture, design, coding style, and use of class libraries is a very effective way to promote your own technical progress.

There are also issues of breadth and depth of technology. As far as I am concerned, for engineers who have just graduated or just joined the company, the most important thing is the problem of depth. Only when you have in-depth research and attainments in a certain field, can you integrate, rapidly expand your knowledge and make breakthroughs in breadth. For engineers with a certain amount of work experience, although the depth is not so necessary, but the problems encountered, new things to learn or get to the bottom of it, otherwise once there is a problem to blind sheep repair will make you appear very passive, is not conducive to their own technical development. After all, a person who has done everything, used everything and mastered nothing is too replaceable.

Hands-on practice

The learning field has the so-called 721 model: 70% of personal growth comes from on-the-job practice, 20% from learning from others, and 10% from training. Although this theory is controversial, it seems reasonable to me for programmers to prioritize in terms of practice, learning, and training. One widely recognized best practice for learning techniques is “project-driven learning,” or hands-on practice. A lot of technology, just reading, you will be in a fog, read and forget. You need to be able to use this technique quickly through your own practice or projects. In addition, now circle of friends, micro blog are full of all kinds of so-called dry goods, many people read a lot of information to think that the goods are full, in fact, for the inside of the things did not go to practice. Sometimes even just sigh about others really good just. The real stuff needs to be digested by itself, and one of the best ways to digest it is through practice, whether it is from examples in the material or from a brush brush of knowledge.

Frequent practice

Hands-on practice can get you started quickly, but it takes frequent practice to become proficient.

The “10,000 hours” theory states that any industry needs at least 10,000 hours of practice to become an expert. Regardless of whether this theory is true or not, everyone can relate to the feeling of strangeness you feel when you don’t write code or use a technology for a long time. This shows how important frequent practice is for the role of development.

Of course, frequent practice here does not mean repetitive work. Should be with their own thinking to practice, to think about why do you do it? Is there a better way?

Continuous learning

The phrase “never too old to learn” applies to the profession of programmer. IT technology, especially in the development of Internet technology, its iteration is very rapid. Maybe what you learn today will be abandoned in a few years. Although the back-end technology is relatively stable compared to the front-end technology, the speed of iteration is still very fast compared to other industries, and the technology like Struts, which was a hot mess at that time, has become obsolete now. Therefore, we must be sensitive to new things and new technologies, and constantly dabble in the latest knowledge points in the industry to expand our knowledge base.

Another thing to mention here is getting out of your comfort zone. People are familiar with the things they are familiar with, and can use the technology they are familiar with with confidence. However, when they need to use the technology they have not been exposed to, many people are afraid to try, and thus lose the opportunity to learn new knowledge and expand their knowledge base. The best way to get out of your comfort zone and embrace new technology is to keep yourself interested in learning and improving.

Self summary

I believe that many people in the ordinary work, often encounter some problems, and then through access to online information, ask colleagues, look at the source code and other means to solve, when again encountered similar problems or even the same problem, or confused. Forget the memory problem, a big reason for this is not summarizing. Of course, the summary here not only means to record the problems you usually encounter, but also to find out the essence of the problem, how to avoid the same problem, and what inspiration and harvest from it. Further, we need to organize our knowledge harvest in a period of time into a system or into our own knowledge system, so that we can draw inferences from one another and have evidence to follow when encountering the same problems.

Ways to summarize yourself include note-taking, blogging, and sharing. Among them, I recommend blogging and sharing more than taking notes. After all, while communicating with others can help you maintain control over the quality of your summary, the “honor” of sharing your knowledge can in turn generate positive feedback that makes you more willing to summarize and share.

Learn to plan

I have talked with many engineers about career planning. Some of them have a clear idea of their career path, but most of them have no idea and just think they can earn money to support their family. It is obvious that the former belongs to those who have a plan. For such people, their efforts are targeted, so their path will be more steady and sustainable.

Learning to plan is a key trait for r&d positions. Planning can be divided into long-term planning and short-term planning. The career planning mentioned above is a kind of long-term planning, which needs to be forward-looking to set their own direction of progress. Growing as a back-end service architect in five years can be considered a long-term plan. The author’s own long-term plan is as follows:

  • Before the age of 35, only do things that can improve their skill level and become recognized as an expert in a certain technical field.
  • Never join a company or team you don’t agree with for money.

For short term planning, it is about specific skills, promotion, and learning. For example, the author’s one-year study plan includes:

  • Learn machine learning techniques and become a “tuning engineer”.
  • Strengthen my management skills and be able to lead the department to achieve good performance.
  • I have read ten books including Growth Hacker and Distributed System Concept and Design.

It should be noted that for these short-term plans, they should be set reasonably and accessible, and their priorities should be set, and they should be completed step by step according to the priorities. In addition, planning should not be fixed and can be flexibly adjusted according to the actual situation.

How to learn a new skill

The above is mainly about how to learn technology at the macro level, but there are also laws to follow when it comes to learning a new technology. As shown below:

Because a lot of technology module is very much, the source code is also very complex, a lot of times when looking at the source code will be trapped in the more see more can not rule, so here focuses on “look at the source code” a typical process:

  1. Read the architecture documentation for the technology to understand its overall architecture and composition.
  2. Classify source files into modules or hierarchies based on the overall architecture.
  3. Choose the most independent (least dependent) module code from modules you have never read before.
  4. Read the functional documentation for this module.
  5. Read the source code for this module.
  6. Organize the call relationships (in table or tree form) as you read.
  7. Go to step 3.

conclusion

Programmers are a pyramid system, and the higher up the ladder, the fewer people there are and the harder it is to reach. As shown below:

Getting to the top of the pyramid requires constant learning and improvement, including the right attitude, the right approach and constant effort. This article is just the author’s own experience, but also their own practice. In addition, there are certainly many other excellent methods and ideas to facilitate this process.

This article is excerpted from the Book “How to Be a Java Engineer.”

This book can be seen as a Java engineer’s orientation guide or a reference manual for connecting Java back-end skill points. Through the carefully choreographed content, the novice Java engineers can learn the relevant development skills in a systematic way, and the experienced Java engineers can check the gaps, consolidate their relevant development skills, and further improve their Own Java technology system.


Book address: item.jd.com/12325207.ht…