After making my WeChat ID public for a while, quite a few people added me. Most of them were learning front-end development. Some had run into difficulties, or maybe it is more accurate to call them bottlenecks, and wanted to know how I would handle them. Others asked me to talk about my own learning experience.
Some of those questions are too broad to answer properly in a chat window. To be honest, I often did not know where to begin. After thinking about it for a while, I decided to write down a few things from these past three years.
Not long ago I wrote about how front-end work has become harder to do. The role of front-end engineers has changed a lot. The front-end field keeps expanding, the things we can do keep increasing, and naturally there are more directions to choose from.
At the same time, new terms and new technologies appear one after another, barely giving people time to breathe. Before you have fully understood one wave, the next wave—or even the one after that—has already arrived. Many people gradually lose themselves in a pile of technical vocabulary. Add to that the fact that you may face the same people and do similar work every day, and it becomes easy to feel that you are not growing, or that you do not know how to grow.
I officially joined Taobao on July 14, 2014. Before that, I had interned for three months at Baidu and three months at Taobao. Those two internships helped me grow a great deal, and the two years after officially joining Taobao taught me even more. Looking back, I feel that the fastest period of growth for a person is often the period in which they are adapting to a new environment.
Build the fundamentals until they are solid
Before my first round of interviews, I remember working very hard to list all the front-end-related technical points I knew. I wrote several pages of keywords, then went through them one by one, reviewing them systematically, resolving old questions in my mind and dealing with new questions that came up during the process. After that, I went into interviews at Sina and NetEase feeling quite confident.
At that time, front-end engineering practices had probably already started to take shape in those companies. But perhaps because interviewers assumed students did not have much real project experience, most of the questions focused on front-end fundamentals: closures, regular expressions, the DOM model, the event model, and so on. There were not many especially deep topics. Of course, my résumé at the time did not show much about engineering practices either, so there probably was not much for the interviewer and me to discuss in that area.
For front-end beginners, interviewers usually care most about learning ability and future potential. They will also check whether your programming ability is acceptable and whether your understanding of JavaScript, CSS, and HTML is solid enough. If an interviewer chooses you, it generally means your overall qualities are strong and you qualify as an entry-level front-end developer.
Students from stronger universities usually have decent learning ability. After taking a few computer-related courses in college and doing some appropriate practice outside class, their programming skills are often good enough. That is one reason companies like hiring students from well-known universities, especially those with a science or engineering background. I have seen many students start learning front-end development only three to five months before graduation and still manage to enter companies like Baidu, Alibaba, or Tencent.
I belonged to that general group too, except I did not start cramming right before graduation. I encountered front-end development relatively early, read many books, became part of the front-end community, and trained my basic skills in a technical team at school. I am glad I spent so much time in college learning the fundamentals of front-end development, because after graduation I realized that I no longer had that much time or patience for knowledge that can feel a little dry.
If you are already working, can you still sit down and read through JavaScript: The Definitive Guide in one stretch? I suspect most people no longer have that patience. Even if some of the knowledge has faded, you are probably only willing to treat that book as a reference. Before graduation, I had read it four or five times. Now I basically no longer need to keep it beside me as a tool book.
I read a lot during university and once kept a record of those books on Douban. Each book added something to my knowledge. Taken together, that reserve was enough to handle interviews and ordinary development needs. Without being too modest, I had a fairly broad understanding of hard front-end knowledge, and that gave me a firm base for later improvement.
A knowledge system is different from scattered knowledge
After graduating and starting work, however, I quickly realized that what I had learned was far from enough. In fact, I had already felt this during my internships.
Why do companies hope students can intern before joining full-time? Because every company has its own processes and technical system. That system is designed around the company’s business and helps different roles collaborate. And the system differs from company to company.
A new graduate is usually most familiar with using APIs. But once you enter a new environment, you may find that the set of tools and habits you used to rely on no longer works well. There are software environments to set up, frameworks and libraries to get familiar with, development processes, release processes, business processes, and many other things waiting for you. All of this can quickly strip away the sense of superiority a confident newcomer might have.
On top of that, if the business you are assigned to has a few small bugs waiting to be fixed, you will have almost no time of your own. Learning suddenly becomes a luxury. This is also a reminder for students who are still in school: if you want to follow the technical path, make your fundamentals strong. Otherwise, your first year at work will be quite painful.
The months I spent interning at Baidu changed me a lot. After three months of working outside the ivory tower, my experience grew, and more importantly, my understanding of technology improved significantly. Of course, I have the company to thank for that.
Inside a company, it is easy to see which technologies the company actually needs and which skills must be mastered for the business. Slowly, you develop the ability to distinguish between technologies. The keywords that once occupied my mind were things like single-threading, compatibility, bubbling and capturing, and event delegation. Later they became componentization, debugging modes, automated testing, and front-end integration environments. Those are completely different dimensions of knowledge.
A company also has people at different levels, and the things they do are not the same. By observing those differences, you can gradually understand what your strengths and weaknesses are compared with others, and what you need to do if you want to move up. The larger the company, the clearer the ability levels tend to be, and for an individual it becomes easier to locate your own position.
Once you know where your current level is, and where the next level is, the rest is mainly effort.
Let business needs decide how deep you go into new technology
I never worry much when the community produces a few more new technical terms, because I already have a place for those terms in my head.
For example, when names like Grunt, Gulp, and Webpack appeared, I did not rush to study them deeply. I had a rough map in my mind, so I first put them into a category called something like "engineering — build and packaging tools" and stored them there. When I needed them, I would learn them. In reality, I only started studying and using them three or four months later.
But before putting a tool into that mental map, I would still get a basic understanding of it. What can it do? In what scenarios can it be used? Roughly how is it used? Where is its community? How do you search for its plugin or component ecosystem? What are the differences among similar tools? I would also look through the basic APIs.
This does not take much time, but it helps a lot when you later need to understand the tool in depth. I have always agreed with this idea: if you know where to learn a piece of knowledge, you have already learned half of it.
So I do not panic when a new technology appears. I am not in a hurry to master it, because even if I learn it, my team may not use it, and the business may not need it at all. For new knowledge, first classify it and understand the general picture. As for the details, you can leave them for later.
There is no need to jump into source-code analysis at every turn, or immediately dig into React’s diff algorithm or Vue’s MVVM implementation. Those things take time and energy. In many cases, if you think about them briefly, you can already form a rough understanding of what they are doing. The implementation details and underlying principles are not unimportant; they are just not always important right now. You can wait until you have free time, or until you know the business will need it, and then spend serious effort going deeper.
Most of the time, technology changes because requirements change. And where do requirements come from? From your team and from the business. Follow the business, and your direction will usually not be too far off.
Front-end growth has no ready-made syllabus
It is fair to say that almost nobody has learned front-end development in a completely systematic way. Universities do not really have this course, and companies do not really have it either. The term "front-end" became popular around the rise of Ajax. It is a young field, full of energy, and it has developed at an unusually fast speed.
If you want to go far on the technical path, the first thing is still to make your foundation solid. Only after that do you have the ability, and the spare energy, to improve step by step.
I hope these thoughts offer some reference. Another topic worth writing about is how to build one’s own knowledge system, but that is a separate discussion.