00 Preface: The Problems Programmers Solve Are Often Not Technical Problems #

Hello! I’m Zheng Ye, a programmer.

Many people say that programmers work very hard, and the words commonly associated with this role are usually busy, overtime, and staying up late.

As programmers, we consider it a career worth wholeheartedly investing in, hoping to focus our energy on designing algorithms, improving designs, and optimizing systems - work that is creative and fulfilling.

However, the reality is that many people find themselves endlessly busy due to some “accidents”, such as:

• You painstakingly write code, but the product manager tells you that the requirements have changed before your code even goes live.
• You work overtime because you underestimated the workload, feeling regretful but determined to get it done.
• What you’ve worked hard on doesn’t meet the requirements and you have to start from scratch.
• You have to make extensive code modifications simply because of poor design that cannot adapt to new requirements.
• …

These are just a few examples, and there are countless others. We work hard, but the work that consumes a significant amount of our time and energy is often not technical work, but rather these seemingly “unworthy” tasks.

Why is it like this?

In the software industry, there is a famous book called “The Mythical Man-Month”, which introduces two very important concepts: essential complexity and accidental complexity.

In simple terms, essential complexity refers to the necessary work that must be done to solve a problem, regardless of the approach. Accidental complexity, on the other hand, arises from poor choices in methods or tools, resulting in additional work.

For example, if you want to build a website, writing the content is something you must do, which is the “essential complexity”. However, if you’re still using assembly language to write a website, it’s impossible to achieve high efficiency because you made the wrong choice of tools. Problems caused by such wrong methods or tools are examples of “accidental complexity”.

After nearly twenty years of working as a programmer in the software industry, I have come to a regrettable realization: most of the problems that programmers busily solve are not technical problems, but problems caused by accidental complexity.

In other words, as long as you choose the right methods, you can reduce the workload caused by accidental complexity and carry out software development in an orderly and efficient manner.

How to reduce the problems caused by accidental complexity and make software development work organized and efficient is exactly what I hope to help you solve through this column.

Many people rely mainly on intuition in their work. In this era where science is flourishing, we can clearly see that human intuition is often wrong, just like how ancient people intuitively believed that the earth is flat.

Software development is no exception. If you have never learned and thought about software development, forming an efficient working method, and instead rely solely on intuition, you will often face great difficulties in the real world.

Fortunately, there will always be different people exploring different approaches in different directions. Once these approaches have been validated in the real world, they will become best practices that can be directly applied in the industry.

In the software industry, there are already many best practices that can improve work efficiency. However, learning and mastering these best practices can be challenging because it is difficult to find the inherent connections between them.

Intuition is mostly fallible, and best practices are numerous and intricate. Therefore, in this column, I will try to provide you with a thinking framework to help you organize the tasks you need to do when facing problems. Around this framework, I will also provide you with some principles.

These principles are derived from numerous software development best practices in the industry and are principles I adhere to in my work. They serve as a thread that connects various best practices.

There are only a few of these principles, which can be summarized as follows:

• Begin with the end in mind.
• Break down tasks.
• Communicate and provide feedback.
• Automate.

You may not find these four principles impressive when you see their names. You may have come across these terms in many places, but what I am going to share with you may not be exactly what you think.

For example, what you consider as “the end” may not actually be the end, because you are only seeing it from your own perspective. What you perceive as breaking down tasks may not be enough in my view, because I hope you can do micro-operations. What you think of as communication and feedback may just be talking and chatting, but I want to tell you that many technical practices also exist for the purpose of communication and feedback. What you think of as automation may be writing code, but I will tell you that sometimes solving problems without writing code may be the better solution.

In my view, in order to focus your energy on essential complexity, improve work efficiency, and free yourself from the limitations of intuition, as long as you grasp these four principles, it will be enough.

You might ask, aren’t these principles difficult? Actually, they are not. When my editor, who is not involved in software development, discussed the content of this column with me, they often exclaimed, “Is it really that simple? Isn’t this just the logical way of doing things?”

Yes, it is that simple, but most people don’t do it because these principles often go against intuition in practical work. Once you break free from these misconceptions, you will become a different person.

Below is the table of contents for the entire column. I hope it can help you answer questions you have encountered during the development process or clarify things you have not delved into deeply.

When we discuss these principles in detail, I will share with you some best practices, allowing you to see how these principles are applied in different contexts. I hope that my understanding of these practices will become your knowledge map, guiding you in the direction of further exploration.

The principle I follow in writing this column is “give a man a fish, and you feed him for a day; teach a man to fish, and you feed him for a lifetime.” I hope you will understand these principles well and master efficient methods of work. As for best practices, you can decide for yourself whether to directly adopt them or find alternative solutions.

Let me introduce myself. I am Zheng Ye, currently serving as the Chief Architect at Huobi, and I have written code, led teams, provided consulting services, started my own business, and maintained an open-source project called Moco that has won the Oracle Duke’s Choice Award. I am still writing code on the front lines to this day.

For a long time, I have been curious about how to do software development well and have learned various technologies and development methods. Through my experience in consulting, I have had the opportunity to witness the challenges faced by different companies. When leading a team, I also saw many junior developers who worked hard