【2017 Year-End Review】How Programmers Can Keep Growing Fast Amid Waves of Technological Change?
Preface
As technologists, by the end of the year we usually do some self-reflection or write a summary, looking back to see how much we have grown over the year. I am no exception, and I plan to start recording my year-end summaries from 2017. Although this kind of summary article is not purely technical, I wanted to avoid writing a mere chronological diary, so I racked my brain trying to present it to readers in a novel way. I decided to use a question that many people care about as the thread running through the whole article. Unless something unexpected happens, I will use this format every year from now on: one broad question per year. The experiences in these articles are guaranteed to be 100% personally lived by me, including both successes and failures. Of course, each reader’s situation will be different from mine, so you can take what is useful and discard what is not based on your own circumstances. Some viewpoints in this article represent only my personal opinions. If anything seems inappropriate, you are welcome to raise it for discussion and critique.
My Chinese pen name online is “A Wisp of Sorrow, Half-Hidden in Frost,” often shortened by others to “Frost,” “Frosty,” or “Shuang.” Since this annual article series is meant to be special, it should have a special name as well. In Chinese culture, four-character idioms tend to sound more meaningful, and the idiom also had to contain the character “frost” and convey the sense of passing time. After a lot of searching, I settled on the title of this series — Years Slip By.
【Explanation】Years and frost: the stars complete one cycle every year, and frost begins to fall each autumn, so the term is used to refer to the years. It means that time gradually passes.
【Source】Tang dynasty, Wen Tingyun, “To Mr. Cui”: “Years and frost slip by with no word from you; amid misty waters, your name has changed.”
All right, everything that needs to be explained about this series has now been explained. I will not repeat this explanation in future years. Let the main text begin.
Technological change has acceleration
Starting in 2010, which was defined as the first year of the mobile Internet, mobile development also gradually began to take off from that year onward. I joined this wave after graduation. It is said that when mobile development was hot, even a barber could get a monthly salary of 10–20K after a few months of training, which shows how desperate the market was for mobile talent at that time. But starting at the end of 2014, hiring requirements for mobile development returned to a more rational level and gradually became higher. By now, large companies basically no longer hire mobile developers below senior level through experienced-hire channels. Interviews have of course become much harder than in the previous few years. BAT interviews may cover cutting-edge technologies, hotfixing and cross-platform solutions, low-level technologies, LLVM + Clang, fundamentals, WebKit, and JSCore. Some iOS developers around me have gradually shifted toward writing JavaScript. Domestic iOS developers may also feel the impact of the arrival of the “big frontend” era on their own technical skill sets. (Of course, iOS developers overseas do not care much about this; the overseas approach is still native development.) Returning to the domestic market: as some big-frontend technologies gradually encroach on areas previously developed by iOS developers, perhaps before everyone has even become familiar with or proficient in the various frontend frameworks, AI has already entered everyone’s field of vision. Concepts such as machine learning and deep learning are flooding in.
From the end of 2012 to the beginning of 2013, a large number of startups sprang up like mushrooms after rain. By the end of 2014, many companies had failed to survive that winter. In 2017, this year, there are still large numbers of startups being born and then falling, such as the various bike-sharing companies. The capital market is simply that brutal.
Some colleagues around me have also become anxious. To be honest, I have been anxious too. Trendy technologies seem to change almost every year. At the beginning of the year, you may not have fully figured out blockchain or the three major frontend frameworks, and by the end of the year you are immediately crushed again by AI. A frontend expert once explained it to me like this: “Technology has to be followed constantly. In frontend, if you do not keep up with new technologies for a few months, they may look unfamiliar when you see them. If you stick with old technologies for several years without changing, well, when you go back to learn the new ones, the frontend framework landscape may already have become a completely different world.” Perhaps this answer is somewhat exaggerated, but it also shows from another angle just how fast frontend has developed in recent years.
You can also think back on technological changes over the past few years. You may be able to feel it too: technological change has acceleration.
Where does anxiety come from?
I will still use iOS developers as an example. Three images often appear in iOS developer groups.
One is “nobody wants iOS developers anymore,” and another is “people want iOS developers again.” These two images often appear as memes in various discussion groups. Why? Because part of the demand for iOS development has been taken on by frontend developers. Many small companies in China directly state in their hiring requirements that candidates must know JS, RN, Weex, and similar technologies. This directly leads to iOS developers who do not know JS becoming unwanted. Whenever Apple “cracks down” on cross-platform solutions or hotfixing, or takes any related action, native developers will flood chat groups with the “people want iOS developers again” emoji. Frontend developers may have similar anxieties. Their anxiety may come from how well they have mastered the three major frameworks. If you are only proficient in one framework, you may feel insecure when looking for a job and encountering someone proficient in all three.
This is one source of anxiety: not knowing certain knowledge points may lead to being unable to find a job, or unable to find a good job.
Another source of anxiety may be “backflow” from newer entrants?
Every year, trending technologies change extremely fast. For example, AI has been extremely hot this year, which directly led to a situation where fresh graduates receiving AI offers can have salaries that mercilessly outcompete people with 2–3 years of work experience. Even people with 2–3 years of experience who have been continuously following these new technologies will feel pressure. That is why we have the second image above: please stop learning; we cannot keep up.
After all, very few people can guarantee that they have large blocks of time every day to learn new technologies. Aside from finishing company work, plus possible overtime, people are tired when they get home and need rest. There simply is not that much time every day that can be used in large blocks for learning new technologies.
People also differ in how fast they learn and how deeply they master things. After comparing ourselves with others, we may discover that we learn more slowly and learn less than others. If we force this kind of comparison, it will indeed create anxiety that we are not as good as other people.
How can we learn efficiently?
Facing such rapid technological change, how should we learn efficiently so that we maintain competitiveness and are not eliminated? After more than 10 months of growth, I now have some right to speak on this question. Please allow me to slowly share my experiences and reflections from this year.
I will start from the psychological side, and then finally talk about my learning methods. I hope that by following this train of thought, readers can gain something from it.
1. View anxiety and confusion correctly
Once programmers become anxious or confused, their sense of achievement will be greatly reduced. Over time, this leads to insufficient motivation. But as analyzed earlier, the reasons reality creates anxiety are objectively present. So how should we face them?
This is how I face them.
In the process of technological change, if you blindly follow new technologies, have you thought about what exactly you are following them for? Is it to change jobs or transfer to another role? Or is it to increase your compensation and realize your ideals and self-worth? Both reasons are valid. One thing to note is that you should not blindly follow new technologies. Blindly following them will only turn you into a slave of technology in the end. We need to be masters of technology and face technological changes with greater composure.
How should you choose? If you are not transferring roles, and if you do not have a goal, learning knowledge that may not be used in your day-to-day work may be somewhat “blind.” The process of learning such knowledge may also be inefficient. Inefficient learning, combined with the rapid growth of others, leads to comparison, and new anxiety arises. I have personal experience with this.
The following is my own failure case, shared with you.
In July this year, I bought a Haskell book, intending to study this ancestor of functional programming. After being exposed to FP, I had developed a strong interest in Haskell. I chose to invest skill points in Haskell purely out of interest. It is basically not used at work (you could say it is not used at all). Transferring roles is also completely impossible. If you search for “Haskell development engineer” on job sites such as Lagou, your heart will go cold: there is not a single corresponding position in China. (There are some overseas, but very few.) The book I bought is the one below:
For the ebook, I read this one:
The book says: the unbeatable Air Man, the unlearnable Haskell. My progress learning Haskell was very slow, because there were indeed too few opportunities to practice it. After finishing the book, my understanding of FP did improve by one level, but there were very few opportunities to use it for development. Haskell is a very good language, but my learning curve with it was truly painful. I took many detours along the way. (I will not share those detours and wrong paths.) Later, my team lead said something to me: he believed that learning without a large amount of practice is inefficient. Facts proved that my learning of Haskell was indeed inefficient. I did not have a lot of practice. I did learn it, but my progress was very slow. I did gain something, but there was also a lot of frustration. The unbeatable Air Man did not beat me down; I will continue learning it next year when I have time.
Learning is never wrong. What is wrong is choosing an inefficient direction that consumes time and energy.
My suggestion here is still to prioritize learning knowledge used in your company’s projects and dig deeply into technical pain points. If you have extra time, then broaden horizontally and learn about other areas. Just like becoming a T-shaped person: first specialize in one area, then broaden your range. If you only have breadth without depth, you may not even be able to find a job.
Now let’s talk about confusion. Confusion has two sources: first, not seeing your value to the company; second, not seeing your future development path.
First, the first source of confusion: not seeing your own value. Many people write business logic at the company every day, commonly called “moving bricks.” They move bricks every day and feel they are making no progress at all. Looking back at people in framework teams or researchers in their own departments, they are researching or building frameworks or tools every day. When many people use those things, it brings a strong sense of achievement. They also believe that business logic has little technical content, and that the logic and processes in the business have no advantage after switching to another company. This idea is actually incorrect; it is wrong and one-sided. How to correctly understand and change this idea will be discussed in more detail in the next section.
Now let’s discuss the second source of confusion: not seeing where the road ahead lies. I think this confusion comes from unclear self-positioning. A teacher once told me that in the first five years after graduation, you can choose various kinds of development: frontend, backend, or mobile; you can choose freely. What is the purpose of this? It is to find the direction that you are interested in, that matches your strengths, and that you intend to keep doing for the rest of your life. If you still cannot see your future development path, you can consider broadening your horizons and looking for the direction you are truly interested in. By “truly interested,” I mean something like staying up late to play games without feeling sleepy. If in a certain direction you can write code late into the night or even through the night without getting bored, not because the company forces you to work overtime but because you choose to, then that must be something you are interested in. Once the direction is set, you will no longer be confused. Run toward the goal.
2. How should you choose between business logic and architecture?
Among programmers, there may be a kind of contempt chain: people who write architecture look down on people who write business logic. This contempt is biased.
First, the revenue of the vast majority of companies comes from the company’s business. There are only a very small number of exceptions. Those who write business logic do not need to feel that business logic has no value. You should understand that the business logic you write makes money for the company.
Of course, people who can write internal frameworks or tools in a company must have accumulated a certain technical depth. Frameworks and tools do not come into being for no reason. They are born to solve problems or pain points. They either solve pain points in development or improve development efficiency. If you do not have a certain degree of understanding and awareness of development, how can you deeply understand and feel these pain points? Without understanding them, you cannot build frameworks that solve problems, or tools that are useful and pleasant to use.
I believe that those who can write frameworks or tools must have a certain amount of technical accumulation, and they must be able to understand and see clearly some pain points in development or in the business. Therefore, they develop things that solve these problems.
At least for now, most companies in China cannot do without people who write business logic. Small companies, in order to survive, can do without people who write frameworks and tools, but they cannot do without people who write business logic. Large companies need people who write business logic even more. At present, there do not seem to be any companies in China that do not write business logic. If a company purely writes frameworks or tools for other companies to use and makes money from that, then those frameworks or tools have become that company’s business.
Now let’s talk about my understanding of architects or higher-level titles.
In our BU, there is a dedicated architecture group, and everyone in it is at the level of P7 architect or above. What is their work? They are the people who provide solutions that can address current development pain points. I have talked with them. Although they do not understand the business down to every line of code word for word, they have an overall understanding of the company’s entire business process and data flow. Their understanding of the business is deeper and broader than ours, since we are only responsible for a single business area. On this foundation, they can also solve difficulties and pain points in development, and provide their own thinking on the business development of the BU. Architects also have the ability to independently discover business value.
Perhaps everyone thinks architects do not write code, but they need to produce solutions. To a certain extent, producing solutions is even harder than writing code. Where does the inspiration for a solution come from? It comes from a deep understanding of the company’s business and deep technical accumulation. Without understanding the business, the proposed solution may not be fully suitable for the company. Without deep technical accumulation, the performance of the proposed solution may not be optimal. I don’t think people should look down on writing business logic. If you’re a programmer at a company working on business features, please don’t give up on yourself. When the company hands you a business domain, whether you can deliver on time and efficiently is the problem you need to focus on right now. Once you are very fluent in the current business area and have developed a deep understanding of it, you can then think about understanding the product line you are in and the process of that business line. While understanding the process, consider why the company’s current architecture is designed this way. What are its advantages and disadvantages? What can be changed and what cannot? Which parts are the result of historical baggage?
Only through this kind of day-by-day accumulation—after you have accumulated substantial business experience and seen excellent, reasonable architectural designs across many business scenarios—can you move toward becoming an architect.
I firmly believe one thing: when a company pays to hire an architect, that person’s responsibility must be to design and complete architecture-related work for the company. As the saying goes, there is no best architecture, only the most suitable architecture. This is where an architect’s value lies: after deeply understanding the company’s business requirements, they tailor the best and most suitable architecture for that company’s business.
At my company, there was a P8 senior algorithm expert sitting next to me. Before I knew his title, I observed that his day-to-day work consisted of putting various algorithms into production and solving real pain points and development challenges inside the company. Whenever a product manager or developer came to ask him about some piece of logic, he knew it inside out. For a while, I thought all the logic people asked about was something he had personally helped develop. It was only later, after I learned his title, that I felt even more strongly where the value of an algorithm expert lies.
In non-academic industrial production, the value of an algorithm expert lies in using various algorithms to solve business pain points inside the company. I saw him use graph algorithms together with machine learning to solve intelligent scheduling problems in real production, and his understanding of the business he was responsible for was extremely deep. (Of course, in academic research, the value of an algorithm expert should lie in creating algorithms or improving algorithm efficiency.)
In the iOS field, everyone also knows Digo. Digo is an architect. After talking with him, I learned that his day-to-day work involves organizing department personnel, making decisions on technology selection, organizing business work, and designing architectural solutions. So I believe that an architect’s work is based on solving business problems and driving business growth; on top of that, they improve the company’s architecture so that it can provide better performance externally, while also having the ability to organize and coordinate people, technology, and business.
A good product must be able to perfectly address users’ pain points. Understanding and discovering the value of the business is also a capability. At the very least, it is a capability an architect must have. I am also currently training myself through business work. While deeply understanding the company’s business, I am also thinking about how to design the architecture, why it should be designed this way, and whether there is a better design. I cannot say that I will definitely become an architect in the future, but at least I believe I am working in that direction.
3. The Differences and Unity of Technical Division of Labor
This year, I have worked on both frontend and backend. The frontend is the side closest to users. And now that we are in the era of the “big frontend,” you may notice that frontend engineers can do more and more. Moving forward, they can get involved with clients; moving backward, they can get involved with Nginx. The frontend engineer’s tech stack has also become very broad. Backend engineers, by contrast, may seem less busy than frontend engineers.
Frontend data comes from the backend. The frontend focuses more on UI, interaction, and design. The backend focuses more on API performance and data correctness. But as cloud infrastructure has gradually matured, backend infrastructure has been moved to the cloud, making configuration and management of this part exceptionally easy. All of it is handed over to the cloud.
Frontend frameworks and browsers are now developing by leaps and bounds. Some business logic is handled directly on the frontend. Even with frontend-backend separation, the frontend has taken on more and more roles within companies. There is a joke: a big-frontend engineer says to a backend engineer, “Isn’t your backend just writing APIs and spitting out strings?” The backend engineer says to the big-frontend engineer, “Isn’t your frontend just putting pages together? The frontend is just a pretty string.” Although neither statement is accurate, they do abstract the nature of their work from the side.
So the frontend and backend have different divisions of labor, but they are still cooperative and indispensable to each other.
In the private circle of Zhu Yun, a female PhD at Airbnb, I saw a Q&A:
Question: As a backend developer, I would like to ask Anjie how to improve my ability to handle complex business logic, my design ability, and my abstraction ability. If I take over a system with insufficient stability, how should I reduce complexity and gradually improve stability?
Teacher Zhu Yun gave this answer very succinctly and beautifully:
To control something, you must first understand it thoroughly. Understand the full context of all business logic, know some typical system design solutions and the problems they address, as well as comparisons of their pros and cons. Have experience with some real systems. Only on top of this is it possible to apply an appropriate design to the current business logic and abstract the existing business logic into an existing (partial) solution, or into a more classic approach.
If you take over a system with poor stability and do not have enough time to redesign it from scratch and completely refactor it, then at minimum you need to know the key factors affecting stability. Then prioritize them based on importance, urgency, and the resources required to solve the problems (time, skill sets, people, etc.), and tackle them one by one. For all improvement-oriented actions, make sure there are suitable evaluation and monitoring mechanisms, so you can know exactly how effective different measures are.
Combined with the relationship between architecture and business that we discussed earlier, this is also unified. Whether frontend or backend, whether business or architecture, the ultimate goal of these divisions of labor is the same: to let technology drive business growth and multiply the company’s profits. Students who write frameworks or tools build better frameworks and tools to improve development efficiency. Students who write business code use technology to make the business more stable and the logic more reliable. The ultimate purpose is to drive the company’s business growth. I believe that once you see this, you can recognize your value within the company. When you find your own value and realize the company’s value, you are less likely to feel lost, and it becomes easier to gain a sense of accomplishment.
4. Efficient Learning Methods
At this point, I will use my experiences from this year to talk about what I believe efficient learning methods look like. I will also summarize my work and gains over the past year. Roughly, there were three stages.
The first stage: the iOS stage
I came here in February this year, after the New Year. After joining the company, the first task assigned to me was to solve memory leak issues in the project. Because the project used RAC throughout, and the team did not have a deep enough understanding of its internals, it was easy to write code that caused memory leaks. After I arrived, I identified all memory-leak-related issues in the team. Later, the team started working on componentization, so I began researching and implementing a routing solution suitable for our team’s use.
Later, the company began promoting a cross-platform solution—Weex. I was also honored to be assigned to research this area. I learned a great deal from reading the source code. By this point, it was May of this year.
The second stage: the frontend stage
After June, the team took on a new project, and I proactively applied to write the frontend pages for it. Because I had already learned about Weex, choosing the Vue framework was a natural next step. So I started writing Vue-related projects.
During just over two months of project iterations, I learned a lot. Various internal scaffolding tools, the frontend development process, frontend page instrumentation, the frontend release process, continuous integration for frontend projects, page performance monitoring APM, frontend engineering, componentization… All of these also exist in iOS, but I was exposed to all of them in just a few iterations. Compared with other colleagues who started learning frontend around the same time, my progress was relatively “blazing fast.” At least after I had finished learning the whole workflow, he was still exploring JS.
Although my frontend experience is still very shallow, I am competent enough to work as a P4 and handle basic business iterations. I also deeply understand that frontend covers a huge amount of content, and a few months only scratches the surface of the surface. But at least it gave me a taste of day-to-day frontend development.
I think my frontend learning was efficient. Why was it efficient? Because I learned through practice. Using real company projects to train yourself is truly an especially efficient way to learn. For problems I encountered in the project every day, I would very purposefully search online for solutions during my commute. The learning goals were extremely clear. I progressed much faster than people who only read syntax every day without practicing.
For getting started with frontend, I can provide my path.
First, of course, learn JavaScript and Css. The entry-level method is still reading books. I read the following books:
JavaScript: The Definitive Guide (6th Edition)
Professional JavaScript for Web Developers (3rd Edition)
DOM Scripting: Web Design with JavaScript and the Document Object Model (2nd Edition)
Getting Started with ES6 (2nd Edition)
Effective JavaScript: 68 Specific Ways to Harness the Power of JavaScript
Speaking JavaScript
You Don’t Know JS: Up & Going
You Don’t Know JS: Scope & Closures
After that comes a large amount of hands-on project training. By being “tempered” through participation in company business iterations, you can quickly learn a lot. After a few iterations, you can understand the whole process.
Of course, to intensify my training, I also practiced on Github. At the time, I was also very interested in the Electron framework, so I wrote this open-source project: A cross-three-end application developed with the Vue ecosystem + Electron.
In addition, within the company I also recognized three mentors who helped my frontend skills take off. One is a well-known frontend influencer on Zhihu, @Ao Tianyu. This young woman has many titles: Ele.me frontend mascot, Brother Tian, Tianzun… too many to count. She joined the frontend architecture team right after graduation, and she is extremely capable. I would also like to thank her again for patiently answering entry-level newbie questions like mine. She answered many questions on my path of growth. (Here I can also recommend her Zhihu Live session. Students who feel lost about the frontend advancement path can go listen to it; it will definitely answer some of your questions.)
Another mentor is Pengpeng, who joined the company on the same day as me. He is also a frontend developer and is very strong technically. I also have a very good relationship with him. When I have frontend questions, I often ask him.
The last mentor was my college roommate. He is also very strong in frontend, and I ask him for advice on questions I do not understand.
Here I would also like to thank the three mentors above for answering my questions and carrying a frontend newbie like me to fly.
To summarize this period of frontend learning: a large amount of project practice + proactive, purposeful reading and learning + guidance from experts = efficient learning.
The third stage: the Go stage
In July, I followed my team lead and switched to writing backend business code. In just a few months, I also grew very quickly. I have become very familiar with the basic usage of Go. I have also summarized and recorded my Go learning path. Interested readers can read this article: The Growth Path of a Go Beginner. I will not repeat it here.
After switching to backend business work, the language barrier was not a big problem. What felt more painful was the entire backend ecosystem. The sheer amount of stuff flooded over me like a tide.
The business our team is responsible for is all related to geographic location. So I conducted deep research into spatial search. I also wrote all the research results into articles and placed them here: Collection of Articles on Spatial Search.
In the project iterations I have participated in so far, I have basically mastered the use of all backend development processes and tools: the Thrift RPC framework nex, Docker, k8s, ELK logs, Redis, Huskar SOA configuration, GoProxy configuration, ETrace monitoring, MaxQ delayed message queue, Eless releases, Workflow workflows, PostgreSQL usage, Google S2… Watching the QPS of the services I developed gradually grow gives me a strong sense of accomplishment. This project feels like my own child, and I cherish it deeply.
In addition to reading and learning on my own, whenever I encountered various technical problems in the project, my team lead and teammates answered my questions. They also carried me forward. If I had studied and explored everything on my own, I do not know how long it would have taken me to understand so many of the things above.
To summarize this period of backend learning, it is the same: a large amount of project practice + proactive, purposeful reading and learning + guidance from experts = efficient learning.
The experiences above are relatively successful ones. Compared with learning Haskell, the progress was clearly “blazing fast.” While solving pain points in company projects, I also quickly learned and improved a great deal of knowledge. Thinking back to what my team lead said before: practicing in company projects is the fastest way to grow. I also used one year to verify the truth of this statement.
5. Summary
How can programmers maintain a relatively high growth rate amid waves of technological change? My answer is: practicing in company projects is the fastest way to grow. First, the iteration schedule of the business prevents your learning from dragging on. Within the schedule, you must complete the specified tasks, which provides a very good guarantee for learning progress. Second, practice in real projects gives you hands-on experience with language proficiency, the language ecosystem, development processes, bug-finding workflows, monitoring, and many other aspects. Real projects also let you encounter all kinds of pitfalls; the more pitfalls you step into, the more you grow. The correct way to learn should also be to combine learning with concrete business scenarios, helping the company use the technologies you have mastered to launch business services and create value. From this perspective, this kind of growth is certainly the fastest. A true computer science luminary once suggested that programmers should grow at a pace of learning at least one unfamiliar language every year. Judging from this year’s results, I did it.
After a few years in the industry, a programmer’s perspective should no longer be confined to the development language they use. You can rise above programming languages, broaden your horizons, and think about problems at a higher level. Of course, to people at a higher level, the thoughts I shared above may still be fairly ordinary. But those people must also have walked this path step by step, until they eventually reached the point where they could comment on the state of the world, and their ideas could influence the entire industry. The above is some of the non-technical understanding I gained over this past year. All of it comes from “valuable experience” I personally earned through practice. I hope readers who have made it this far can take something away from it.
Of course, everyone grows in different ways. I am simply offering a method that I have validated through practice and found workable. If readers already have better methods of their own, I welcome you to share them as well; you can treat this article as my year-end summary. If you also lack some methods for growth, you might consider trying the approaches mentioned in this article. Let’s encourage each other.
6. The Future
Our team has started using Python again for business work. This language has been incredibly popular this year, so I’ll study it properly next year as well. In addition, I’ll continue to deepen my Go skills.
Closing Thoughts
A year ago, a senior Alibaba engineer at the P9 level asked me a rather philosophical question: “As a programmer who has been developing software for so many years, how do you view software development?” At the time, I replied, “Are you asking about frontend development or iOS development?” He answered: “Can you avoid limiting yourself to a programming language? Talk about your own views on the definition and process of development from a macro perspective.” At that moment, I couldn’t answer right away. It wasn’t that I had nothing to say, but that the question felt too broad and difficult to answer well. Only now, after being exposed to development work in different languages and different roles, do I have my own answer to that question. For questions like this, the depth of the answer may reveal the depth of a person’s ability. Without several years of software development experience, and without sufficient breadth and depth of knowledge, the answer to such a question will almost certainly be rather superficial. It is like having already mastered advanced mathematics and then testing an elementary school student on solving a linear equation in one variable. No matter how he solves the equation or what method he uses, you can tell his level at a glance. Similarly, the question above is being asked by an expert standing at a higher vantage point. No matter what answer you give, from the perspective of his experience, the depth of your answer roughly reveals how much experience you really have.
I wonder whether readers who have made it this far already have a relatively perfect answer in mind. I plan to leave this question for next year, as the topic of the 2018 edition of “The Passage of Years.”
Finally, one last recent reflection. There is a legendary book, 《Clean Code》, published in Chinese as The Way of Clean Code. Recently, I have been casually picking it up and flipping through it again. Reading it for the second, third, or even fourth time, the experience is different each time. The first time I read it, perhaps because I lacked sufficient experience, there were not many places where I could truly resonate with the author. Most of the time, I was simply reading the words and code in the book and trying to understand the author’s intent. Of course, that is the most basic level. But recently I found that when reading it for the second or third time, I could resonate with the author much more. That resonance comes from my own day-to-day development experience: some of the examples in the book are things I have personally gone through, whether from refactoring a feature, painstakingly designing an architecture, or handling a special requirement. All kinds of personal experiences resurface in my mind. I feel that part of the book’s content has already been internalized as my own. Of course, there are still parts that do not resonate with me yet.
Reading the same book again and again brings different experiences at different stages of a programmer’s growth. At first, you may feel that the book is thick and the content is dry. But after you have experienced many things, you discover that the book is actually quite thin. Looking back at it, the book feels like a memoir of your own different stages, because you have personally experienced much of what it describes. Perhaps this is the path of growth in one’s own level. It can also be considered the most direct material manifestation of personal growth.
All right, that concludes the 2017 edition of “The Passage of Years.” If you have any objections or anything you’d like to discuss, you are welcome to reach out and talk with me.
December 30, 2017, in Sydney
Reference：
An application built with the Vue ecosystem + Electron that runs across three platforms
A beginner Go programmer’s path of growth
Collection of articles on spatial search
GitHub Repo：Halfrost-Field
Follow: halfrost · GitHub
