How can engineers improve themselves at work?

The introduction

As an ancient saying goes, “Live and learn.” The Internet is one of the most laborious industries, “overtime” for engineers has been “common”, at the same time the Internet technology changes rapidly, many engineers are tired to cope with, complaining. So much so that there has long been a widespread misconception that 35 is the end of a programmer’s career.

How to do a good job in the busy work of technical accumulation, build personal core competitiveness, I believe that many engineers are thinking about the problem. This article is my own summary, trying to answer from three aspects:

The first part describes some principles of learning. At all times, following some tried and tested principles is an important factor affecting efficiency, and the right approach is the secret to success.
Another important factor to improve the efficiency of work and study is confusion and a good attitude. The second part analyzes some typical puzzles I encounter and see in my work.
Becoming a good architect is a phased goal for most junior and middle level engineers. The third part analyzes the capability model of the architect, so that we can have a clear understanding of the required capability of the goal.

How to learn

In a busy work, perseverance, continuous learning and progress is a difficult task, requires strong perseverance and determination. If the method is not appropriate, it is twice the effort. Fortunately, our ancient and modern philosophers have summarized many excellent learning methods. Here are some important principles. Following these methods will be of great benefit to everyone’s work and study.

in

It has been reported that the amount of knowledge accumulated in the past few decades exceeds the sum of the previous thousands of years of human knowledge. Computing is one of the most rapidly evolving fields of knowledge in modern times, so engineers must accept that their deep knowledge will soon be obsolete. In order to continue to be a good architect in the computer field, you must constantly learn and master the latest technology. In a word, learning can not have.

The so-called “Rome was not built in a day”, the road to the architect is long and arduous, easily give up, all pay instantly in vain. To be a good architect, you need to be persistent!

Although knowledge changes rapidly, the underlying theories change very slowly. This is the relationship between “Tao” and “image”. Even though there are all things in the world, Tao never changes. For those very basic theoretical knowledge, we need to review frequently, that is, “learn while learning”.

Attaches great importance to the practice

The ancients cloud: “the paper come zhongjue shallow, must know this to practice.” The learning field has the so-called 721 model: 70% of personal growth comes from on-the-job practice, 20% from learning from others, and 10% from training. While this theory is controversial, it is roughly fine for engineers to prioritize in terms of practice, learning and training. Therefore, attaching importance to practice and growing up in practice is the most important learning principle.

There are two kinds of human cognition: perceptual cognition and rational cognition. The two cognitions are mutually irreplaceable. Practice comes largely from emotional learning. Reading books is more like rational learning. Take learning to drive a car for example, it is hard to imagine that anyone can drive a car simply by learning from books.

Book knowledge is mainly evangelism — the description of abstract archetypes, but the description of their concrete application is often vague and the relationship between abstract archetypes is only scratched. Using the same precise language to describe application scenarios and relationships would lose focus and confuse people. So, just reading books to grow is like walking with one leg.

The right way to learn is to pay attention to practice, make full use of perceptual and cognitive potential, and hone yourself in projects. In practice, deliberate practice on some key movements will also achieve twice the result with half the effort.

Pay attention to communication

Newton said, “If I have seen farther than others, it is because I have stood on the shoulders of giants.” We need to learn from others. Learning from teachers, leaders, colleagues, subordinates, and even rivals is an important way to grow quickly.

Learning from teachers and leaders has been a part of people’s life habits. But it’s also important to learn from colleagues and even rivals who are more like us. Therefore, we should observe more, take its advantages, and abandon its weaknesses. For the team’s younger brothers and subordinates, also want to “do not shame subordinates”.

In addition, it is also important to actively participate in the discussion of specific plans during the project. The participants have a priori perception of the relevant background, and the views and suggestions discussed are also integrated with the speaker’s various knowledge and skills. Therefore, discussion allows participants to have a very comprehensive and three-dimensional understanding of book knowledge. At the same time, discuss with the master, their views will be like a pruner to cut the branches, quickly cut off their own knowledge in the field of doubt.

