How to become a great front-end developer

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

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

Frankly, I was surprised that a similar question is being asked to me, since I never considered myself an “excellent” front-end developer. In fact, I am not sure that I was qualified enough for everything I took on when I first started working in this area. I applied for a job only because I didn’t understand how little I knew, but received it, because the people I had come to for an interview did not know what questions to ask.
')
However, I finally 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 choose a replacement for myself. 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 them. The present I probably would not have hired the past myself, although now I know that, in theory, success is possible.

The longer I work in the web, the more I realize that the main difference between good and very good specialists is not in the amount of their knowledge, but in the way 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 the most important thing is how you use this knowledge to solve everyday tasks.

There are many articles that tell about languages, frameworks and tools needed to get a job. I wanted to take a different approach. In this article I’m going to talk about the mindset of a front-end developer, and I hope that I can give the most complete and detailed answer to the question: “How to become an excellent 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 for as long as this “something” doesn’t work, and then move on. I see a similar picture all the time when I look through someone’s code.

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

Same story with javascript. I see how setTimeout is used to prevent a race condition, or how someone stops spreading events 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 attack the same rake.

You may think that trying to understand why your solution to the problem worked out is a waste of time, but I promise that it will help you save time in the future. If you have completely understood 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 anticipate 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. Front-end, on the contrary, is outside your control. The user’s platform or device can change completely at any time, so your code should be able to handle it easily.

In 2011, I once read the source code of a popular JavaScript framework and saw the following line (I simplified it a little): 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 of them whose feature detection incorrectly returns 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 reason for pride and concern.

Read the specifications

The bugs in the browsers were, are and will be, but when two browsers process the same code differently, people often assume that the so-called “good browser” is right and the “bad” 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 crash in the future.

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

If you’ve encountered such a cross-browser incompatibility and noticed 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. I was often told that my Flexbugs project has a problem of this incompatibility, but if I tried to work around this and implement several solutions, everything would have collapsed just two weeks ago with the release of Chrome 44. Possible solutions to the problem were not so much in line with the specifications How many tried to compensate (in fact) the correct operation of the browser [2].

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

I would add that the so-called "excellent" front-end developers are people on the front lines who adapt new technologies before they become popular, and even contribute to their development. If you develop the habit of looking into specifications and understanding how the technology will work even before it appears in all browsers, you will become part of a select group and 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 this 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 this is all you will do, then you will reach your limits pretty quickly. 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 work in a team or participate in open source projects.

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

Work with those who are smarter than you

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

The problem here is that by 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. I recommend at least at the initial stage of your 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 benefits as teamwork, and sometimes even more.

Invent the bicycle

To invent a bicycle is bad for business, but good for learning. You may be seduced and grab a sample widget or an event delegation library from npm, but just imagine how much more you will learn by 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, the bugs of which are corrected, and the advantages are confirmed by several years of testing, is almost always a very good solution.

But in this article I'm talking about how from a good developer to turn into excellent. Most of the people in this industry, whom I consider great, have themselves created or helped with the support of very popular libraries that 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 ask this question instead of trying to learn a new tool or create 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

Last but not least, write about what you have learned. There are a lot of reasons why it is worth doing this, but the main one 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 bad idea of it. Very often you don’t even know that you haven’t fully understood it until you try to express your words on paper.

From my own experience I will say that writing articles, communicating and creating models are the best ways to force yourself to immerse yourself 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 this in version 44 of July 21, 2015, which means that Opera will get to that soon. Edge was released July 29, 2015 and works according to the specification. Work on Safari, apparently, is underway. You can think of Flexbug # 1 as a good cross-browser patch to fix this problem.

Our publications on development and design:

Source: https://habr.com/ru/post/293936/

All Articles