Can I be called a senior engineer after two years?

Preface

Two years ago, I wrote this self-reflection of a junior engineer at the end of the year, mainly to review what I had learned that year and express my thoughts and feelings, and raised some questions about my career development.

The reason why the title is “junior” engineer is that at that time I felt that I couldn’t even touch the edge of being a senior engineer, so I used the word “junior” to describe myself.

Two years have passed, and my job title has changed from engineer to senior engineer, and even further to Front-end Team Lead. Although job titles don’t represent everything, I think they at least “represent something”. When you reach that position, you must take responsibility. If you feel that your ability is not enough, you must try your best to catch up until you can take on that responsibility.

This article will first review my development in the past two years, and finally share some of my thoughts and feelings.

Before that, I would like to wish all readers a happy new year!

Depth of Technology

Two years ago, I mentioned in the article that I was a person with breadth but not depth, and I hoped that I could go deeper in the future and make my foundation more solid. And during these two years, I have indeed made progress in this direction, starting to write some more in-depth technical articles, and these articles are often inspired by work.

For example, when I was warned by the security department about a CSRF vulnerability at work, I spent some time studying and wrote Let’s talk about CSRF. I also discovered a cookie problem that I was very puzzled about at about the same time, accidentally solved it, and then wrote The most difficult cookie problem I have ever encountered after understanding the problem. Different job content will also encounter different problems, such as It turns out that CORS is not as simple as I thought encountered when doing PWA and PWA practical experience sharing after completing PWA.

In addition to the inspiration obtained from work, I deeply feel that my grasp of the basics of JavaScript is insufficient, and I have never understood why those common interview questions are. Although these may not necessarily be used in work, I think they are things that cannot be avoided if I want to become a senior engineer, and they must be understood.

For this part, the first article I wrote was It’s time to understand the JavaScript prototype chain, which received a lot of praise. Then I wrote In-depth discussion of parameter passing in JavaScript: call by value or reference?, which summarized my opinions on this issue, and then the recent I know you understand hoisting, but how deep do you understand? and All functions are closures: talking about scope and closure in JS, which deeply studied the well-known hoisting and closure. Looking at it this way, after finishing writing about “this” (I also have a plan to write about it), I can probably handle the more common basics of JavaScript, and then it may be some issues related to type conversion.

In addition to JavaScript, I also wrote several articles about the network and browser, such as Easy understanding of Ajax and cross-origin requests for beginners, Progressive understanding of HTTP Cache mechanism that I used to be confused about, and Event propagation mechanism of DOM: capture and bubble, or occasionally study newer things like Unified web payment interface: Payment Request API.

Since 2015, my front-end development career has been revolving around React, so sometimes I will also write some related topics, such as React performance optimization challenge: understanding Immutable data and shouldComponentUpdate at once and Talking about React Fiber and its impact on lifecycles, or to learn RxJS in order to use redux-observable and finally write The most easy-to-understand RxJS tutorial.

I have written more than 20 articles in the past two years. I want to thank the partners of TechBridge for proposing the idea of running a collaborative blog together, which forced me to write an article every month.

Even though I have written so much, I know that there are still many topics that I have not covered. Even the topics I have written about may not have been fully understood. I think this is a part that writers need to be very careful about (or it can be said that it is a reminder to myself). Otherwise, if you are not careful, you will become arrogant and not realize that the world is much bigger than you think.

For example, a few days ago, I saw this article: “Tencent Front-end Interview (Part 1)” which shared the author’s experience of interviewing at Tencent. There were some questions that I didn’t know how to answer, so I still have a lot to learn.

In addition to not being arrogant, you also need to be careful not to underestimate yourself. However, this is super difficult. Sometimes it is difficult to find that line. I cannot say that I understand a topic 100%, but I cannot say that I do not understand it at all. After all, I have written so many topics, and I still have a certain level of understanding of what I have written. I still need to have confidence in myself.

By the way, there is also a trap to be careful of, which is that many people actually know these technologies, they just haven’t posted or shared about them. I used to think that if I couldn’t find an article about something, it meant that not many people knew about it. But that’s not true. They just haven’t shared it yet, and there are still many people who know about it.

Breadth of Technology

Two years ago, I felt that I had more breadth than depth, so I wrote a lot of articles to study different topics in depth and deepen my understanding of technology.

What about breadth? After having depth, I didn’t care so much about breadth anymore. In my first job, I hadn’t decided where I wanted to go, so I wrote the backend with node.js, the frontend with react+redux, and even wrote an Android app with Java.

But after that, I became a full-time frontend engineer, so I didn’t pay as much attention to backend technology. I don’t know what new trends there are, let alone mobile. I still maintain some basic sensitivity, such as knowing about new things like Flutter, but only knowing the keyword.

This is actually the direction I want to go. I think it’s a good thing to be broad before going deep. You have to be broad first to find the direction you want to go, and also accumulate a basic understanding of other fields during this period, and then go deep to understand the field you choose.

