Character descriptions:
- The novice: New to programming, eager to improve his software development skills, he is always curious and eager to learn.
- The master: With over 20 years in software development, he is proficient in many programming languages and has software engineering experience that few can match. He is economical with his words, sometimes coming across as cryptic (but he is not a bad person).
1. Clever code
One day, the novice asked the master, "I optimized 10 lines of Python code into a single line using a list comprehension, and the new code is very elegant. Why did my pull request get rejected?"
The master replied, "I was the one who rejected your PR."
Seeing the novice's surprise, the master added, "I wrote those 10 lines of code a month ago."
The novice blushed, but still didn't want to give up his PR, so he argued, "But right next to the function I changed is a similar function with much more complex one-liners. Why were they getting merged?"
"Oh, that was code I wrote 10 years ago," the master replied.
Author's comment
"What kind of code is good code?"
The answer to this question may change dramatically as our "coding age" increases.
10 years ago, the master was intoxicated with expressing the most complex logic with the least amount of code. Now he prefers to write plain, simple code.
When programming, we have to find a balance between "fancy code" and "simple code," and from what I've seen, that balance point is constantly shifting toward the "simple" end with increasing experience.
2. One line of code and five lines of comments
One day, the novice asked the master, "I write a lot of code every day, fulfilling many requirements, but why doesn't my programming level improve?"
The master replied, "Let me see what you've been writing."
The novice opened his computer. The master pointed to an ordinary line of variable assignment code on the screen and said, "The day you realize you need to put five lines of comments before that is the day you've grown." With that, the master walked away.
Author's comment
In an ideal world, code should be "self-explanatory" - easy to understand without the need for comments.
However, sometimes the scenarios that the program needs to handle are so complex that it is impossible to convey all the essential information with code alone. In these cases, the use of comments to enhance the readability of key pieces of code becomes very important.
Being able to write highly readable code is certainly commendable for a programmer, but being able to effortlessly produce concise and clear comments (or documentation) is the icing on the cake.
3. Delete the comments
One day, the novice asked the master, "I write a lot of code every day, fulfilling many requirements, but why doesn't my programming level improve?"
The master replied, "Let me see your code."
The novice opened his laptop. The master pointed to a section of comments on the screen and said, "Delete that."
The novice did as instructed. After pondering for a moment, the novice exclaimed, "I get it! You mean we should focus on the descriptiveness of the code itself, rather than relying too much on the comments!"
The master shook his head and said, "No, I just wanted to check your typing skills, and from what I've observed, you can't even touch type. Then the master walked away.
Author's comment
The novice's point about "focusing on the descriptiveness of the code and not relying too much on comments" is indeed correct, but this time the playful master was actually drawing attention to something else: a basic skill (touch typing).
Programmers use a variety of tools in their work. I've seen some programmers who are like the novice in the joke, having only a superficial understanding of the editors, IDEs, and command-line tools they use every day, and never taking the time to learn them systematically.
However, thoroughly mastering these everyday tools, as well as consciously improving underlying skills (such as typing speed), can actually bring unexpected and substantial benefits to work efficiency.
4. Microservice architecture skills
One day the novice asked the master, "How can I improve my microservice architecture skills?"
The master replied, "Let me see your code."
The novice opened his laptop. The master noticed that the project's utils directory was many times larger than all the other modules combined.
"If you don't know how to organize modules, you essentially can't 'architect' anything else." The master said, then turned and walked away.
Author's comment
Designing a large monolithic project has many similarities to designing a distributed system made up of a bunch of microservices; they follow some of the same guiding principles.
For example, the "Single Responsibility Principle" which answers the question: "How can we design the project's modules (or microservices) so that when we develop a feature, we don't involve too many other unrelated modules (or microservices)?" applies equally to both architectural styles.
"Modularity" is one of the most important guiding concepts in software development, regardless of the architectural pattern.
5. Beyond the code linter
One day, the novice approached the master.
"The code linter introduced to the project yesterday is incredibly powerful. I've noticed that everyone's code quality is now almost identical," the novice continued, asking, "I wonder, if a linter can help everyone write equally good code, where does the oft-mentioned 'better coding skills' actually manifest itself?"
The master pondered for a moment before answering, "Ten years ago, when driving on the highway, drivers had to maintain a steady speed and keep the car centered between the lane lines. Surprisingly, it took a considerable amount of driving experience to accomplish this simple task of driving 'steady and centered'."
The master went on to say, "But now most cars are equipped with assisted driving features that can easily perform the task mentioned earlier. You'll notice that once on the highway, some drivers start browsing TikTok on their phones, while others stay focused on the road, ready to optimize their route and take over in emergency scenarios that machines still struggle with."
Seeing the novice deep in thought, the master added, "Driving is not just about keeping the car steady and centered in the lane, just as software development is not just about submitting code that passes linter's quality check. Good programmers are always aware that there are many more important problems to solve."
The novice nodded in agreement. But then, as if suddenly struck by a frightening thought, he said hesitantly, "However, the technology for assisted driving is constantly evolving. There will come a day when drivers on the highway will be able to completely let go, without having to do anything at all."
Upon hearing this, the master glanced at the ChatGPT window on the screen and fell into deep thought. Finally, he spoke deliberately, "Yes, you're right. I think the same applies to software development." Then, the master suddenly stood up and walked slowly towards the green grass outside the door, his figure appearing somewhat forlorn.
Author's comment
Since the advent of tools like ChatGPT and GitHub Copilot, the software development industry has undergone tremendous changes. Such AI tools have made programming easier than ever before, further increasing the efficiency of programmers.
While AI tools currently excel at solving well-defined, smaller programming problems, one wonders if, as it's capabilities evolve, AI could completely replace humans in the development of more complex software? I believe time will tell us the answer.