Focus on summary and output

Engineers will master a lot of details in practice, but even if they master all the details, they will fall into the situation of “learning without thinking is lost” without deep summary and thinking. The “quantitative change” of growth comes from the gradual and in-depth control of details, and the real “qualitative change” comes from a deeper understanding of the “Tao”.

Putting your experience out there and having it tested by others is a high-level summary. This kind of output not only helps others, but also helps oneself. There are many ways to summarize, including organizing sharing, writing technical articles and so on. Of course, “three days to check my body” is also a good way to sum up. In short, a lot of summary, a lot of sharing, nothing!

Answering other people’s questions is also an important means of personal growth. Sometimes, a problem is not quite understood by oneself, but when explaining it to others, it suddenly becomes clear. Therefore, “teach others tirelessly” to benefit others and yourself.

Attaches great importance to the planning

Forethought makes sense, unforethought makes waste. For a long learning career, a good plan is half the battle.

Long-term planning

Long-term planning takes perseverance and determination to implement, but getting it right also requires a vision, a super-sensitive nerve and a bit of luck hitting the jackpot. For most people, long-term planning is mainly about “setting direction”. However, following these principles can reduce the chances of making a wrong direction:

Stay away from the sunset industry.
Do things that interest you.
Do things that add up.
See while walking, do not go all the way to black.

Short term planning

Good short-term planning should strike a balance between life, growth, performance and promotion. Most companies have a review cycle — as little as a month, as much as a year. So we might as well take the assessment cycle as a short-term learning planning cycle. In essence, planning is a multi-objective optimization problem, which has a series of theoretical solutions, which will not be detailed here. Based on relevant theories, I propose a simple and feasible scheme:

Prioritize your goals. For example: growth, life, performance.
Determine a lower limit for each goal. From the perspective of optimization theory, this is called a constraint. Your performance must be above average, your planned trip cannot be changed, you must have read Effective Java, and so on.
Prioritize allocating adequate resources to lower-bound goals. For example, if a pre-planned trip takes 10 days, those 10 days must be budgeted for.
Allocate resources in the order of the main objectives. For example, the final time allotted to study is 10 days.
Be aggressive in setting learning goals for a given learning budget. Then the implementation scheme is given. For example, the goal is to master basic statistics and become an expert in Java. Specific plan: Complete the reading of Effective Java, Java Performance, Design Pattern and Head First Statistics.
Prioritize each learning task in the plan according to the goal priority, and start the task with the highest priority first. For example, if mastering statistical theory is the highest priority, Head First Statistics is the First.

For this scenario, note the following:

The minimum goal must be easily attainable, otherwise, from the point of view of optimization theory, the proposition has no solution. For example, something like “get two promotions within six months, get all S’s, go from novice to Java expert” is not a good minimum goal. In short, make a distinction between ideals and dreams.
Major goal planning must be challenging and require impossible goals. Overplanning is essentially a greedy algorithm that aims to maximize the target value. Since everything is in flux, use that time to accomplish more learning goals if you can accomplish other goals earlier. In short, the future must be bright, but the road must be bumpy.
Goals do not necessarily share resources and programs do not necessarily conflict with each other.

In addition, short-term planning can also be optimized from the following aspects:

The study plan had better be able to combine the work plan, the theory contacts the actual union, quick study applies to practice. For example, if you plan to do some data analysis work this quarter, you might as well set your learning goal to learn statistics.
Be flexible about the goals and steps of the plan, and avoid “zheng buying shoes” jokes. In the face of new challenges and changes, programs need to be constantly adjusted.

The agonizing confusion

Life is a marathon, and there’s a lot of confusion along the way. Confusion is like a shackle, holding us back. Confusion is like a deadlock, holding us back.

What follows is a summary of some typical puzzles I encounter and see at work. These puzzles have long puzzled the author himself, or colleagues and friends around me. When the confusion is resolved, everyone feels liberated and provides positive energy for the next stage of the journey. Life is like a journey, do not care about the destination, care about, should be the scenery along the way, and the mood at the view. A good mental attitude is the best companion on the technology journey. We hope that we can have a happy mood to feel the long learning journey through this journey.

