Translated from Philip Walton’s blog

After reading very feeling, many views are their own long-term very adhere to and identify, so share the translation to more front-end students!

I recently received a letter from a reader that got me thinking. It went like this:

Hi Philip, do you mind if I ask how you became a great front end engineer? Do you have any suggestions?

I have to admit, I was surprised to be asked this question, because I never considered myself a great front-end engineer. I didn’t even think I could do it for a few years. I was sure I was less knowledgeable than I thought, and people didn’t know where to ask me in interviews

Having said that, I’ve done reasonably well so far and become a valuable member of the team. But when I finally left (to seek a new challenge — something I wasn’t up to yet), I was often asked to recruit my successor. Looking back on these interviews, I can’t help but marvel at how little KNOWLEDGE I had when I started. I might not be hiring on my own model right now, even if MY own experience would have been successful.

The longer I work on the Web, the more I realize that what separates talent from top talent isn’t their knowledge — it’s how they think about things. Obviously, knowledge is very important and critical in many situations — but in a fast-moving field, how you move forward and acquire knowledge (at least over a long period of time) will be more important than what you already know. What’s more important is how you use your knowledge to solve everyday problems.

There are tons of articles about languages, frameworks, tools, and more that you need to do your job. I want to give some different advice. In this article, I want to talk about the mindset of a front end engineer and hopefully help you find your path to excellence.

Don’t just solve the problem. What’s going on

Many people bury their heads in CSS and JavaScript until the program works, and then move on to other things. I found this happens frequently through code review.

I always ask people, “Why did you add float: left here?” Or “Overflow: Hidden here is necessary?” “They tend to say,” I don’t know, but when I delete them, the page gets messed up.”

In JavaScript, too, I always see a setTimeout somewhere in a condition race, or someone inadvertently prevents an event from propagating without knowing it affects the rest of the event handling on the page.

I’ve found that a lot of times, when you have a problem, you just solve the problem of the moment. But if you never take the time to understand the source of the problem, you will face the same problem over and over again.

Take some time to figure out why. It may seem time-consuming and taxing, but I promise it will save you time in the future. Once you fully understand the system, you don’t have to guess and argue all the time.

Learn to anticipate future browser trends

One of the main differences between front-end and back-end development is that the back-end code usually runs in an environment that is completely under your control. The front end is relatively out of your control. Platforms or devices for different users are a constant topic on the front end, and your code needs to handle it gracefully.

I remember reading a major JavaScript framework before 2011 and seeing code like this (simplified) :

var isIE6 = ! isIE7 && ! isIE8 && ! isIE9;Copy the code

In this example, the variable IE6 is used to determine whether the Internet Explorer version is 6 or lower. So when IE10 is released, our programming judgment will still be broken.

I understand that feature detection doesn’t work 100% in the real world, and sometimes you have to rely on buggy features or design whitelists based on bug detection of browser features. But everything you do is critical, because you see a bug-free future.

For many of us, the code we write today will take longer than our work cycle. Some of my code is more than eight years old and still running on the production line. It’s very satisfying and very unsettling.

Read the specification document

Bugs in browsers are inevitable, but when the same code renders differently in two browsers, it’s tempting to assume that the “popular” browser is right and the “humble” browser is wrong. But that doesn’t have to be the case, and when your assumptions are wrong, any workarounds you choose will have problems in the future.

A close example is the default minimum size for Flex elements. According to the specification, flex elements initialize min-width and min-height with auto (not 0), which means they should shrink to the minimum size of their content by default. But over the last eight months, only Firefox’s implementation has been accurate. [1]

If you run into this browser compatibility issue and find that Chrome, IE, Opera, and Safari look the same and Firefox doesn’t, you’ll probably assume Firefox has made a mistake. In fact, I’ve seen this a lot. Many of the problems I report on my Flexbugs project are like this. And the problems with these solutions will show up when Chrome 44 is fixed in two weeks. Each of these solutions harms proper normative behavior compared to standards-compliant solutions. [2]

When the same code renders differently in two or more browsers, you should take the time to determine which effect is correct, and code accordingly. Your solution should be future-friendly.

In addition, the “great” front end engineer is always aware of change, adapting to a technology before it becomes mainstream, and even contributing to it. If you train yourself to see the specification and visualize how it works before the browser supports it, you’ll be the one to talk about and influence the development of the specification.

Read other people’s code

Reading other people’s code for fun may not be your idea of fun every Saturday night, but it’s certainly one of the best ways to become a good engineer.

Solving problems on your own is definitely a great way to do it, but it shouldn’t be your only way, as it will soon settle you down to a certain level. Reading other people’s code opens your mind, and reading and understanding other people’s code is a must for team work or open source contributions.

I do think one of the biggest mistakes that companies make when hiring new employees is that they only evaluate a candidate’s ability to write new code from scratch. I’ve rarely seen an interview where a candidate is required to read existing code, identify problems, and fix them. The lack of such an interview process is really bad, because a lot of your time as an engineer is spent adding or changing doorsteps to existing code rather than building something new.

Work with people smarter than you

I remember a lot of front-end developers being freelancers (as opposed to full-time) and not that many back-end developers thinking the same way. Probably because a lot of the front end is self-taught and a lot of the back end is learned in school.

The problem with both self-learning and self-working is that you don’t get to learn from people smarter than you. No one reviews your code for you, and no one hits you with ideas.

I highly recommend, at least early in your career, that you work with a team, especially one that is generally smarter and more experienced than you.

If you end up working independently at some point in your career, make sure you get involved in the open source community. Keep contributing actively to open source projects, which will benefit your team as much or more.

“Make the Wheel”

Making wheels is very bad in business, but very good from a learning point of view. You might be tempted to pull those libraries and gadgets straight out of NPM, but imagine how much you can learn by building them yourself.

I know some people read this with particular disapproval. Don’t get me wrong, I’m not saying you shouldn’t use third-party code. Well-tested libraries with years of accumulated test cases and known problems are definitely wise to use.

But what I want to talk about here is how to go from good to great. I think a lot of the best people in the field are the authors or maintainers of very popular libraries that I use every day.

You may not have built your own JavaScript library and had a successful career, but it’s almost impossible to strike gold without getting your hands dirty.

A common question in this business is: What should I do next? If you’re not trying to learn a new tool to create a new application, try recreating your favorite JavaScript library or CSS framework. The good news about this is that the source code for all the libraries is there to help you out when you run into trouble.

Write down everything you learn

Last but not least, you should write down what you learn. There are many reasons for doing this, but perhaps the most important reason is that it forces you to understand things better. If you can’t explain how it works, along the way it pushes yourself to figure out things you don’t really understand. Many times you don’t even realize you don’t understand them — until you start writing them yourself.

In my experience, writing, speaking, and making demos are the best ways to force yourself to fully understand something. Even if you write something that no one else will read, you will benefit from the process.

Footnotes:

  1. Firefox implemented the spec change in version 34 on December 1, 2014. Chrome implemented it in version 44 on July 21, 2015, which means Opera will get it shortly. Edge shipped with this implemented on July 29, 2015. A Safari implementation appears to be in progress.
  2. You can refer to Flexbug #1 for a future-friendly, cross-browser workaround to this issue.