How to become an excellent front-end engineer

[[145462]]

Philip Walton, a front-end engineer from Google, shared his views on how to become an excellent engineer. I personally feel that it is very valuable, so I translated it into Chinese for your convenience. My level is limited, if there are any inappropriate translations, please point them out in the comments.

Original article address: http://philipwalton.com/articles/how-to-become-a-great-front-end-engineer/

Recently, I received an email from a reader that prompted me to think about something. This is the question he asked me in the email:

Hi Philip, is it okay to ask how you become a great front-end engineer? Any advice?

I have to admit that I was very surprised to be asked such a question because I never thought of myself as a good front-end engineer. In fact, for my first few years in this industry, I really didn't think I was qualified for my job. I accepted these jobs only because I didn't realize how little I knew before, and I was able to get these jobs only because the people who interviewed me before didn't know what questions to ask me.

That being said, I did a great job in my role and became a valuable member of the team. When I left a job (and I was still not qualified for the next position) I would usually interview the people who were going to apply for my position. Looking back at the candidates I interviewed now, it makes me realize the importance of looking at knowledge. Even though I was weak in this area at the beginning. My current self probably would not hire my former self either, even though I know that success is possible with work experience.

The longer I work in the Web space, the more I realize that the difference between good people and really great people is not what they know, but how they think. Obviously, knowledge is important -- especially in certain situations -- but in a rapidly changing field, that's not the case. How you acquire knowledge is more important than what you know. And perhaps most important of all: how you use your knowledge to solve problems in your daily life.

You can find a lot of articles talking about knowledge points, frameworks and tools, which are all knowledge you need to know to get a job. I want to say something different. In this article, I will talk about the mentality that front-end engineers should have, hoping to answer the original question: How can you be excellent?

Don’t just solve the problem, get to the root of the problem

I see a lot of people just writing CSS and Javascript patches until they find something that works, and then they leave it alone. I see this a lot during code reviews.

I'll often ask people: "Why did you add a float: left here?" or "Is this overflow: hidden really necessary?", and they'll respond: "I don't know, but if I remove them, it breaks".

The same goes for Javascript. I've seen some people use setTimeout to prevent order of execution issues, or some people misuse stopPropagation() without considering that it might affect other event handlers on the page.

I have encountered many of the same or similar problems. If you never take the time to understand the root cause of the problem, you will find that you will encounter the same difficulties over and over again.

Taking the time to deeply research why your solution works may seem like a lot of work, but I swear it will save you a lot of time in the future. Having a comprehensive understanding of the system you are working on will reduce your guesswork and checking in the future.

Learn to predict future changes in the browser space

The main difference between the front-end and the back-end is that the back-end environment is under your control. But for the front-end, it is completely out of your control compared to the back-end. The platform or device used by your users may change at any time, and your code needs to be able to handle this situation gracefully.

I remember back in 2011, I saw the following source code in a very famous JavaScript framework (roughly like this):

var isIE6 = !isIE7 && !isIE8 && !isIE9;

I know in real life, feature detaction is not 100% effective, sometimes we have to resort to this bad way or browser whitelisting, but any time you do this, you should anticipate what might happen in the future, and even if it happens, your code should not have bugs.

For most of us, the code we write in our current job will outlive our tenure there. It’s both satisfying and terrifying to think that some of the code I wrote 8 years ago is still used regularly today.

Read the official documentation

Browser bugs always exist, but when two browsers run the same code and behave differently, people often make assumptions, rather than checking for themselves, and simply call the browser they think behaves well a "normal" browser and the browser that behaves abnormally a "bad" browser. But this is not always the case, and when you make the wrong assumption, any workaround you choose may fail in the future.

A real-world example is the default minimum size of flex items. According to the official documentation, the min-width and min-height of flex items are auto (not 0), which means that their size will not be smaller than their content. But for the past 8 months, Firefox was the only browser that correctly implemented this standard.

If you've ever encountered this kind of cross-browser compatibility issue, and you noticed that your page behaves the same in Chrome, IE, Opera, and Safari, but not in Firefox, you would definitely assume that it's a problem with Firefox itself.

When two or more browsers render the same code differently, you should spend some time to research which browser is correct and then write your code in the right way. Your work will be future-proof.

Additionally, great front-end engineers are often at the forefront of change, adopting and even contributing to technologies before they become mainstream. If you can find official documentation on your own and imagine how a technology will work before you can use it in a browser, you'll be the one who can talk about how the official standard will affect development.

Reading other people’s code

Reading other people's code is undoubtedly the best way to become a better developer.

Solving problems on your own is the best way to learn, but if you have solved these problems before, you will quickly reach a plateau (it is difficult to move up). Reading other people's code can open up new ways of thinking about problems. And the ability to read and understand code written by others is also a crucial skill when working with a team or participating in open source projects.

In fact, I think it is a big mistake to interview a candidate and only ask them to write code - new code. When I was applying, I was never asked to read some existing code, find a problem in it, and then solve it. This is very bad because as an engineer, most of the time we add and change some code on top of other people's code. It's rare to write something new from scratch.

Work with people smarter than you

In my impression, more front-end developers want to be freelancers (full stack) than back-end developers. Maybe it's because front-end engineers tend to be self-taught, while back-end engineers tend to be academic.

The problem with self-learning and working on your own is that you don’t get the benefit of people who are smarter than you. There’s no one to bounce ideas off of or review your code.

I strongly recommend, at least early in your career, working in a team, especially with people who are smarter and more experienced than you.

If you're done with your career and are now working for yourself, get involved in open source. Contributing to open source projects gives you many opportunities to collaborate with a team.

Reinventing the Wheel

In business, reinventing the wheel is bad, but not for learning. You might try to get a typeahead widget or event delegation library from npm, but imagine how much more you would learn if you tried to create those things yourself.

I’m sure some of you who are reading this are feeling strong opposition to this. Don’t get me wrong. I’m not saying you should never use third-party libraries. Using good libraries is a very smart thing to do.

However, in this article, I want to talk about how to become an excellent engineer from a good engineer. Most of the excellent engineers in this field are maintainers of these excellent third-party libraries.

You may never build your own javascript library and still be successful in your career, but you may never understand the core of problem solving.

A question that people often ask in this industry is: what should I do next? If you ask this question, why not try to recreate a JavaScript library or CSS framework that you like instead of trying some new tools or writing a new app. The advantage of doing this is that even if you get stuck, you can find the answer from the source code of the existing library.

Write down what you learn

1. You should write down what you learn. There are so many reasons to do this, but perhaps the most important reason is that it forces you to better understand what you're learning. If you can't explain how it works, there's a good chance you don't fully understand it. Many times you don't realize you don't understand until you write it down.

In my experience, writing, giving a talk, and writing demos are the best ways to force myself to understand something completely, inside and out. Even if no one will ever read what you write, the process of doing it is much more valuable.