Is there no end to learning

We must admit a cruel reality: human life is limited, but knowledge is infinite. Using limited life to learn infinite knowledge is an impossible task. Some engineers get a little gloomy at the thought. Sorrow is not necessary if done properly and diligently.

Yet the whole body of human knowledge is expanding all the time. However, for many important engineering subdivisions, the basic theory is not profound. In many important areas of computing, engineers have the ability to get to the heart of the matter in limited time.

Cryptography, for example, is considered to be a very sophisticated science, but the basis of a large class of cryptography is a very simple theory of number theory called prime factorization: given two prime numbers, it is easy to compute their product, whereas given the product of two prime numbers, the computation of the factorization is very surprising.

“Consistency” is the most classic problem in the field of computer. It is the foundation of all distributed systems, from multi-core and multi-CPU to multi-thread, from cross-machine to cross-machine room, everywhere. Almost all computer practitioners are trying to solve this problem, but Paxos provides a very elegant solution.

Permission management is a nightmare for many engineers, but if you can handle “Attribute Based Access Control(ABAC)” and “role-based Access Control(RBAC)”, you can go quite far.

In addition, technical learning is a competitive game, although learning is endless, and overtaking most opponents is a victory. Therefore, in the right way of learning, long-term investment will form core competitiveness.

There is no absolutely brilliant technology, only the real master

Engineers who devote themselves to technical achievements dream of becoming technical masters one day. But the criteria for being a tech whiz are highly controversial. It’s a time-honored misconception that technical excellence is judged by mastery of a certain skill. I often see engineers claiming to be masters of some technology like Spring, Kafka, Elasticsearch, etc. Some engineers admire another team because that team uses a certain technology.

There are several reasons for this misunderstanding. First of all, the more skills you have, the better. People who have many skills are not newbies. Second, before the advent of the Internet, access to information was very expensive. This leads to a skill that can give an individual or even an entire company an advantage. In the Internet era, the emergence of various frameworks and the popularity of open source have rapidly eliminated or reduced the value of many skills and lowered the threshold for learning many technologies. Therefore, at present, acquiring knowledge of a certain skill is only a short-term goal. People who are complacent with certain skills need to remember that pride takes a back seat.

Small as a sparrow is, it has all five organs. If you were the creator, the complexity of designing sparrows and elephants is not significantly different. A seemingly small business requirement requires a very comprehensive and sophisticated set of skills and capabilities in order to achieve perfection. The real master is not to take the mastered technology to meet customer needs, but to listen to customer needs, to give better solutions. To meet the needs of customers is a challenge, the real master, is to meet the open move.

Can’t grow without projects

Learning on a project is one of the fastest ways to grow, and many engineers enjoy the process. But doing projects all year round, you might be working for an outsourcing company. For a product company, if you are doing projects to the end of the year, either in the initial start-up stage, or a lot of failed projects, it is not a particularly ideal state. Normally, there will be some non-project time between projects. During this time, some students will be confused and grow slowly.

Are more projects really better? The answer is clearly no. Repetitive projects do not lead to new growth for engineers. Working on projects without time to learn something new leads to the danger of doing without learning. What really makes an engineer outstanding is the depth of the project, not the incessant work on it. Therefore, in the gap period between projects, engineers should cherish the rare breathing space, in-depth thinking, the project to do deep, do fine.

How do you increase the depth of the project? Generally speaking, any project has a goal, and when the project is complete, the goal is basically achieved. But are customers really satisfied? Is the system as usable, reliable, scalable, and maintainable as it can be? The answer to these questions is always no. So, any worthwhile project, you can always dig deep. Digging deep into projects and thinking deeply can also exercise engineers’ creativity. A person who expects to keep working on projects, like a person who focuses on training more swift horses, can’t invent a car. Building creativity isn’t something you do overnight. It takes a lot of thinking. In short, engineers should always feel short of time, because time is the most precious resource.

Is the responsibility really small

Most of the time, the number of systems an engineer works on and the size of the team has a positive correlation with their “status”. However, there is no necessary correlation between the social status and technological growth. The key to improving technical capabilities is project depth and customer pickiness. The more projects you have, the less time you have to invest in a single project and the more superficial it is. In particular, it is necessary to avoid the situation of “neglecting to govern in their own place”. The bigger the team, the more effort it takes to manage it. Being forced to take charge of a large team on the premise that management skills are not mature and technical vision is not high enough may lead to personal fatigue and no achievements of the team. In the end, “one general is incompetent and exhausted”, the effect may be counterproductive.

From the perspective of technology development, technology managers should pay attention to the number of active projects they can control, and strive to improve the influence and technical depth of active projects. Team size should be commensurate with individual management ability, planning ability and demand control ability. When more than one person does a job, each person’s growth is limited. Everyone doing simple repetitive work is not good for technical growth. Team management and project management need to step by step, avoid “pulling out the seedlings to encourage”.

Do you have to be the boss

There are some engineers whose life ambition is to be the technical boss of the team, which is certainly a praiseworthy ideal. However, if the team is average in technical ability and growth potential, and you are the most skilled, that is more sad than lucky. This scenario is called “Wu Dalang shop”. It’s not impossible to be a top performer on the team, but in order to continue to grow, the following conditions need to be met:

You need to be the top expert in your field — it’s hard to find anyone better than you!
Secondly, you often have to take on tasks that challenge your own abilities, but at the same time you have a team of smart and capable people. Although you are the most technically competent, your teammates will be able to explore and expand the group’s knowledge in areas that are unfamiliar to you.
Finally, you must be quick to learn and ask questions.

Otherwise, joining a stronger technical team might be a better choice, at least not something to be proud of.

The legend of platformization

Platformization is a synonym for “high and powerful,” and many engineers fight to be part of it. However, platforming requirements are not fundamentally different from other business requirements. Whether it is a platform requirement or a general business requirement, its value comes from customer value. The differences are as follows:

Many platform-based requirements come from the technical team, while common requirements come from the business side.
Product managers are different. Common business requirements come from the product manager, and the product manager for platform requirements may be the engineer himself. Engineers, who have been “oppressed” by product managers for a long time, finally find the feeling of “emancipating serfs and singing” on the platform.
A lot of platformization is about access and scalability, and more about normal business.

Ultimately, platformization is a common need. Before implementing platformization, it is important to avoid the following two pitfalls:

Platformization is definitely not the accumulation of adjectives such as “unified” and “comprehensive”. Whether platformization is needed should be considered comprehensively: the number of customers, the problems solved for customers, and whether the customer value is worth the investment in platformization.
Platformization is not about making a platform and letting customers serve you. Some platform designers, in their planning and design, hand over a lot of platform access work, the dirty work to the customer, and then focus on the so-called “top” function. On the contrary, platformization should mean that the customer does nothing and the platform side does all the dirty work. In essence, the value of platformization comes from technical depth. What really shows the depth of technology is that designers can easily do all the dirty work.

So the best practice for platformization is to solve the most problems with the least amount of resources. The platform solves everything and the customer reaps the benefits.

Do gay technology must be very good

I often hear students express their admiration for students in the basic technology department, but despise those engaged in business technology. They believe that only storage, message queue, service governance framework (such as OCTO used in Meituan review) and Hadoop can be called real technologies. That’s not the case. More basic is not necessarily deeper.

For example, there is a popular saying that the more advanced a language is, the less technical it is. But is that true? Take Java and C, which are two completely different languages and require completely different skills. C is probably closer to the operating system and more likely to deal with CPU and memory. But in order to use Java well, programmers must be proficient in object orientation, design patterns, and framework technologies. It is not easy for Java engineers to switch to C, but the author has also seen many C engineers who switch to Java.

The underlying technology and the business application technology are bound to have different concerns. There are two reasons for this misunderstanding:

The basic technology is relatively mature and has a relatively complete system, which gives people a lofty feeling. Business application technologies are relatively less impactful because they are used differently by each team.
The threshold for basic technologies is relatively high, and the minimum requirements for reliability and availability are high. However, high threshold does not mean high technology content. In addition, mature technologies are relatively constrained in innovation. But the most advanced technologies come from active innovation.

In contrast, business technology and basic technology are different. But the real masters focus on problem solving. All skills are just skills.

The holes in the feasibility study

In the work to carry out feasibility research from time to time. The following situations should be avoided when conducting feasibility research:

Turn a feasibility study into an infeasibility study. It’s really bad. The conclusion of infeasibility is often: for one reason or another, it doesn’t work.
Avoid the “mouse to bell the cat” high-risk scenario. As a Chinese saying goes, “important things in the world must be done in detail.” Feasibility research must be meticulous and avoid carelessness.
Avoid taking too long to research. If you find that your research is getting exponentially complex, requiring twice as much time per step, you should stop your research.

The conclusion of the feasibility study should be a compromise between benefits and costs, and the format is generally as follows:

First, identify the expected results and grade them in terms of high, medium and low returns.
Describe the actions and programs required to achieve each desired outcome.
Give the cost of implementing each plan.

Are engineers inherently bad communicators

In practical work, problems caused by communication emerge one after another. Many engineers are introverted and often labeled as “poor communicators.” In fact, communication ability is one of the most important abilities of engineers. Good communication is the foundation of efficient work and study, and can be mastered through learning. Let me talk about communication in the language of an engineer.

The first common problem is the reliability of communication. In terms of reliability, communication is divided into TCP mode and UDP mode. The TCP model is visually stated: I know you know. UDP mode is visually stated: hope you know. TCP is of course more reliable, but the cost is higher, while UDP is cheaper, but not reliable. In terms of communication reliability, there are two common errors:

This argument is often heard. One side says, “I’ve told him so.” The other side says, “I didn’t know that.” Using UDP as TCP is easy to dispute.
Overcommunicate. Some students have excessive anxiety about the reliability of communication and repeatedly discuss the existing problems. If the TCP mode is used as UDP, the efficiency is low.

The second type of communication problem is timeliness. In terms of timeliness, communication can be divided into synchronous mode and asynchronous mode. I need you to listen up right now. The visual expression of asynchronous communication is: Remember to do it for me. There are two common mistakes in communication timeliness:

We’ve got an online incident. It’s an emergency. We talked and talked, feeling that the accident might be related to several people, but we could not be completely sure, so we did not inform the relevant people. Eventually, an ordinary accident became a serious one. For urgent matters, communication must be synchronized.
You’re asleep at 3am, or shopping on the weekend, when you get a call saying, “I need something I can do right now.” It can be very frustrating because it’s not an emergency. Not all needs need to be addressed immediately.

An important principle of effective communication is to communicate in advance. The essence of communication is information exchange and processing, which can be likened to a SERIAL information processing CPU. Communicating ahead of time means putting processing requests into the processing queue as early as possible. Here’s an example that many engineers hate: a requirement that took a month to plan and a product that took two weeks to design. When the development project first heard about the requirement, it found that the development time was 2 days. The engineer argued hard and worked overtime for a week. The final conclusion was that the engineer was very unhelpful and uncooperative. Just as engineers hate such requirements. To coordinate a big project and get the cooperation of others, early communication is also necessary.

Another key to effective communication is “staying on topic”. Many seemingly similar problems are fundamentally different. For example, if the topic of a meeting is “How to implement a plan”, someone may ask “Should we implement the plan?” “How to do it” and “should it be done?” are two completely different questions, and many of the seemingly related questions are actually quite beside the point. “Off topic” is an important cause of ineffective communication.

The secret of good communication is to master the essence of TCP mode and UDP mode, correctly judge the urgency of the problem, communicate in advance as far as possible, and avoid getting off topic.

Take the way of people

Some first-time mentor engineers, worried that graduates would be too weak to teach them, ended up writing their own code. The same thing happens to many engineers who have just managed small teams. The end result: they write all the code, leaving their subordinates with nothing to write. Of course, “trying to do everything yourself” sucks, and the result is often poor overall team performance, slow growth of team members, and fatigue.

The ancients said, “No doubt about people, no doubt about people.” The saying is not “one-size-fits-all.” In ancient times, limited by communication technology, feedback delay was significant, and there was a lot of noise and serious deformation in the process of information transmission. In this case, making quick decisions based on a small amount of deformation information gathered in a short period of time can easily lead to rash decisions. In a company, this phrase is more appropriate for the selection process, should be: hire no doubt, doubt people do not hire.

Even at the hiring level, sometimes it’s not possible, given the cost of hiring. As a manager of a small team, I can quickly and accurately obtain all kinds of feedback information from team members, and there is no need to “doubt people, doubt people”. The real theoretical basis for human employment lies in Exploration and Exploitation. Don’t ask your subordinate to do something just because he can do it, and don’t deny him an opportunity just because he failed once.

According to the classic theory of Exploration and Exploitation, good human use is as follows:

The first choice is to believe, and in the face of failure, to shrink trust.
Find out the cause of failure, provide improvement advice, improve subordinates’ ability.
Always give your subordinates a chance and give them a higher challenge at the right time. In short, the sky tree from a small seed, to believe in the power of growth.

Efficiency, efficiency, efficiency

It is common to see some students give their performance score of 100 – full marks, because in the past period of time too hard, but the final performance is so-so. God rewards those who work hard, but god rewards those who work well. Engineers have all learned about data structures, and the time complexity of different algorithms can’t be bridged simply by working longer hours. In order to improve work and study efficiency, we need to pay attention to the following points:

Focus on efficiency. In many cases, the benefits of extra time are dwarfed by the benefits of increased efficiency.
Have clear results-oriented thinking. Credit and hard work are not the same thing.
Do the right thing, not just do the right thing. It’s a recurring topic, but mistakes are made every day. There are always trade-offs in order to finish a big project in a given time. If there is no focus, even force, easy to get twice the result. If the opposite is true, it is even more deplorable.

Architect competency model

Now that we’ve covered the rules and confusion, how can engineers improve themselves?

Becoming a good architect is a phased goal for most junior and middle level engineers. Good architects tend to have seven core competencies: programming, debugging, compilation and deployment, performance optimization, business architecture, online operation and maintenance, project management, and planning.

The relationship between these abilities is roughly shown below. The ability to program, debug, and compile and deploy are among the most basic capabilities. Without mastery of these three capabilities, it is difficult to achieve performance optimization capabilities and business architecture capabilities. Only with certain performance optimization capabilities and business architecture capabilities can they perform well in online operation and maintenance capabilities and project management capabilities. Team management ability is the highest ability, which is more dependent on project management ability.

Programming ability

For engineers, programming is the most basic ability, a necessary skill. It is essentially a translation capability that translates business requirements into a language that machines can understand.

There are many books on improving your programming skills. Mastery of object orientation and design patterns is fundamental to effective programming. Junior engineers should write and read more code. Looking for an expert to do Code Review is also a shortcut to improve your programming skills.

Debug ability

Program code is a static form of the system, and the purpose of debugging is to verify and optimize the system by looking at the runtime state of the program. Essentially, engineers are constantly debugging to improve their ability to predict the state of operation from static code. Therefore, debugging ability is also a key means to improve the programming ability of engineers. Long ago, there was a legend: “As good as debugging, so good as programming.” But now that many editors are so powerful, the bar for debugging capability has been lowered.

Debugging capability is the key to timely and high-quality project delivery. Most engineers can’t complete a project with even a slight degree of complexity all at once. Large projects are optimized and corrected through continuous debugging. So the ability to debug is an indispensable ability.

Writing more programs, solving bugs and consulting experts is an important means to improve debugging ability.

Compile and deploy capability

