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 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 after a period of time, and the direction of work gradually becomes clear.

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.

Talk about your experience to improve learning efficiency, in fact, 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:

 





How do you know all this? There are always all kinds of problems in my work. Several times, I summarized the process of dealing with the problems and sent them out. After that, more and more friends came to consult the problems, such as:

A while ago, I helped to troubleshoot a performance problem. When the system pressure was slightly higher, GC would be frequently Full. After the pressure was reduced, it 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 frequent Full GC problem, which I have checked many times before, is mostly Java program or JVM memory leak problems, but this time there is no memory leak and GC throughput is normal, so I just need to check how to see the most objects created in a period of time.

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.

Architecture technology is a topic that programmers cannot live without. Here I recommend an architecture exchange learning group: 650385180, which will share some videos recorded by senior architects: Spring, MyBatis, Netty source code analysis, high concurrency, high performance, distributed, microservice architecture principles, JVM performance optimization has become an architect’s essential knowledge system. Also can receive free learning resources, I believe that has worked and encountered a technical bottleneck code friends, in this group will have the content you need.

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 the architecture diagram and the code implementation, and you can’t guarantee that everyone will understand your design correctly. Or a programmer who hits a snag in writing code and immediately comes up with an elegant enough solution.

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 they are not found and corrected in time, they become “right wrong code,” or “I didn’t write that code,” 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.

In my opinion, an architect who writes code is more of a logistics job: spotting potential problems in the code first, alerting others, or suggesting improvements, or demonstrating proper posture when 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 do a much better job than I do when they are focused, and I just need to keep the big picture and participate in moderation.

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.

Practice: Is meeting a technical activity? I don’t think anyone likes meetings, and as a programmer, not many people aspire to be a workplace social butterfly.

But meeting invitation so jumped out one by one: the meeting with product development requirements, project plan with technical meeting, new positive to judges and other companies to open a few are sharing meeting, there is something wrong with the summing-up meeting, group a week meeting to be held, departments have weeks, big project open meeting twice a week is not too much? 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’ll be in a meeting that lasts for two hours and has nothing to do with me, and at the end someone slams the table and says, “Any questions? All right, let’s go! “

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 show up for that meeting and everyone said it was supposed to be you… 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 that “We’ll talk about this later.”

This problem is not meeting, the programmer in daily communication, also has a lot of people don’t know how to communicate, such as the occasional will receive an email with the written some very seriously, after open is a screen of text, but from the first sentence start don’t know what he was saying, things haven’t see the power behind.

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 make a huge difference in productivity at work, but many people overlook it.

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

1. Make sure everyone is 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.

2. Get rid of the other party can’t/don’t need to understand the content, such as product said “this queue under the high concurrency because lock has problems in the implementation of the CPU performance bottleneck” than 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”.

3. Make sure to get the point across quickly before the other person loses focus. For example, if the first paragraph of your troubleshooting summary email reads, “XXX technology is used inside the framework, and this technology is built like blabla,” the other 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”.

4. Don’t waste other people’s time with meaningless stuff like “This requirement can’t be done” or “there’s no way there’s a bug”. 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 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 interviewed a lot of people in recent years, and found an interesting phenomenon: Many people claim to be the architect when people tell you an architecture of gushing, all kinds of technical terms like said crosstalk from his lips, three sentences from high concurrency large data, but slightly ask once, 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, The person who claims to be proficient in architectural design can’t understand how his system can guarantee high availability, the system that claims to be very large data volume actually has less than 1 million pieces of data, etc.

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 do not work in places where they need to get in touch with architecture design every day, such as Weibo platform, and many companies do not have work in architecture for them to improve, so they try to work hard in theory. The characteristics of these people are very obvious: Without enough information or even knowledge of the actual scenario, the so-called architecture design is often superficial and can not stand 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.

Java technology zhai



Make every push carefully

You are one public number away from the Internet