How to become a great front-end developer

Original author: Philip Walton
  • Transfer

I recently received a letter from a reader of my blog, which, for some reason, made me think. The letter read:

Hi Philip, may I ask how you became a great front-end developer? Can you give some advice?

Frankly, I was surprised that they asked me a similar question, since I had never considered myself a “great” front-end developer. In fact, I'm not sure that I was qualified enough for everything I undertook when I was just starting to work in this area. I applied for a job only because I didn’t understand how little I knew, but I got it because the people to whom I came for an interview did not know what questions to ask.

However, in the end, I coped with each of my roles and became a valuable member of the team. When I was about to leave (for new challenges, for which I was also not prepared), I was usually asked to pick up a replacement. Looking back and recalling those interviews, I am amazed at how much importance I attached to knowledge - despite the fact that at first I myself lacked it. The present I probably would not have hired the past myself, although now I know that, theoretically, success is possible.

The longer I work in the web sphere, the more I understand that the main difference between good and very good specialists is not in the volume of their knowledge, but in how they think. Of course, knowledge is important, sometimes even very, but in an environment that is changing so quickly, the ability to acquire new knowledge always outweighs (at least in the long run) the knowledge that you already possess. But most importantly, how you use this knowledge to solve everyday problems.

There are many articles that talk about languages, frameworks, and tools needed to get work done. I wanted to take a different approach. In this article I’m going to talk about the mindset of the front-end developer and I hope that I can give the most comprehensive and detailed answer to the question: “How to become a great developer?”

Don't just solve problems - try to understand what is really happening with your code

Too many of those who work with CSS and JavaScript do something until this “something” works, and then move on. I observe a similar picture all the time when I look at someone’s code.

I often ask: “Why did you add float: left?” Or “overflow: hidden is really needed here?” In response to this, the phrase “I don’t know, but if I remove it, it won’t work”.

Same story with JavaScript. I see how setTimeout is used to prevent race conditions, or how someone stops events from spreading without worrying that this action will affect other page event handlers.

I understand that there are situations when you need something to work, and immediately. But if you do not waste time trying to figure out your problem, then continue to step on the same rake.

You can assume that trying to understand why your solution to the problem worked is a waste of time, but I promise that it will help you save time in the future. If you fully understand the system with which you work, then when solving problems you will not guess, but you will understand why you need to do this and not otherwise.

Learn to predict future technology changes

One of the main differences between front-end and back-end code is that back-end code is most often executed in an environment under your control. The front-end, on the contrary, is beyond your control. The platform or device of the user can completely change at any time, so your code should be able to cope with it at ease.

In 2011, I somehow read the source code of one popular JavaScript framework and saw the following line there (I simplified it a bit): var isIE6 =! IsIE7 &&! IsIE8 &&! IsIE9;

In this case, the code processed all versions of IE older than the sixth, but as soon as IE10 was released, significant parts of our application completely stopped working.

I understand that in the real world feature detection does not give 100% guarantees, and sometimes you have to take into account the incorrect behavior of browsers and reckon with those with feature detection incorrectly returning positive (or negative) values. But if you do this, you need to guarantee a future where these bugs no longer appear.

The code that we write today will exist for a long time - even after we leave the current work. Part of the code that I wrote more than 8 years ago still works on large sites - this thought at the same time gives rise to pride and concern.

Read specifications

There were bugs in browsers, they are and they will be, but when two browsers process the same code differently, people often assume without checking that the so-called “good browser” is right and the “bad” one is wrong. But this is not always the case, and if such an assumption turns out to be erroneous, any changes you make will almost certainly lead to a collapse in the future.

A topical example of this is the standard size of flex items. Based on the specification , the initial min-width and min-height values ​​for flex items are auto (but not zero), which means that by default they should not become smaller than the minimum size of their content. For the past eight months, FireFox has been the only browser in which this has been implemented correctly [1].

