Research in software engineering suggests that, for individual developers, the best developers are about twice as productive as the average, while the best developers attract other good people, or motivate and help other members of the team, resulting in a 10-fold difference in productivity between teams.
A great engineer is a group of people who are twice as productive individually as the rest of the group, and 10 times more productive as a team.
In recent years, the development speed of the front-end field is very fast, and the talent distribution shows a bifurcated trend. Everyone is saying that there is a lack of front-end, but in fact, there is a lack of excellent front-end. For the low-end front-end, training institutions have been in mass production, but they cannot meet the requirements. In many cases, a great front-end is valuable to the team in a way that no amount of low-end front-end can provide.
Great front-end engineers have some common traits that may not be at the core of the front end, but can be identified by them.
The pursuit of user experience
Don’t assume that user experience should be controlled only by designers and product managers. The front-end engineer’s focus on the user experience directly affects the end result of the product.
No matter how detailed the design document is, there are still a lot of details in the product that the designer didn’t consider or default to, and those details need to be checked out by the front end engineer. The same design, handed to a front end that doesn’t care about the experience, has a significant roughness, and there’s a lot of additional cost to fill in that roughness.
The weakness of most visual designers today is their inability to understand products dynamically. For example, if we wanted to make a design, in the PC era we would make a fixed width, say 800 pixels, and have the engineers restore it. Then in the mobile era, we would have designers come up with two or three drafts for different screens. This is the lack of dynamic thinking measures to compensate, no matter how many width of the visual draft, are only the cross-section of the dynamic form.
Source of motivation
A lot of the people I meet who switch to the front end think it’s a low barrier to entry, so they start at the front. Such a person may be able to do basic work, but it is difficult to be excellent.
They come for more challenges and opportunities in the front end, not for job hunting. In fact, it’s hard to fill a senior front-end position, and we probably have one of the lowest interview approval rates for a senior front-end engineer in the R&D category.
Others say they are interested in the front end, so they switch to the front end. Interest in the front end should be based on interest in computers, interest in programming. If a person is interested in working on the front end, but is averse to working on the back end or other development positions, then question that interest. This person may not be a good fit for r&d.
Consciousness of the whole stack
When I say full stack, I don’t really want to do the same thing as a back-end engineer. For the separation of the front and back end, many people have a misunderstanding, understanding that the front end does not need to write background code. The real separation of the front and back ends refers to the separation of the system level, with a separate system at the front end, of course, with its own back end, and various auxiliary support systems. Code construction, release, online operation and maintenance, data statistics and monitoring should be understood, otherwise it is impossible to undertake a business independently.
A great front-end engineer is a great software engineer first and foremost. They don’t put limits on what they can do.
What the front end engineer does is extend the cross section into a finished product form.
The awesome front end can actively pursue the improvement of user experience and have basic understanding and aesthetic ability of interaction, UI and visual design. Even without the support of designers, it can still deliver products with good user experience.
Understand automated testing
A good front end doesn’t necessarily have a lot of hands-on experience with automated testing, but it does need to understand the basics associated with automated testing. The testability of the system itself is more important than the specific test case coverage. Striving for quality is not something to be done when you have more time. Striving for quality itself is a way to be more productive and thus give you more time. Automated testing is an essential part of front-end engineering construction. Although front-end automated testing has not yet formed a stable and widely used practice method, it will certainly not become an awesome front-end if automated testing is completely missing.
Pay attention to monitoring system
The primary front end sees the function, the intermediate front end sees the test, the advanced front end sees the monitoring.
The purpose of front-end monitoring is to get first-hand data from the user side after the product goes online, after all, the user side is really good to use.
At present, most companies are not doing enough to monitor the front end. Under the technology architecture of the front and back end separation, the front end must have its own set of monitoring system.
Most of the time the background monitoring is the result, combined with the front-end monitoring to analyze the cause. I, for example, such as daemon to real-time lost a lot of orders, and this is the final result, if there is a front-end monitoring, we’re going to have a look at the front end of availability, various pages of UV, load performance, each interaction link clicks, the performance of each interface and error of ratio, the amount of front-end code error and location, and then locate out the problem.
Engineers who have really experienced large projects and technical architecture will pay attention to the construction of monitoring systems.
Good monitoring requires a good view of the big picture, on the one hand, of the product, including thinking about how users will use the product, how to quantify those behaviors, and the expected changes in data at each stage. The other side is the big picture of the technology, understanding how the different modules of the overall technology architecture work together and measuring whether they are working properly.
conclusion
The top end certainly doesn’t just spend time on browsers, but they share a commitment to user experience, a can-do drive, a full stack awareness, and an emphasis on automated testing and data monitoring. In addition to the basic knowledge, the control of the surrounding system is the most distinguished.