Three thoughts necessary for excellent engineers, continuously updated
Guide
Technical people of different positions and responsibilities have different requirements for the depth of thinking of engineers, but thinking from multiple dimensions should be the quality that every technical person should possess. I hope that everyone can correctly treat those points and things that seem to be irrelevant to their own positions in real work, but have a great impact on team effectiveness.
In the context of social division of labor, the group of engineers in the software industry is divided into many positions such as development, testing, and products, and they work together to create value in a collaborative manner. The Internet industry, which is highly dependent on software, is improving people’s lives in a brand new way. At the same time, it puts forward higher requirements on the effectiveness of value creation on the road of improvement, and behind it is a higher demand for the effectiveness of collaboration between individuals and teams. .
The biggest challenge faced by the special-person and dedicated-post collaboration model in further improving the team’s collaboration effectiveness lies in the “post wall”, that is, there will inevitably be some fuzzy areas in the connection between posts, and these fuzzy areas are easy to ignore each other and cause loss of attention And greatly reduced the effectiveness of the team. For example, a development engineer will think that quality assurance is a test engineer’s unilateral responsibility; a development engineer does not care about user experience but only needs to focus on implementation, and so on. In addition, this collaborative model will also solidify the individual’s thinking and mental models, and frame the individual’s thinking and mind within the post, so that the content outside the post cannot be understood well, and the individual is involved in the entire collaborative activities. There will be a lack of empathy and systemicity, which will affect work happiness.
I believe that readers of these real work scenarios are not unfamiliar:
● Development engineers think that the user experience requirements put forward by product engineers are too critical;
● Product engineers do not understand the implementation principles of technology and put forward unreasonable and ungrounded requirements (we This special case of innovation is not discussed here);
● Test engineers turn their work into manual work because they don’t understand the connotation of engineering efficiency;
● Development engineers are not clear about their own responsibilities for software quality, and instead do their own work. Good trivial work is handed over to the test engineer to do it comfortably;
● Users complain about the hard-to-use functions developed through hard work.
The final result of these problems must be the low efficiency of teamwork. So in the absence of a better collaboration model than dedicated personnel, how can we use individual strength to improve team collaboration effectiveness? The starting point for improvement is to comprehensively sort out the thinking of engineers, help individual engineers to establish a more comprehensive thinking and vision in the workplace and career development, so as to encourage each engineer to maximize individual abilities in the process of collaboration to promote team collaboration efficiency The promotion.
I decompose the thinking of engineers into three thinkings of product, technology and engineering. The main concern of each dimension is expressed by several keywords, as shown in the figure below. In the following, each word that needs attention for each kind of thinking is explained in the order from top to bottom in the figure. Since the explanation is based on keywords, the connection between paragraphs may appear blunt. Please forgive me.
Product thinking
The origin of product thinking is user (or customer) value. User value is to solve the user's pain points or bring refreshing points in the form of products or services through technical means. Undoubtedly, engineers should always pay attention to and clarify the connection between their work and user (or customer) value in their daily work, and should prioritize work and allocate their energy by focusing on user value.
When the user value is sufficient, whether the product can gain a foothold in the market and truly reap the benefits, the first test is the user experience of the product. A good user experience must be based on the user’s point of view to shape the concept based on the user’s mind. Because the concept has the cost of understanding and interpretation, the concept should be light enough, small and easy to grasp. Once the concept is shaped, the relationship between the concepts is also determined. These relationships basically determine the interaction process between the product and the user. A good product is embodied in the word "easy to use", and its ultimate is to cater to the user's instinctive reaction and conform to various life or professional common sense.
All products have a process of evolution, and the created user value is constantly being explored and explored. At that time, different refined values need to be distinguished and expressed through product characteristics. Features are also a manifestation of product differentiation. Features also indirectly determine the functional module boundaries at the software implementation level. As a development engineer, you also need to have a very thorough understanding of product characteristics, and be able to abstract and convert them into functional modules at the software implementation level. Features need to be considered to be turned on or off through sales licenses and other forms to achieve sales, which is very necessary for 2B products.
In order to better evolve the product, it is necessary to test the effect of creating user value through the form of closed-loop data, so that product development, operation, and marketing can be targeted. On the road of product value creation, the most fearful thing is to just bow your head and do additions, doing so much but no one cares about the results. And through the form of data-based closed-loop, not only can the entire product team focus on the core value, but also help the team rationally subtract on the road of exploring user value. In most cases, subtraction is far more difficult than addition.
Technical thinking
The source of technical thinking is demand. Demand can be divided into different levels, such as market demand, system demand, and feature demand, and it answers the question of "what to do" at the technical level. Obviously, clearly expressed requirements and precise understanding of requirements can ensure that things are done right. Undoubtedly, the waste caused by deviations in requirements is very serious, and because of this, engineers attach great importance to the quality of requirements.
Once the requirements are established, they will be split into multiple functional modules based on the idea of modularity to reduce the local complexity of the implementation, and finally all functional modules will be "spliced" together to achieve the overall requirements. Each functional module will be assigned to a person or a team. Because functional modules are the product of requirements decomposition, it is easy for engineers to only see "trees" and forget "forests" in the process of implementation.
Performance is what engineers have to pay attention to when implementing a functional module, especially when the functional module is used in high-frequency, time-sensitive, and limited computing power occasions. In reality, sometimes there are engineers who are willing to pursue the ultimate in performance to reflect their technical strength, and even the misunderstanding of over-designing by pursuing performance too early.
There is no doubt that a formal team will usually complete the delivery of the functional module development work in a project-based and multiple iteration manner. Many engineers have a misunderstanding here, forgetting that "the purpose of project planning is to adapt to changes" advocated by agile thinking, but regards "delivering on time" as a bounden duty. When all kinds of rushing to the end are not surprising I saw the sight of "a place of chicken feathers".
On the road to the fourth industrial revolution, artificial intelligence, big data, machine learning, Kubernetes, Istio, Knative, Go, Dart, Flutter and other new technologies continue to impact the skills that engineers have mastered. Quickly keeping up with the iterative pace of technology is one of the performances of every aspiring engineer continuously improving his professionalism. Engineers must not lack the pursuit of new technology in their hearts, and they hope that the technology they have mastered has a certain degree of advancement.
Engineering thinking
The starting point of engineering thinking is the process. Behind the process is science, with established steps and phased input/output to complete value creation, and process control to ensure that the final result is satisfactory. Since the process involves the work quality and efficiency of each engineer, its meaning is not only in definition, tooling, inspection, etc., but also in seamless integration of the process and the engineer’s working environment based on the engineer’s daily work habits. The concept of "seamless" embodied in the process is consistent with the professional common sense established by the engineer community, without adding a worthless burden, and still ensuring ease of use.
The meaning of the mechanism is to solve similar problems in a mode by analyzing the problems to be solved. The mechanism should reflect a certain degree of systemicity, rather than "headache cures head, foot pain cures feet". Systemicity cannot be discerned from the beginning, it may be discovered and improved gradually in the course of evolution, which requires engineers to review and implement them in practice from time to time during the work process. For engineers, the mechanism is achieved through systematic software design.
It can be said that product quality directly determines the happiness of work and life of engineers. A product of unreliable quality will definitely bring troubles to users and engineers themselves, and even cause irreparable economic losses and negative social impacts. For engineers, that is bound to disrupt the individual's work and life rhythm. In order to make the quality of the product reliable, the means to ensure the quality of the project such as unit testing, static analysis, and dynamic analysis should become the basic work content of the engineer. By integrating these means with the CI (Continuous Integration) process to continuously build the software Product quality confidence.
In the Internet industry, in addition to the reliable quality of software products, controllable risks are another content that cannot be ignored. The controllable risk is based on a systematic mechanism and reliable quality. This is even more true for server-side software. Risks often appear in extreme scenarios of resource usage. When the influx of too many transactions from the outside far exceeds the processing capacity of the software product, a certain mechanism is required for the entire product to respond relatively smoothly, or expand resources or limit Flow into the transaction.
The machine cost required by software is a topic that is relatively easy to overlook. Software cost is not only related to software performance, but also related to factors such as software dependencies and technical solutions. When a piece of software needs to be exported from the company's internal and external, usually neglecting the concern about cost will expose the cost problem. For example, in order to run a certain software, a huge amount of computing resources are required, and the resulting capital expenditure may be unacceptable for customers.
So far, I have roughly introduced the engineer thinking that I understand.
extend
The value of understanding the thinking of engineers is that individual engineers need to gradually establish the three major thinking of product, technology and engineering in their work in order to look at the difficulties and confusions they face in daily work with a more comprehensive perspective. It may feel unreasonable when looking at the problems faced from a single thinking, but the conclusions obtained from the three levels of thinking may be completely opposite. From the perspective of teamwork, only when there are more individuals in the team thinking from multiple dimensions, can it be easier to find those unattended gray areas where the positions are connected, and then use supplements and assists to
maximize the team’s performance. efficacy.
Obviously, engineers of different positions and different responsibilities have different requirements for the depth of these three thinkings, but thinking from multiple dimensions should be the quality that every engineer should possess.