If you encounter such cross-browser incompatibility and notice that your site looks the same in Chrome, IE, Opera and Safari, but differently in FireFox, you would probably assume that FireFox is wrong. In fact, I have come across this many times. They often wrote to me that my Flexbugs project has a problem of such incompatibility, but if I tried to somehow work around this and implemented several solutions, then everything would have collapsed just two weeks ago with the release of Chrome 44. Possible solutions to the problem did not so much meet the requirements of the specifications how many tried to compensate (in fact) the correct operation of the browser [2].

When two browsers display the same code in different ways, you need to spend time and understand which one works correctly, in order to edit your code accordingly. Then in the future you will not have to redo anything.

I add that the so-called "excellent" front-end developers are people who are at the forefront, who adapt new technologies before they become popular, and even contribute to their development. If you develop the habit of looking into specifications and imagining how the technology will work even before it appears in all browsers, you will become part of a select group and you will be able to understand and influence the development of the specification.

Read code written by others

Reading other people's code for fun is probably not what you want to do on Saturday night, but it is, without a doubt, one of the best ways to improve your developer skills.

Solving problems on your own is a great way to learn, but if that’s all you do, then you will reach your limits pretty quickly. By reading the code of other people, you open your mind to new ways of solving problems. The ability to read and understand code that you did not write is very important if you are working in a team or participating in open source projects.

I believe that one of the biggest mistakes companies make when hiring new engineers is that they ask them to write code - new code, from scratch. I have never been in an interview where I was asked to evaluate an existing code, find errors in it, and correct them. This is very bad, because most of the time an engineer takes to supplement or modify an existing base. Very rarely do you create something from scratch.

Work with people smarter than you

I got the impression that there are a lot more front-end developers than back-end developers who want to do freelance work (working independently all the time). Perhaps this is because front-end developers often learn on their own, and the second category receives most of their knowledge at universities.

The problem here is that, doing self-education and working for yourself, you do not get the benefits and experience from working with people who are smarter than you. You have no one to discuss the idea or code with. I recommend at least at the initial stage of my career to work in a team where people are smarter and more experienced than you.

If at some point you start working for yourself, become (or remain) a part of open source projects. Active participation in such things will give you the same advantages as teamwork, and sometimes even more.

Reinvent the wheel

Inventing a bicycle is bad for business, but good for training. You may be tempted to grab a sample widget or event delegation library from npm, but just imagine how much more you will learn when trying to write these things yourself.

I am sure that some readers of this article will now begin to object. But don't get me wrong. I am not saying that you should not use ready-made code. Using excellent and proven libraries, whose bugs are fixed and the benefits are confirmed by several years of testing, is almost always a very good solution.

But in this article I’m talking about how to turn from a good developer into a great one. Most of the people in this industry whom I consider to be great have themselves created or helped with the support of the very popular libraries I constantly use.

Of course, you can make a successful career without creating your own JavaScript libraries, but then you will not have the opportunity to thoroughly understand what you are doing.

People in this industry often ask the same question: “What should I do next?” If you are asking this question instead of trying to learn a new tool or creating a new application, why not try to recreate one of your favorite JavaScript libraries or one of the CSS frameworks?

Write about what you learned

And last but not least, write about what you learned. There are a huge number of reasons why you should do this, but the most important thing is that it makes you better understand the issue. If you are unable to explain how something works, there is a chance that you yourself have a poor idea of ​​it. Very often you don’t even know that you haven’t figured it out completely until you try to express your words on paper.

From my own experience I’ll say that writing articles, communicating and creating models are the best ways to force yourself to plunge and fully understand any issue. Even if no one reads what you write, so be it - the process itself is important.

Notes: FireFox introduced specification changes in version 34 of December 1, 2014. Chrome did it inversion 44 of July 21, 2015, which means that Opera will get to this soon too. Edge was released on July 29, 2015 and operates according to the specification. Work on Safari seems to be underway. You can consider Flexbug # 1 a good cross-browser patch to solve this problem.

Our publications on the subject of development and design:

Also popular now: