Ali P8 architect talk: from “rookie” code farmers to “senior” architects

After working for a long time, I found an interesting phenomenon. From programmer and senior programmer to architect and expert now, with the improvement of technology and ability, there are more and more things I don’t understand.

Some of these questions come from the communication with my friends, some are my own questions and answers, and some are still unclear. This article will write about these questions.

How to study more efficiently?

A lot of new programmers have trouble learning at first, but I think most of these problems become less obvious and the direction of work becomes clearer after a period of time.

However, it was not long before the information I could learn began to exceed my daily learning ability, such as the books I had bought and the posts I had collected and the articles I had not paid attention to since I became a Mark, not to mention the new things I found in various technical sharing or micro-blogs.

Most people have limited time to study every day. At this stage, how to improve learning efficiency becomes the focus to be solved.

Tell me what you have learned to improve your learning efficiency. It’s very simple: systematic learning.

I used to like to read some blogs or articles that “looked” relatively easy to understand. Every day, I would Mark down any technical articles on Weibo and wechat and read them in a few minutes.

Can come down for a period of time, although read a lot of things, but there is still a kind of state in situ, and did not feel what actual improvement.

Finally, I could not help myself, holding a thick book and eating it again. Suddenly, I felt that what I had learned was a complete network of knowledge, and each knowledge point was related to and distinguished from other contents. This kind of comprehensive understanding is much higher than a single article.

After reading books for a period of time, the knowledge that was not in a system will be gradually connected, such as the development of back-end services. A brief overview will look like this:

After repeating the painful learning-sorting process for several times, it is often twice the result with half the effort to read some independent articles or materials, because corresponding knowledge can be found in the system, and sometimes only one sentence on a page of a book can be read and the layer of paper can be broken to master new knowledge.

How do you know all this?

I always encounter various problems in my work. I summed up the process of dealing with problems for several times and sent them out. After that, more and more friends came to consult me.

For example, I helped to troubleshoot a performance problem a while ago. When the system pressure was slightly higher, the FullGC would be frequent. After the pressure was reduced, the FullGC recovered.

A friend connected to the code quality check system and found that every build would report an inexplicable error, unable to open the package.

Once there was a Bug in my code, my friend came to me and asked me how git could roll back the code.

Every time I checked these questions, some of my friends, fresh out of school, would look at me with a kind of admiration, and most of them would ask, “How did you know that?”

In fact, even though I’m constantly learning, I’m faced with endless new problems on the job, and most of them hit the areas I don’t know. I get a kick out of it every time someone asks me about something I don’t know: What better way to learn than by asking questions?

And fortunately, on the basis of the establishment of their own knowledge system, learning new knowledge is usually very quick, to solve a problem often only need to understand one more point of knowledge.

For example, the problem of frequent FullGC, I have checked many times before, most of them are Java program or JVM memory leak problems, but this time there is no memory leak, GC throughput is normal, so I just need to check how to view the most objects created in a period of time method.

Back to the question, my friends asked me: “How did you learn all this knowledge?”

The answer is: after you asked me a question.

Should architects write code?

It seems like every once in a while you see an article about whether an architect should write code or not. I’m a coder because I love writing code.

However, as job responsibilities change, it becomes a problem to keep the balance between coding and other work.

In terms of individual efficiency, I have no absolute advantage compared with many people who write the code by myself, and some people even write the code faster than me.

But as an architect, there are some modest benefits to getting involved in writing code. In general, qualified programmers do a good job with clearly assigned tasks, but in most cases the word “architecture” implies that the architect does not go into too many details.

There is always some distance between architecture and code implementation, there is no guarantee that everyone will understand your design correctly, or that programmers will immediately come up with elegant solutions to obstacles in writing code.

I’ve written about bad code before, and most bad code is not the architect’s design problem, but if the programmer doesn’t understand the design well or is inexperienced, he can do something really weird.

For example, I have seen recent graduate programmers copy the coupled code to prevent module coupling, or try to write all the logic in a single function to “optimize performance.”

If these problems are not found and corrected in time, they can become “right wrong code,” or “I didn’t write it,” or “DAMN it, I saw that code,” something worthy of a badge of shame.

Is this problem the architect’s responsibility? As an architect who values his reputation, I think so.

To me, architects who write code are more likely to be in the logistics business: spotting potential problems in code and alerting others; Or offer suggestions for improvement, or demonstrate proper posture if necessary.

Most of the time as an architect I don’t need to take on “core module” development because my time is too fragmented to be productive. There are many people who can do much better than I can when focused. I just need to keep the big picture and participate in moderation when I need to.

In general, architects and programmers are in some ways like product managers and users. Most programmers don’t tell you what they want, where they need to optimize, or even know it themselves. One of the easiest ways to make a great product is to do the same thing.

Is a meeting a skill?

I don’t think anyone likes meetings, and as a programmer, not many people aspire to be a workplace social butterfly.

But the meeting invitations just kept popping up:

Developing requirements involves meeting with the product.

The project proposal should meet with the technical staff.

The new recruits are going to a review meeting.

There are some big shots from other companies who are having a sharing meeting.

There’s a wrap-up meeting if something goes wrong.

The group has weekly meetings.

The department has weekly meetings.

.

Is it too much to meet twice a week for big projects? Isn’t it too much to have a meeting at the start of a little project? We found a pit during debugging, can we discuss it?

Sometimes I’m in a meeting that lasts two hours and has nothing to do with me, and at the end someone suddenly slams the table and says, “Any questions? All right, go away!”

Or maybe you were not invited to a meeting and two weeks later you received an email urging you on the development progress. “You didn’t attend that meeting and everyone said you should do it… Didn’t you read the minutes?”

With all the teasing, I still think meetings are technical, especially for architects.

Most tech meetings aren’t the briefings on the news or the meetings of the elders. They really need to get together to discuss a specific solution or solve a specific problem.

Unfortunately, I’ve been in a lot of meetings, and most of them involve wasting time on meaningless communication: people sitting in a room saying things to each other that they don’t understand, and concluding, “We’ll talk about this later.”

This isn’t just a meeting problem. There are many programmers who don’t know how to communicate in their daily interactions.

For example, once in a while, I will receive some very carefully written emails. When I open them, there will be a screen full of words, but I don’t know what he is saying from the first sentence, and I have no motivation to read the following things.

Most of the time, communication isn’t about what you say, it’s about what you want the other person to know and do. Good communication can significantly increase productivity at work, but many people overlook this.

Communicating properly can be tricky, but there are a few simple rules:

Make sure all parties are on the same page about the background, such as a quick email before the meeting, a 30-second briefing on new comers, or asking the other person to share his or her understanding during the discussion.

Get rid of the other party can’t/don’t need to understand the content, such as say “this queue to products under the high concurrency because the lock has problems in the implementation of the CPU performance bottleneck”, not to “we found that the performance problems, for 10 minutes, 100000 users don’t get to run without moral integrity advertising, about 5 minutes after expansion solution”.

Make sure to get the point across quickly before they lose focus. For example, if the first paragraph of your troubleshooting email says something like, “The xyz framework uses XXX technology internally, and this technology is built like this: Blabla,” the person will have no idea what you’re talking about.

You can change it to something like this: “I found a Bug in the so-and-so framework and need to upgrade as soon as possible, otherwise there may be YYY problems in the case of XXX. The specific troubleshooting process is as follows: Blabla”.

Don’t waste other people’s time with meaningless stuff like “This requirement can’t be done” or “there can’t be a Bug here.” No one wants to hear that.

Why do other people’s systems always suck?

Many programmers are so good at solving problems that they can write hundreds of lines of code in the afternoon to solve a problem.

But it felt like something was missing, and IT took me a long time to think of a word to describe “this thing,” until I came up with one that barely did: the vitality of the program.

Most programs can do the job, but if you consider “time” as a dimension, you realize that a good project needs to consider much more: more common usage, easy-to-understand documentation, simple and easily extensible design, and so on.

It’s easy to kill the life out of an application: make it more complex, more customized, and involve fewer people.

I told many programmers the vitality of the program, for example to write their own tools operation mode with other Linux commands are similar, or want to use some of the more easy to understand but not the performance of the optimal design approach, or reference to the practice of the industry mainstream, now he went to the many people believe that carry the meaning of this demand is not big, I think here is an example.

Many companies have legacy systems that are huge, cumbersome, difficult to use, almost impossible to maintain, and everyone complains about them and tries to replace them every day.

But after a while, you’ll find new people around you poking fun at the system that replaced legacy systems.

“Most of the systems were great at the time, functional at the time, and seemed to scale well, but they all went bad after the people who developed them left.”

Is there a better way?

The job after becoming a technical expert can be said to be both painful and happy, there will be a lot of people to consult with you, on the other hand, there will be too many people to consult with you.

There was even a time when my daily work was to answer questions, ranging from tool use, medium to difficult bugs, to architecture design. I was basically providing consulting services to various partners from morning to night.

I quickly realized that something was wrong: some of the questions were so simple that I could answer them without even thinking. Why?

And then I started every answer by asking,

“Do you have a better idea?”

A few people can give me an improved version immediately, or even after I ask them several times in a row. A small number of people will just say it can’t be optimized, and that’s it.

But most people will hesitate to say something completely off-key.

And then I changed it to start each answer with two questions:

“What are you trying to solve?”

“Is there a better way?

The effect is much better, many partners find that the problem to solve is not complicated, but the way to run off.

Then I changed to asking three questions before each answer:

“What problem do they want you to solve?”

“What problem are you solving?”

“Is there a better way?

Now the third sentence is rarely asked.

What is the most difficult threshold for becoming an architect?

In the process of talking to some programmers, many of them asked me how to be a great architect.

I’ve interviewed a lot of people in recent years, and it’s interesting to find that many people who call themselves architects can talk to you about an architecture without stopping. Various technical terms come out of their mouth like a cross talk, and all three of them are about high concurrency and big data.

But asking a little, you will find a lot of the lack of basic concepts, such as claims to master the high concurrency people say not clear where he so-called high concurrent system bottlenecks, claim to be proficient in architecture design that don’t see how his system to ensure high availability, claims to large amount of data in the system, in fact, less than 1 million data, and so on.

Architects, while they may sound lofty, are still engineers at heart, not scientists, and not charlatans. No matter how much you learn, you also need to practice.

Designing architectural solutions is more about abstractions and trade-offs: abstracting complex requirements into simple models, planning how to build a system in terms of functionality, performance, availability, r&d costs, and so on, requires more practice.

Many people don’t work in places like Weibo platforms where they need to be exposed to architecture design every day, and many companies don’t have architecture work for them to learn, so they try to work on the theory.

The characteristic of this type of person is very obvious: without information, even without understanding the actual scene, they start to do architecture design. This so-called architecture is often superficial understanding and can not stand the scrutiny.

Every year after we recruit, we do some architectural training for new hires. The course materials basically cover the main aspects of high availability architecture. But is it enough to become a self-supporting architect after learning these materials? Don’t.

Instead, it’s just the beginning, and it’s not until you’ve actually done a couple of systems with tens of thousands of concurrent applications that you’re really getting started: trade-offs when you’re under pressure, shortcuts when you’ve gone through detours.

So I think the most important part of an architect’s job (and many others) is the practice, and it’s easy to talk about it, and instead of dragging on with technical terms, actually do a good job with the system you’re working on.

How much distance is there between me and the bull?

Like many people, I came out of college with the feeling that I could achieve something as a programmer with a little hard work and talent.

After working for a period of time, MY understanding of myself and others became clearer and clearer. Gradually, I realized that the gap between programmers might be bigger than the gap between humans and monkeys. It made me depressed for a long time to accept this fact.

After a period of time, I found myself able to objectively evaluate my ability and realized that the distance was not so important, as long as I tried to run faster, it was enough.