For me, during the breadth period, I made myself understand backend, mobile development, or some architectural things. These are all helpful for my career later on. At least I have a basic concept and won’t know nothing.

Now that I have entered the depth period, I focus on JavaScript, browsers, networks, and React, and I don’t pay as much attention to other things.

But if I have to choose a few topics to study outside of this, I would choose GraphQL and Vue, hoping to have a basic understanding of these two things.

Integration

At some point, you will start to be able to integrate what you have learned before and know the context of its development. It seems that I have reached this point in the past two years.

Actually, I had this ability before, but it has become more obvious recently. After mastering the context, you can explain the emergence of a technology and why to choose it clearly. You can know the core idea behind it. After such thinking, what you write is different.

In addition to the development of technology depth, I also write some popular science articles for the general public, such as “How can a beginner like Xiao Ming become a frontend engineer?” and “Understanding Technical Terms with Xiao Ming: MVC, SPA, and SSR”. These are things that I have digested and produced after organizing them myself.

I think the reason why these articles are so popular is that they have context. The development of technology has context. React will appear to solve some problems that jQuery and Angular cannot solve. Otherwise, we don’t need a new technology, and this new technology will not be so popular.

As long as you can find that reason, you can connect these points into a line, and connect more to become a surface, becoming a complete knowledge map.

In those two articles, I started from the simplest state and pushed down step by step. It’s like a mathematical proof or a logical proof. Each step is related to the previous step. It becomes more and more complicated in the proof process, but each step is interlocking.

Letting a novice touch React directly is like letting him start from the tenth step of the proof. He doesn’t know how he got here and needs to spend a lot of time to figure out how to move on to the next step. But if you let him start from the first step, take him to the second step, the third step, and so on, when he reaches the tenth step, he knows why he is here. He knows that this step is actually the accumulation of the previous ten steps. This is the difference between having context and not having context.

The reason why my articles are special is that I take readers from the first step and lead them step by step to the tenth step. So for people with no foundation, it is not particularly difficult; for those who already have a foundation, it will connect everything they have learned before and give them a refreshing feeling.

Teaching

I have actually been teaching intermittently before, but in January of this year, I finally tried what I have always wanted to do: to cultivate an engineer from scratch.

I have done two sessions of the program, and the detailed plan can be found in the Program 2 Enrollment Briefing. The course outline is also available on GitHub for those who want to learn on their own.

The second session is coming to an end, but it will take until early February to evaluate the results. I learned the most during the teaching process. Before each class, I had to make sure I fully understood the topic I was going to teach. This gave me the opportunity to understand some concepts that I had rarely encountered before, such as database views, stored procedures, triggers, and ACID.

The course outline was designed according to the context I mentioned earlier, but the difficulty gap was a bit too large, so there are still many areas that need to be adjusted. However, overall, I think there is no problem with what was taught. Everything that needed to be learned was learned, and not only the tools but also the principles.

Teaching is one of the few things I can maintain momentum and stick to. Although it is part-time teaching, I believe that the quality of the course is not too far from that of full-time teaching. As a one-person team, I think I did a good job. But of course, I won’t stop here. I think there is always room for improvement in the course.

Communication

When I first took on the position of Front-end Team Lead a year ago, I was actually very nervous. At that time, my supervisor just asked me if I was interested in trying it out slowly, and I said I could try it out slowly. The next week, I was pulled into this position. I originally thought I would be apprenticing with my supervisor first, but that didn’t happen at all.

However, although it is called Team Lead, it is actually more like Lead Engineer. The difference is that the former tends to be a management position that leads people, while the latter focuses on the technical side. I think in terms of job content, the latter is closer.

What I have to do is communicate with the PM and hold a sprint planning meeting every two weeks to see what tickets to put in. When there are new features, I have to give the PM a rough time estimate and distribute the tickets to other colleagues to decide what they need to do.

Simply put, I am responsible for communicating with the PM, and other front-end engineers are responsible for solving those tickets. But I also have to write code myself, and some of my time is reserved for communicating with the PM. Whenever there is any problem with the front-end, they come to me. I think I spend about 80% of my time writing code and the other 20% dealing with project-related matters. In short, I have to keep communicating.

I actually knew that my communication skills were not bad before, but I was nervous this time because I had to communicate in English… When I first joined the company, my English was quite poor (it’s not much better now), and I was afraid that I would keep jumping and saying, “Sorry, can you repeat again?”

At first, I did have some communication problems, but after two or three months in this position, I found that I was starting to get used to it. I was super focused during meetings, and although there were still some words I didn’t understand, I just focused on the keywords, and understanding 70-80% of what was said was enough for smooth communication.

In addition to this, I have also started to act as an interviewer in recent months. I have always felt that interviews are something that companies need to pay a lot of attention to because they are the company’s external face. A bad interview is worse than a bad meal.

