Conclusion: Do Less to Work More Effectively #

Hello, I am Zheng Ye.

In this column, I have talked about many things, almost covering all aspects of software development. However, there is one important aspect that I have never mentioned, and that is algorithms.

I have always considered algorithms as a fundamental skill that every programmer should master, so I never felt the need to discuss it. In the conclusion of our column, let’s start with this untouched topic!

Differences in Algorithms #

Sorting algorithms are something every programmer will learn, and we all cherish various algorithms: insertion sort, bubble sort, merge sort, heap sort, quick sort, and so on. We are also aware of the complexity of each algorithm, such as insertion sort with a complexity of O(n^2), quick sort with an average case complexity of O(nlogn), and so on.

Have you ever wondered what the essential difference in complexity between different algorithms is? Let’s take insertion sort and quick sort as an example. Why is quick sort faster than insertion sort?

I don’t intend to do algorithm analysis; I’ll just reveal the answer: quick sort performs fewer comparisons. Why do the number of comparisons differ for the same sort? This is because insertion sort only focuses on the current target during each loop, and the loops are independent of each other. On the other hand, quick sort’s previous results are helpful for the next partition, thus saving a lot of comparison times.

Understanding this principle, let’s take a look at algorithm optimization, which is actually about making the best use of known information and avoiding unnecessary operations as much as possible.

Let’s consider a common interview question: given a bunch of numbers, find the top 100. Many people will instinctively think of sorting and then selecting the top 100. This approach is feasible but definitely excessive. Here, what we need is to find the top 100 numbers, not 100 sorted numbers, let alone having all the numbers sorted.

Having said that, you now know that as long as the data is divided, it’s fine. No sorting is needed. If the partition point is not the 100th element, then continue dividing in the direction of 100.

Computers are best at handling tedious repetitive work, but even so, we still need to optimize algorithms. The reason is that when the data size reaches a certain level, the difference in complexity between different algorithms becomes very obvious. If the algorithm is not utilized effectively, no matter how good the computer hardware is, it will be in vain.

There is an anecdote about Donald Knuth, the author of “The Art of Computer Programming.” When he was young, he participated in an algorithm competition and defeated many opponents with the worst system, winning the championship for algorithm execution efficiency, relying on his powerful algorithm optimization skills.

For computers, algorithms are so important, and the same applies to us when facing work!

Effective Work #

“10x Programmer Method”, perhaps some students hurriedly joined when they first saw this title, thinking that they would learn some “one-for-ten” programming techniques from this column. I’m sorry, I completely let you down. Not only did I not talk much about programming techniques, I even advised you from various angles to write less code: whether it’s asking questions to the product manager or making you think more about design.

Isn’t the more you do, the more efficient you become?

Insertion sort does not receive higher praise than quicksort just because it does more work; they compete on who sorts faster. High work efficiency is not achieved by writing more code, but by doing more effective work.

If the CPU is occupied by ineffective instructions, where is the time to execute effective instructions? Even if you are busy, the progress of your work is still minimal because ineffective work occupies too much of your brain, preventing you from focusing on important tasks, and of course, efficiency will suffer.

In fact, the content of this column has been spiraling in my mind for many years. However, even during the planning period of the column, after I prepared many drafts, I still couldn’t find an accurate way to describe my thoughts.

I thought of “professional qualities of programmers”, but it seemed that this would lead the column towards the direction of a career action guide; I thought of “effective work”, but in reality, I don’t intend to discuss those work skills. It wasn’t until the deadline was approaching and my editor couldn’t stand my procrastination anymore, that she sat down and talked with me for a long time, and I finally found the word that resonated with me: effective.

The real theme I want to discuss in this column is effective work.

Effective work requires us to focus our energy on the right things, to do essential complexity tasks and to do less meaningless tasks.

I used to work as a consultant in a large company, and according to their statistics, 60% of the code online has never been executed. We all know that adding more than half of the code does not only add more than half of the workload. The team may need several times or even dozens of times the mental effort to maintain it.

