Whether in development, testing, or operations, every technical professional harbors more or less a dream of becoming a technical master. After all, "You have to have a dream, just in case it comes true"! It is precisely the pursuit of this technical dream that drives us to continuously work hard and improve ourselves.


However, "dreams are beautiful, but reality is cruel." Many students will find after actually working that the dream is to become a master, but what they do seems completely unrelated to being a master. For example, programmers say, "Writing business code every day and working overtime, how can I become a technical master?" Testers say, "There are endless test cases to execute every day." Operations staff say, "Carrying machines, connecting network cables, and typing shell commands — this is not the operations life I wanted." ...... On Zhihu, a similar question, "Programmers who write business code every day, how can they become technical masters and start writing technical code?" has 6K+ followers and 120+ answers. At that time I also answered and received the most upvotes. Later, while conducting career level promotion assessments and communications, I gained new findings and ideas, so I had the idea of systematically organizing an article, hoping to help more students avoid detours on the road to becoming a technical master.


Since I am a programmer, some of the examples below are based on software development, but the general principles are universal, and testers and operations staff can also learn from them.


Several typical misconceptions


1. Taking a technical master as your teacher


Some people on Zhihu believe that the simplest, most direct, fast, and effective way to become a technical master is to "take a team's technical master as your teacher" and have them give you extra coaching and assign you some difficult tasks.


Personally, I am against this approach for several main reasons:


  • Masters are very busy and are unlikely to give you one-on-one coaching, let alone one hour of coaching every day. Moreover, within a team, if a master often gives you special coaching, it will inevitably arouse suspicion among other team members. Personally, I think that if a master truly cares, the best thing is to give more training to the team. However, anyone who has done training knows that preparing a training session is very time-consuming. Courseware and materials take at least 2 hours (and cannot be done in fragmented time), and explaining takes 1 hour. For masters to give training once a month is already very frequent.
  • Because of the first reason, when you generally want to consult a master, you should go with specific questions to ask for advice or discuss. Since answering or discussing questions doesn't require too much time and relies more on experience and accumulated knowledge, masters are usually happy to do so—after all, influence is an important indicator of a master. However, special attention is needed: if you often ask about knowledge that can be easily found in books or on Google, masters will also become impatient, because time is precious. Often netizens ask me questions like "How to configure the JVM -Xmn parameter?" and I directly reply, "Please just search on Google," because there are too many such questions. If you don't learn systematically on your own, asking every question individually wastes both your time and others'.
  • Masters are few; it is unlikely that every team has a technical master. At best, there are people in the team who are more skilled than you. Even if he gives you coaching every day, you can only at most improve to his level. If the technical master is from another team, due to work arrangements and assignments, there are relatively few opportunities for direct consultation and mentoring. Attending a few of the master's training sessions alone is unlikely to make you a technical master.

Given the above reasons, I think for most people, to become a technical master, you first need to understand the principle of "mainly relying on yourself" and do not expect a master, like a martial arts teacher, to teach you step by step hand in hand. At appropriate times, you can improve yourself by consulting or discussing with masters, but most of the time you should still improve systematically and in a targeted manner on your own.


2. Business code can also be awesome


Some answers on Zhihu argue that writing business code can also be awesome, because business code can also involve various techniques. For example, you can use encapsulation and abstraction to make business code more extensible, you can communicate more with the product team to better understand and implement the business, and with good logging, problem-locating efficiency can be increased 10 times... and so on.


It is certain that business code also has technical content; the technology in business code is the foundation for every programmer. But just mastering these techniques does not make you a technical master. It is like leveling up by fighting monsters in a game. At the beginning, fighting small monsters gives high experience points. The further you go, the fewer experience points you get. Fighting small monsters can no longer improve your experience, and at this time you need to fight some higher-level monsters and clear some challenging dungeons. I have never seen a game where you can reach the top level by only fighting small monsters. The path to becoming a technical master is similar. You must continuously improve your level, then face greater challenges. By responding to these challenges, you raise your level to the next level, and then repeat the cycle, eventually reaching the realm of technical master or even industry master. Writing business code is just one challenge on this road of leveling up, and I think it is a relatively elementary challenge.


So I believe: a programmer who cannot write business code well certainly cannot become a technical master, but a programmer who only writes business code well is also not yet a technical master.


3. Work is too busy and there is no time for self-study


Many people think that the reason they have not become a technical master is not that they are unintelligent or not hardworking, but that in the Chinese environment, technical personnel have too much overtime, leaving them no extra time for studying.


This reason is somewhat objective. After all, compared with Europe and the United States, we do work more overtime, but this factor is just a problem that needs to be overcome, not an insurmountable gap. After all, there are still many masters around us who have grown up in this Chinese environment.


I think there are several misconceptions that lead to this view:


1) The work at the office is all repetitive; to improve, one must study extra outside work.


