It has 2,835 characters and takes five minutes to read. The purpose of this paper is to construct my own cognitive model of the growth process of front-end engineers, analyze the relationship between the ability structure of Programmer, Developer and Enginner and the growth process of engineers from my own perspective, and share it with everyone, hoping to provide some reference and inspiration to the front-end students who are beginners. It should be noted in advance that the different terms of engineer used in the article are not intended to classify or label engineers, because the growth process of engineers is continuous, so please take a detour by yourself.

Programmer or engineer

There are many terms for students engaged in software development in the circle, such as Programmer, Developer, Engineer, and even code farmer. “code farmer” is used by people in the circle to make fun of themselves. How about other terms? It’s all about software development on the surface. Does it really matter what it’s called?

I have to say that the name is not important, no matter what he or she claims, what degree, years of work experience is not important, what really matters is the ability of a person. So since the name doesn’t matter? Why even talk about it? The real meaning of the name is to enable me to actively broaden their horizons, and constantly light up their skills tree, in the career development of the road to continue to accumulate, constantly improve.

What is the threefold realm of engineering? What does the term programmer, developer, and engineer have to do with this triple realm?

Level 1: Get things done

To get things done is the basic requirement of the company for employees. Most of the beginners are at this stage and they can be called “Programmer”. To tell him what to do and how to do it, he usually needs executive ability and basic skills. Basic programming skills, at least one programming language, familiarity with the language at least to enable him to solve basic needs. Specific to the front-end field, the requirement of Programmer is to be able to use JS, CSS, HTML, and be familiar with editors and browsers to complete the basic requirements.

Take the common WEB statistics as an example. In order to study the user behavior of key elements of the page, it is necessary to add event statistics (more commonly known as “buried points”) to some user interactions, such as click events and form submission events. If Baidu statistics is used, the method of burying points in the page is roughly as follows:

<a onclick="_hmt.push(['_trackEvent', 'checkout', 'click']);" > buy < / a >Copy the code

Or bury a point in JS:

_hmt.push(['_trackEvent', 'checkout', 'click']);Copy the code

Next, due to business needs, we need to send a copy of the same statistics to Google Analytics. The simplest and crude solution is as follows:

<a onclick="_hmt.push(['_trackEvent', 'checkout', 'click']); _gaq.push(['_trackEvent', 'checkout', 'click']);" > buy < / a >Copy the code

The same needs to be done in JS:

_hmt.push(['_trackEvent', 'checkout', 'click']); _gaq.push(['_trackEvent', 'checkout', 'click']);Copy the code

If your site’s page size and number of statistical events is small, it may be easier to change the burial point, but when the number of pages and events increases as the business grows, it is expected that programmers will bury the point and get cramps in their hands. At this point, Programmer won’t be happy, and probably Boss won’t be happy as well, because burying points is inefficient and error-prone. As a smart Programmer, solving a problem superficially is not enough. How to break the game?

Level 2: Getting things done

What skills do you have to get things done? Familiarity with basic skills exceeds (by a large margin) the need to get things done; Be proactive about business needs; A Developer is someone who can come up with a relatively robust technical solution, who can solve one class of problems at a time instead of one problem at a time, and who knows which solutions are off the wall.

Admittedly, Developer is an upgraded version of Programmer. By contrast, Developer mostly needs to find and implement solutions to problems by itself. In layman’s terms, facing specific technical and business problems, Developer can consider more points and come up with more solutions than Programmer. But to achieve these two “more”, it takes effort, time and experience.

Of course, the progress from Programmer to Developer can be accelerated. You need to compress your time to do more things in a shorter time. Note that this is not to repeat the same thing many times, otherwise it is easy to have 3 years of work experience and 6 months of work experience.

Going back to the burying point solution mentioned above, what’s the problem with a crude solution?

  • First of all, the code expansibility is poor. If the demand side needs to access self-built statistics later, the front-end workload is not reduced, but it needs to be more careful when changing.
  • Secondly, whether directly sending statistics can guarantee accurate delivery, whether there may be omission of the situation, careful students must be able to think of this risk;
  • Finally, front-end code style, it’s not really recommended to write JS events inline in HTML, which is a good example of dirty code;

How does Developer solve this problem? Buried first analyze the nature of the point code: send statistical movements, specify parameters, including sending statistical movements associated with need to access the statistics of the platform, to ensure that statistics also associated with this action, this action has nothing to do with statistical parameters, and statistical parameter itself more closely relationship with node, actions and parameters can be decoupled.