I am still exploring how I can do better in interviews, but I remember what my senior said: the purpose of an interview is not to show off, but to see the strengths of the interviewee, whether they are suitable for the position, and whether they want to work with them. If the purpose of the interview is just to show off, then it is completely meaningless.

By the way, some people’s resumes are really poorly written. They have ten years of work experience, but it’s hard to tell what they have done.

So, am I a senior engineer?

Okay, after reviewing so much, I finally returned to the title.

Two years ago, I mentioned this great article: How to qualify as a senior engineer, which provides some indicators for reference and thoughtfully provides counter-indicators so that everyone knows what it looks like to go crazy.

After two years of training, I independently completed the development of a live streaming website in my previous company, and during this period, I deepened my understanding of the basics. My understanding of developing new features has changed from “not knowing if I can do it” to “I can do it, but it may take some time,” which has greatly increased my confidence.

In my current company, I finally have more opportunities for discussion and communication. I discuss with two other front-end engineers which library to choose, how to set coding style, how to name files, etc. I also communicate more frequently with the PM, which has further deepened my understanding of communication and project management.

In the past year, I have been responsible for four front-end projects in the company, and I have a different understanding of the architecture or technology used in each project. When doing different projects, I can observe the architecture and code written by others and cultivate the habit of fixing bad code on the spot. Before refactoring, someone said a great sentence: “Many engineers only rebuild, not refactor.” Refactoring should be gradual. If you want to wait until you have time to start over, you will never have time.

What you should do is fix some things while fixing bugs or writing new features. For example, if I change something in the purchase process today, I will refactor that part. You don’t have to do it perfectly, just make sure the code quality is better than before, and it will get better and better.

Writing blog posts and sharing experiences outside of work has been a great way for me to spend my time. Occasionally, I would spend six or seven hours just to write a technical article. Most of my time, however, was spent on teaching and training. The success of my students has proven the value of my curriculum, and teaching has also helped me solidify my own foundation.

Two years ago, with only a year and a half of work experience, I joined my second company. I considered myself a decent programmer, but my foundation was weak and my experience was lacking. I didn’t feel like I deserved the title of “senior engineer,” so I called myself a “junior engineer.”

Now, two years later, I can put various front-end tools into context, explain why they exist, and describe their benefits. I can also explain how to use them in projects. I have a good foundation in the essential skills of a front-end engineer, and I can discuss various strange phenomena in JavaScript, as well as network and browser issues. When a PM presents a requirement, I’m not worried about whether I can do it or not because I know I can. Instead, my focus is on how to implement it beautifully and in the required time. I also understand that engineers have many important tasks besides writing code, such as understanding requirements, communicating, and thinking.

Yes, I think I am a senior engineer now.

If you agree, please like and share (just kidding).

What’s next?

The more you know, the more you realize your shortcomings. There are still many areas where I need to improve, even as a senior engineer. Even if you’re a senior engineer, there can be a 30-point difference between a 90 and a 60. Learning is endless, and there is still much to learn. Here are a few areas I want to focus on:

First, I have a good foundation in JavaScript, but I want to be more stable. I hope to be so stable that I am not surprised by any JavaScript-related articles.

Second, I am weak in testing. I only have experience with unit tests, and I don’t know what to test when it comes to testing components in React. I also have little experience with end-to-end testing. I believe that testing is a critical key to moving to the next level. It can change the way you look at code and improve quality.

Third, I want to deepen my understanding of the tools I use. I hope to spend some time studying the source code of Vue, React, and Redux to learn more about their architecture and design.

Fourth, I have a limited understanding of some “basics,” such as browsers and networks. I have a general understanding of the rendering process in browsers, but I don’t understand each step well enough. I also hope to become more familiar with HTTP, HTTP2, and TCP/IP.

Fifth, I lack a foundation in computer science, such as operating systems, computer organization, algorithms, and data structures. If I want to move up, these are also essential parts. The most effective way to learn is probably to take courses offered by universities.

Technology is the foundation of an engineer, and we must not forget this. We must not let our technical skills become obsolete. It is because of our technical abilities that we can reach our current position.

Conclusion

I am very fortunate to have written that article two years ago. It was a great summary for me, and it allowed me to compare myself to my past self. After rereading my retrospective from two years ago, I realized that my concepts are still similar, and I still value sharing. Therefore, I have not stopped sharing in the past two years. I still believe that “pain is the best teacher,” and I have turned these concepts into articles. Otherwise, I would have to explain them again every time I mention them, which is not in line with the character of an engineer. I support breadth before depth because it has been helpful for me. As for the problem of small companies versus large companies, I have not yet worked for a large company, so I cannot share my experience. It may take some time before I can share my experience with everyone.

Every time I write a retrospective like this, I am amazed at how quickly time passes. I didn’t even realize that two years had passed. However, this also makes me look forward to what I will become next time.

That’s it. See you in two years!