The main reason for this misconception is still the belief that "writing business code has no technical content," and since I write business code at work, I cannot improve at work.


2) Learning requires long continuous blocks of time


Many people think that to study, you need to have a whole day of classes like in school. Since we work overtime a lot, on weekends we are so tired that we just want to sleep in, or just watch movies and play games for relaxation, so there is no time for studying.


The actual approach is just the opposite: first, we should learn and improve at work, because learning by applying or having real examples gives the best results; second, after work, learning does not require large blocks of time, but rather squeezing out time and using fragments of time to study.


The right approach


1、Do more


Do more—do more than the tasks your supervisor assigns to you.


When I was at HW, I was responsible for developing a version. The workload for this version was about 2,000 lines, but in addition to completing the feature, I also thoroughly understood all related features and read all the code (about 10,000 lines). After finishing this version, I was familiar with the entire set of business related to this version. After one or two meetings, everyone found that I knew this area best. Then things became interesting: product discussions asked for me, testers came to me for problems, and my boss came to me for external support. Later, even for features not under my responsibility, they came to me. Even if I did not know at the moment, I would read the code or find documents to help them answer... In the end, I became the "expert" of this system. Although I was still doing business and writing business code at that time, I had become familiar with the entire business.


The above is just a simple example. Actually, it shows that to have opportunities, you must first stand out from the crowd. To stand out, you must be different. To be different, you must do more!


How to do more? You can start from the following aspects:


1) Be familiar with more business, whether it is yours or not; be familiar with more code, whether you wrote it or not.


This has many benefits. Here are a few simple examples:


  • Requirements analysis becomes more accurate, and risks, impacts, and difficulties can be identified at the requirements stage.
  • Problem handling becomes faster, because you are familiar with the related business and code, and can quickly determine possible causes and troubleshoot and handle them.
  • Solution design becomes more comprehensive; with an understanding of the overall business, you can design better solutions.

2) Be familiar with the end-to-end process


For example, if you are responsible for web backend development, in reality, when a user initiates an HTTP request, it goes through many intermediate steps before reaching your server (e.g., browser cache, DNS, nginx, etc.). The server generally goes through many processing steps before reaching the part of the code you wrote (routing, permissions, etc.). For many systems or steps in this entire process, the vast majority of people cannot participate in writing the code, but mastering this knowledge has a great effect on your overall level. For example, technical work with more value such as solution design and online fault handling all require a comprehensive technical level.


Words like "systematic," "global," and "comprehensive" may sound vague, but they are actually essential qualities of a technical master. To reach such a level, you must become familiar with more systems, businesses, and code.


3) Self-study


Normally, in a relatively mature team, since frameworks or components have been heavily encapsulated, the technology used for writing business code is indeed limited. But we must understand that "the only constant is change." The framework may need to be improved, components may need to be replaced, or you may change to a company where neither components nor frameworks exist and you have to start from scratch. These are both opportunities and challenges, and opportunities and challenges are only given to those who are prepared. Therefore, in this case, we need to self-study even more, because by the time you actually need to use it, it will be too late to learn.


Take Java as an example. Most business code is just if-else plus a database operation, but we can absolutely learn more Java knowledge on our own, such as garbage collection, tuning, network programming, etc. These may be useless for now, but when you really need them, it is not enough to just Google it. At that time, whoever has already mastered the relevant knowledge and skills will get the opportunity.


Taking garbage collection as an example, I personally took time to learn this knowledge in my spare time and did not use it for a year. But later I used it several times, and each time it solved major problems of system freezes. Meanwhile, some students who have written Java code for several years do not even know what the concept of stop-the-world is, let alone how to optimize it.


2、Do better


Know that nothing in this world is perfect. The systems and business you are responsible for will always have unreasonable aspects and areas for improvement. These "unreasonable" and "improvable" places are all higher-level monsters—defeating them gives you more experience points. Identify these areas, come up with solutions, and propose them to your supervisor. If it doesn't work the first time, propose again. As long as one proposal gets implemented, that is your opportunity.


For example:


  • There is too much duplicate code—can we introduce design patterns?
  • System performance is average—can it be optimized?
  • It is currently a single-machine setup—would it be better to make it a dual-machine setup?
  • The quality of version development is not high—can we introduce efficient unit testing and integration testing solutions?
  • The current system is too large—can we refactor and decouple it into three systems?
  • Some Alibaba middleware systems feel like something we could use too—can we introduce them?
  • 。。。。。。。。。。。。。。。。。。。

As long as you think about it, you can always find areas for improvement. If you feel there is no place in your system that can be improved, that means your skill level is not enough yet. Learn more about related technologies and see how other companies in the industry do things—how BAT companies do things.