Compiling and deploying the running program online is the last step in bringing the system online. With the popularity of SOA architectures and the increase of business complexity, most systems are just one part of a complete business, so local compilation and running cannot fully simulate the online operation of systems. To quickly verify the correctness of the program, compiling and deploying it online becomes necessary. So the ability to compile and deploy is a required skill.

Getting so many interconnected subsystems up and running is no small challenge. Thanks to the ubiquity of SOA architectures and the proliferation of compile and deploy tools, the barriers to compile and deploy have been lowered. In companies that develop at the application layer, there are very few “compiler engineers” anymore. But compiling and deploying is still no picnic for junior engineers.

Performance optimization capability

An important measure of a system’s success is usage. As usage increases and business complexity increases, most systems will eventually encounter performance issues. Performance optimization capability is a comprehensive capability. Because:

Many factors affect system performance, including data structure, operating system, vM, CPU, storage, and network. In order to tune system performance, the architect needs to master all relevant technologies.
Mastery of performance tuning means a deep understanding of the nature of availability, reliability, consistency, maintainability, scalability, and more.
Performance optimization is strongly coupled to the business, and the ultimate approach is often a compromise. Therefore, performance optimization is about mastering the art of compromise.

It can be said that the ability to optimize performance is a sign of the convergence of skills as engineers grow up. See the previous blog post “Summary of Common Performance Tuning Strategies” for this. There are a number of books on performance optimization that you can refer to. Reading the documentation and code in open source frameworks for performance optimization is also a good way to improve. Hands-on solutions to online performance problems are also key to improving performance optimization capabilities. If you have the opportunity, learn from the best and analyze performance optimization solutions (we’ve written a lot about this in the past on our tech blog), which is a great way to quickly improve your performance optimization capabilities.

Online operation and maintenance capability

If the performance optimization ability reflects the static thinking ability of the architect, the online operation and maintenance ability tests the dynamic reaction ability. The harsh reality is that no matter how perfect your program is, there will always be bugs. At the same time, the higher the position, the greater the responsibility, many architects are responsible for very important online systems. Online failures can be catastrophic if they are not prevented and resolved quickly, so online operations are a must for a good architect.

Standardized monitoring, reporting, escalation, and basic coping mechanisms are of course important in order to quickly deal with online failures. It is also critical to quickly locate, alleviate, and resolve the symptoms observed. This requires the architect to have a thorough understanding of the business and technology of the failing system. An architect who fixes online glitches is like a F1 driver. A racing driver has to understand himself, his car, his opponents, his peers, the weather, the venue — all factors — to make quick decisions and make constant adjustments. The architect must understand all the technical details, business details, processing specifications, peers, and many other factors to make quick decisions and make quick adjustments.

Online operation is essentially a process of reinforcement learning. Many abilities can be completed by reading books and looking up materials, but online operation and maintenance skills often need a lot of practice to improve.

Business Architecture capability

Stories of engineers complaining about product managers are common, and the main reason for the most complaints is that requirements change frequently. There are two main sources of demand change: the first reason is market change or strategic adjustment, and the second reason is pseudo demand. For the first reason, both engineers and product managers have to reluctantly accept it. A good architect should be able to reduce the probability of requirement changes due to the second cause.

Pseudo requirements arise for two reasons:

The first reason is demand transfer distortion. From the perspective of information theory, any communication is a process of encoding and decoding. A typical requirement goes through at least three coding and decoding processes, from the demander side to the product manager and eventually to the development engineer. With every passing of information there is some loss and some noise, which sometimes results in a product that doesn’t meet the requirements at all. In addition, weak control of demand feasibility, system reliability and development cost control on the demander side and product manager will also lead to demand distortion.

The second reason is that the demand side has completely failed to think about its own needs.

A good architect should be able to distinguish between real and fake requirements. Take the time to understand customers’ real business scenarios, have strong business abstraction ability, and understand customers’ real needs. The real implementation party of the system is the engineer. After identifying the real needs of customers, a smart architect should be able to accurately judge the project’s requirements on feasibility, reliability, availability and other aspects, and be cost conscious. Finally, due to the tight coupling between requirements and online systems, mastering the details of online systems is key to a successful business architecture. As the level rises, the requirements faced by engineers become more and more abstract. Taking on abstract requirements and providing abstract architectures is the only way for architects to excel.