Based on this understanding, it is not difficult to design the following scheme, which specifies the marking method of parameters in all places that need to be buried, and uses the data-event-* parameter to mark the event name, event type and additional parameters:

<a data-event-name='checkout' data-event-type='click'> purchaseCopy the code

Then, listen at the page level for those buried nodes, and when appropriate, send the statistical code, simplified as follows:

// The same parameters are sent to all connected statistical platforms, if the platform is different, Const sendEventLog = (name, type, param) => {_hmt. Push (['_trackEvent', name, 'click', param]); _gaq.push(['_trackEvent', name, 'click', param]); }; // For the click event processing, $(body). On ('click', '[data-event-name][data-event-type="click"]', Const target = $(e.target); function (e) {const target = $(e.target); Const name = target.attr('data-event-name'); const param = target.attr('data-event-param') || ''; if (! name) { return; } sendEventLog(name, 'click', param); });Copy the code

As discussed above, the way from Programmer to Developer is accumulation, so how to accumulate? My basic rule of action is to make good things before you know what good things look like. On the one hand, read more classic books, carefully read high-quality articles, pay attention to this reading is far more important than collection, where to find classic books and high-quality articles? This requires the establishment of its own information screening mechanism; On the other hand, when you encounter problems, you should learn to search, find more solutions, and then compare them.

I have to admit that it takes a lot of efforts and accumulation to go from Programmer to Developer, but the road to improvement is endless. Here is the third realm.

The third realm: do things absolutely

The man who can do things perfectly can be called an Engineer. Then how can he do things perfectly? Statistical burying points, for example, provide insight into the nature of burying point requirements, decoupling log sending and burying marks to maximize both. In reality, the source of buried spot requirements is usually the operations and product managers, who are basically the driver of all change. If you can provide them with the tools to manage buried spot markers on the page. Xpaths, microservices, browser plugins, not detailed in this article) can free engineers from such trivial requirements to do more meaningful things, which can change the way different employees collaborate in an organization and improve its efficiency.

If you want to be a front-end engineer, you have to be an engineer. What should an engineer be capable of? To answer this question, consider what engineering is. WIKIPEDIA reads:

Engineering is the application of mathematics and scientific, economic, social, and practical knowledge in order to invent, innovate, design, build, maintain, research, and improve structures, machines, tools, systems, components, materials, processes, solutions, and organizations.

Simply put, engineering is the process of using knowledge to design, create, maintain, and improve tools, systems, processes, and organizations, and engineers are the primary drivers of this process.

Engineer, first of all to have the very strong learning ability, can grasp the complete knowledge system, the source of knowledge is not important, can from self-study, can also come from school, as well as the summary of the production practice, confined to a programming language or specific tools is not enough, for an engineer to switch to the new language doesn’t have any barrier, A solid foundation in computer science is the cornerstone. Specific to the front-end domain, basic data structures and algorithms, design patterns and paradigms, networks, JS, CSS, browsers, performance, design, software quality, maintainability, scalability, software engineering (construction, deployment, operation and maintenance, monitoring).

Engineers should also have good abstract thinking ability, with which they can quickly establish a thinking model of system operation mechanism, and transform real-world business problems into appropriate models, and then use technology to solve them. Specific to the front-end field, such as the typical information architecture of front-end applications, the application of data structures such as state machines, stacks and queues in the front-end.

Engineers, but also have good communication ability, communication ability is good or bad determines whether you can accurately understand the nature of the demand, whether can put their own design show clear to colleagues, and the form of communication is not so important, can be written, can be a whiteboard, mind map, or even an animated demo.

Engineers should also have the ability to balance and make choices, knowing where to do, where to do well, and where to do absolutely. Because the essence of engineering is to make choices, to strike a balance between business and technology, which is often overlooked by many people.

Rome was not built in a day, grow into a reliable front-end engineer can not be accomplished overnight, need a long time of accumulation and precipitation, and reach this realm after the end of it? Absolutely not. The biggest obstacle to a man’s progress is his mind. Again, progress never ends.

One More Thing

The author of this article is Wang Shijun. For commercial reprint, please contact the author for authorization. For non-commercial reprint, please indicate the source. If you found this article helpful, please give it a thumbs up! If you have any questions about the content of this article, please leave a comment. Want to know what I’ll write next? Please subscribe to my nuggets column or Zhihu column: Front End Weekly: Keeping you Up to date on the Front End.

Happy Hacking