In 2013, I was transferred to Jiuyou. At first, I took over a simple backend system. Every day I was just doing data CRUD operations for the frontend. It seemed completely uninteresting, right? If you only do those things, it really is boring. But after we took over, we did a lot of things:


  • Decoupling: split one backend into two backends to improve scalability and stability;
  • Dual-machine: changed the single-machine setup into a dual-machine system to improve reliability;
  • Optimization: optimized an interface that originally took 5 hours to complete down to 5 minutes;

There were many other optimizations as well. Later, our group took on more systems. In the end, this small team of 5 people was responsible for 6 systems.


3、Do exercise


During career level communications, I found that many people were indeed trying to Do more and Do better, but in the process of execution, almost everyone encountered the same problem: just reading without using has poor results—what should we do?


For example:


  • I have learned about JVM garbage collection, but production rarely has lag issues caused by FGC. Even if it does occur, restoring the business is the top priority. It is unlikely that a production issue will happen and let everyone practice on it. So how can I practice this JVM knowledge and skill?
  • I have also read about Netty and understand the Reactor principles, but I cannot participate in Netty development. How can I truly master the Reactor asynchronous pattern?
  • I have read "High Performance MySQL," but the production databases are managed by DBAs, and the test environment databases feel like they are just configured randomly. How can I verify these techniques?
  • The framework encapsulates the DAL layer, so we do not need to worry about database access. How do we learn about sharding and table partitioning implementations?
  • 。。。。。。。。。。。。。。。。。。。。。。。。。。。。。

There are many questions like these. Let me share my personal experience here. It comes down to three words: learning, trying, teaching!


1）Learning


This is the first stage. Reading books, Googling, watching videos, and reading other people's blogs all work, but one thing to note is "systematization," especially for foundational topics such as JVM principles, Java programming, network programming, and the HTTP protocol... and so on. These foundational technologies cannot be learned just through Google or blogs. My approach is usually to first read a complete book to gain a comprehensive understanding, and then use Google, videos, and blogs to look up specific areas of doubt or some tips and tricks.


2）Trying


This step is the key to answering the doubts mentioned earlier by many people. Figuratively speaking, it is "do it yourself and you will have plenty"—that is, set up your own simulated environments and write your own test programs. For example:


  • JVM garbage collection: you can write a simple test program that allocates memory without releasing it, then adjust various JVM startup parameters, and during execution use commands like jstack and jstat to inspect the JVM heap memory distribution and garbage collection status. Such a program is very simple to write—a simple one is just a few lines, and a more complex one is only a few dozen lines.
  • Reactor principles: actually try writing a Reactor pattern demo yourself. Do not think this is too hard—the simplest Reactor pattern implementation, including comments, is no more than 200 lines. You can refer to Doug Lea's PPT. After writing it yourself, go look at how Netty implements it. By comparing the two, your understanding will become much deeper.
  • MySQL: since there is a production configuration to reference, you can directly ask the DBA to send us the production configuration (remember to remove sensitive information) and learn from it directly. Then set up your own MySQL environment and start it with the production configuration. You should know that many people have used MySQL for years but cannot even set up a simple MySQL environment.
  • The framework encapsulates the DAL layer: you can try writing a simple database/table sharding implementation using JDBC, then compare it with the framework's implementation to see where the differences are.
  • Use browser tools to inspect HTTP cache implementations and see how different kinds of websites and different types of resources control caching. You can also write a simple HTTP server in Python that returns various HTTP Headers to observe the browser's behavior.
  • 。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。

There are many more methods, and I will not list them one by one here. In short, you need to truly try what you have learned in order to understand it more deeply. There is a Native American proverb: "I hear and I forget. I see and I remember. I do and I understand." Moreover, "trying" can actually be quite simple—in many cases, we can do it ourselves.


Of course, if you can use it in actual work, the effect is even better. After all, the real production environment and business complexity are not something a simulation program can replicate. But such opportunities are rare, and in most cases we really can only rely on self-built simulations. Then, when the actual business needs it, we can use it effortlessly.


3）Teaching


Generally speaking, after Learning and Trying, you can master about 70%. But to truly master something, I believe you must be able to explain it clearly to others. When explaining, we need not only to systematize a knowledge point but also to consider various details, which pushes us to think and learn further. At the same time, after explaining, the people listening may have different interpretations or new supplements, which effectively continues to improve the entire knowledge and skill system.


There are many such examples, including when I write my blog—I encounter this often. I originally think I have mastered something comprehensively, but once I start writing, I discover many points I had not considered. I also often see it in internal team training: some people write a PPT, but when presenting, once everyone asks questions or discusses, they find that many points have not been clearly explained, or some points are misunderstood. Going through the entire process of writing a PPT, presenting it, and discussing it basically gives you a fairly comprehensive grasp of a knowledge point.


Afterword


The dream of becoming a technical expert is beautiful, but it requires a lot of effort. Whether it is Do more, Do better, or Do exercise, all require time and energy. This process may be painful or boring. Here I want to emphasize: what I have shared above are methodologies, but what truly plays the decisive role is actually our passion and interest in technology!