Of course, effective work didn’t become the name of this column in the end, and a more distinctive name “10x Programmer Method” was chosen. This name is also good because in my opinion, many programmers are doing negative work, such as the programmer who writes that 60% of the code. As long as you can achieve effective work, your efficiency will naturally be much higher than the industry average.

How can we achieve effective work? I have already talked about it a lot in this column, and here is a summary:

• Expand your context, see the real goals, and better aim at the target. For example, understand the users more so as not to go in the wrong direction; see from the company’s perspective to understand which task has a higher priority; see from the industry’s perspective instead of limiting yourself to becoming an expert only within the company, and so on.

• Remove unnecessary content, reduce waste. For example, spend time analyzing requirements and avoid unnecessary functionalities; spend time on domain design rather than revolving around specific technologies; spend time on automation and focus your energy on coding, and so on.

To achieve effective work, two points are very important. On the one hand, you need to be aware of the ineffective parts of your work. It’s like a switch, just flip it. So, when reading this column, some people have a sudden realization, while others find it very simple.

Many times, you just don’t know, like I mentioned in the column, to ask questions to the product manager, which many people have never thought of. The concluding sentence after each article is like a switch, just flip it.

On the other hand, you need to build your own knowledge system about software development, and this takes time to accumulate. In this column, I have shared many best practices with you, so that you know that in certain areas, people have already done very well, and it’s much better to spend time learning than to start from scratch.

It’s like all mathematical formulas. Theoretically, you can derive them on your own, but surely it’s faster to learn them from a textbook.

Catalog of the Scripture Pavilion #

Although I have spoken so much content, in fact, due to the limitations of length, this is just the tip of the iceberg. Actually, the part I have told you is not specific knowledge, but rather I have told you what things to learn, given you a learning map, and connected various knowledge together.

I once jokingly said with my friends that my column is actually a catalog of the Scripture Pavilion, and the real scriptures still need to be comprehended by yourself. It’s just that someone has connected the knowledge between these scriptures for you. These connections are precisely what I pondered and meditated on when studying related content.

About a year ago (April 2018), the editors at GeekTime found me and asked if I was interested in having a column on GeekTime. As a heavy user of “Dedao,” I have always been interested in knowledge services. I certainly wanted to give it a try if there was such an opportunity, and I even initially set a grand plan to write 100 articles.

When I actually started writing, I realized that writing consistently was quite challenging amidst a busy daily work schedule. Looking at it now, the goal of 100 articles seems so naive and fearless.

However, it is precisely because the length has been compressed to about half that the density of knowledge in the later part of the column has greatly increased. For example, microservices and DDD, these two topics could each be written as a series of content. I condensed their essence and knowledge structure in just one article.

Because I wanted to do my best to help everyone build a knowledge system for software development, so that when you encounter problems in the future, you will know where to strengthen. I hope this column really helps you clarify your thoughts and provides answers to your questions.

Do you still remember the last paragraph of my opening words?

Perhaps at the end of this column, you find that you don’t agree with my principles, yet you are able to discuss with me using your own principles. Congratulations, because that is the most wonderful thing!

I wonder if you have formed your own principles? Feel free to share with everyone, as it represents that you have formed your own knowledge system. What you have learned is more important than what you have told me.

I hope that after studying this column, you can use your own work principles to accomplish more tasks with essential complexity and reduce meaningless time consumption.

In fact, the biggest beneficiary of this column is myself. Thanks to this column journey, I finally addressed my procrastination and organized my thoughts on effective work. Those vague impressions in my mind finally have a complete system. This system is the work principles I mentioned in the column, and now I can better express my ideas.

However, there are regrets for me with this column as well. Because there are so many things I wanted to express, while opening more doors for everyone, it also left many students with more questions.

Some students expect to go deeper into certain aspects, such as DDD, which is worth another column. Due to the theme and length limitations of this column, I have no way to delve into it, so I can only say sorry to everyone.

If there is an opportunity in the future, I will come again to share my understanding of software development with you. This journey of “The 10x Coder’s Work Method” has come to a temporary end!

Goodbye!