There are several books out there on how to become an architect. But practice may be the more important way to improve architectural capabilities. Business architects should focus on customer pain points, not PRD documents, and dig deep into the real business. Mastery of the extensive technical and business details of existing systems is also essential knowledge for business architects.

Project management ability

As a product of the industrial age, division of labor and cooperation into the Internet project DNA. The architect also needs to be responsible for several major projects to clear his name. To manage projects in the role of architect, business architecture is certainly a required skill. In addition, people management and cost control consciousness are also very important.

Project management also means having a big heart. Major projects involve many variable factors such as technological breakthroughs, personnel changes and demand changes. Strong ability to work under pressure in the face of various changes and to ensure the smooth achievement of goals.

People management needs to pay attention to aspects including: know people and make good use of them, optimize relations, simplify communication, adhere to the truth.

Knowing how to use people means that the architect needs to understand the hard and soft skills of each participant. At the same time, pay attention to the performance of team members in the project process, according to the ability of allocation.
Optimizing relationships means managing the mood of the team. After all, the team is at the heart of the project, and a motivated team can achieve its goals effectively.
Simplified communication means quick decisions, compromise where necessary, and clear accountability.
Sticking to the truth means standing up to pressure and never backing down on matters of principle.

Cost control means the meticulous management of the project, which should follow the following principles:

Start with the end and set milestones. In order to achieve your goals, all plans must begin with the end in mind. Breaking a large project into smaller phases and controlling the milestones of each phase can greatly reduce the risk of project failure.
Control the critical path and key projects. According to the critical path Management Theory (CPM), the architect needs to determine the critical path for each subproject and determine its earliest and latest startup times. At the same time, the architect needs to focus on those key points that could delay the overall project and focus on cracking them.
Control the tension of team members. Large projects can last longer and involve different types of work. Project implementation is an ever-changing and dynamic process in which not the whole cycle is tense and not all types of work are equally busy. A good architect must be able to read the overall project in detail and react quickly and make adjustments in real time. This not only significantly reduces project costs, but also improves the quality of output and team satisfaction. Generally speaking, “tighten up and loosen up” is an important principle of project management.

There are many books on project management. However, improving business architecture capabilities is equally important. Getting involved in big projects and observing how others manage them are also important ways to improve.

Team management ability

An engineer who doesn’t want to be a CTO is not a good architect. Moving towards technical management should be a mainstream career plan for engineers. One of the core competencies of team management is planning, which includes project planning and personnel planning. Good planning follows the following principles:

Planning is a game of interests. Good planning is good for the boss above, good for yourself in the middle, good for the team below. Finding a balance point among the three stakeholders to achieve a win-win situation tests the wisdom and ability of managers.
Any planning is better than no planning. A team without a plan is a fly with its head cut off and is not in everyone’s interest.
Planning is not bookish. Markets change, teams change, and planning should not stay the same.
Customer first is the starting point of project planning.
In terms of personnel planning, planning needs to consider the ability, performance, growth and other factors of team members.

There are many books on planning management on the market that are worth reading. Optimization theory is a technical book, but it is the basis of planning, so take a look at it. Starting from self-planning, learning more from others’ planning is also an important means to improve planning ability.

conclusion

Invited to share “learning while working”, the author spent some time thinking and summarizing learning methodology. Then, he collected rumors and tried to dispel them every day. Based on his personal experience, he drew a model of the ability of a good architect, and finally compiled it into a book.

This paper systematically expounds learning principles, analyzes common puzzles, and sets clear learning objectives, hoping to help engineers in their work and learning. To be clear, the article is a blank, and the so-called architect competency model is also the author’s personal opinion. You are welcome to share your thoughts on learning and growth in the comments.

If you are interested in our team, you can follow uscolumn.