01 10x Programmers How They Think

01 How do 10x programmers think? #

Hello, I am Zheng Ye.

In the Preface, we mentioned that many problems encountered by programmers in their work are not programming problems. The hard and inefficient work is mostly caused by accidental complexity. How big is the difference caused by accidental complexity?

In 1975, Frederick Brooks published the classic book “The Mythical Man-Month” in the software industry, and he provided a statistic that the development efficiency of excellent programmers is 10 times that of ordinary programmers. Over 40 years have passed, and this number has been widely recognized in the industry.

Becoming a 10x programmer is the pursuit of many programmers. However, work output is not solely determined by the efficiency of writing code, as inappropriate work methods greatly affect your output.

In the following period of time, I hope to explore with you through this column how to work more efficiently as a programmer and how to devote time and energy to dealing with essential complexity, while reducing consumption on accidental complexity.

As the first lecture of the entire course, I will start with a thinking framework that I often use.

A Framework for Reflection #

I have previously organized training sessions for recent graduates, and in the first class I always take charge. One of the brainstorming activities is called “Imagining the Future,” where I ask everyone to consider three questions:

What level am I at currently?
What level do I want to reach?
How will I reach that goal?

Participants will discuss these three questions from various angles. It’s an interesting exercise, as you will discover that most people excel at answering the first question: What level am I currently at? Compared to experienced individuals, they often consider themselves relatively inexperienced. However, when it comes to discussing the latter two questions, you can truly see the differences in problem-solving abilities among individuals.

Some people already have plans for their future based on prior research. For example, they may aspire to become a development expert or contribute to open source software. In other words, they have a clear answer to the second question.

On the other hand, some people have a bewildered expression and may not have considered this question at all. From the question itself, it can be seen that only the students with relatively clear goals will move on to the third question, while those who are confused are completely at a loss for where to start.

So why do I ask these questions? I want everyone to break free from their current thinking patterns, shake off the habit of working solely on intuition, and raise their heads to look into the future and find a direction for themselves.

Otherwise, if you have no orientation for the future and feel bewildered, even though you know you have to work hard, where should you aim your efforts? If you put forth effort in the wrong direction, the harder you try, the farther you may run on the wrong path. Everyone understands the principle of moving in the wrong direction, but when it comes to their own work and development, only a few truly experience and practice it.

In fact, these three questions come from a framework for reflection. When providing consulting to other company teams, I often use this framework. The original questions are:

Where are we?
Where are we going?
How can we get there?

These three questions actually help us determine:

The current situation.
The goal.
The path to achieving it.

If a person can clearly answer these three questions, it usually means they have a clear understanding of what they need to do. Although this framework appears simple, it is highly effective and has become a very handy tool in my toolbox for thinking.

Throughout my career, when discussing various matters with many people, I have used different variations of this thinking framework. In this column, I will also use it to help answer questions about efficient work and how to excel in software development.

Four Thinking Principles #

In practical work, this thinking framework helps me better understand my job. For example, when a product manager assigns a feature to be developed, I usually ask him or her some questions:

Why do we need this feature and what value will it bring to users?
What kind of users will use this feature, in what scenarios, and how will they use it?
Are there any other means to achieve this goal? Is it necessary to develop a new system?
How can we measure the effectiveness of this feature after it is launched?

If the product manager can answer these questions well, it means that he or she has a clear understanding of the work. At this point, I will feel relieved and proceed to understand the details.

Let’s compare the questions with the thinking framework. Generally speaking, when developing a new feature, I already know the current situation. Therefore, I am more concerned about the goal. The question “Why do we need this feature?” is asking about the goal, and determining the value it brings to users is to confirm the effectiveness of this goal.

Next, I will focus on the implementation path, how users will use the feature, and whether there are alternative means. I need to know if the product manager has given thought to the design or if it was a hasty decision. Measuring effectiveness ensures that my work will not be wasted.

Through this example, I have shown you how to use this thinking framework to ask questions. But I guess what you really want to know is how I come up with these questions. I provide this thinking framework to help you understand why it is important to ask questions. As for the specific questions, you can follow these four principles:

Start with the end in mind;
Task decomposition;
Communication and feedback;
Automation.

These are the extensions from the thinking framework. In this column, I will discuss these four principles in detail with you.

Let me explain. Starting with the end in mind means determining your goals at the beginning of your work. We need to see the real goals, rather than considering the assigned tasks as goals. You can see that this principle helps us answer the question “Where are we going?” in the thinking framework.

Task decomposition is breaking down a big goal into feasible tasks. The more detailed the task decomposition is, the better we can control the work. It helps us answer the question “How can we get there?” in the thinking framework.

If the first two principles are the analysis to be done before starting the work, the next two principles are the support on the path to the goal, because in practical work, we often need to interact with people and machines.

Communication and feedback is to ensure smooth communication with others. On one hand, we need to ensure that information can be conveyed accurately, reducing work omissions caused by misunderstandings. On the other hand, we need to be able to receive external information accurately, so as not to hinder progress due to a false sense of accomplishment.

Automation is to hand over tedious work to machines through automation. This is part of our programmers’ job. We are good at creating automation services for others, but we often fail to apply it to our own work. This is also the most important part of our work that needs improvement.

These four principles complement each other and form a measure for evaluating things. Overall, they can ensure that my work is effective and minimize accidental complexity in setting and achieving goals.

How can we apply these four principles to work? Let’s go back to the previous scenario: the product manager presents a feature for me to develop. From the perspective of starting with the end in mind, I need to understand what the real goal is. Therefore, I will be concerned about why we need this feature. To ensure the goal is effective, I will be concerned about the value it brings to users.

With the perspective of task decomposition, I need to break down a big goal into smaller achievable tasks. If I want to achieve this goal, the overall solution is not enough. I need to break it down into smaller parts. So, I will be concerned about specific use cases.

On one hand, I will learn more details, and on the other hand, when time is limited, I can discuss with the product manager which use case should be prioritized.

Why do we need to learn communication and feedback? Because I need to ensure that I truly understand the requirements submitted by the product manager. So, I need to ask questions continuously to ensure my understanding aligns with what the product manager has communicated.

Moreover, I also need to ensure that our product can truly achieve the goal. Therefore, I will be concerned about the measurement methods after the feature is launched. Because I know that in this industry, there are too many cases where the code is released without ever being run.

The perspective of automation is interesting. The solutions we create are usually automated solutions, but we need to understand how things were done before automation. If it is not automated, how would users do it? So, I will be concerned about whether there are alternative solutions, such as buying an existing service. Many requirements are raised simply because we have a development team.

Alright, now you have a clear understanding of how these four principles are applied in work. But you may also find that the questions I ask seem to go beyond what an ordinary programmer should focus on. But this is the real world, it’s not like an exam where there is a standard answer.

We are not working alone but collaborating with others. In order to work efficiently, we need to “look up” and go beyond just writing code. So, as I mentioned in the opening words, most problems that programmers solve are not just technical problems.

You may still feel that you haven’t fully satisfied your understanding of these principles, but that’s okay. This article is just to give everyone a clear understanding of the logic behind the thinking framework and principles. Next, I will further explain these principles and their specific applications based on industry best practices.

Summary Moment #

The main reason for most people’s inefficiency at work is the presence of occasional complexities. If we can focus more on the essential complexities and reduce the costs caused by occasional complexities, our “real” work efficiency will naturally improve significantly.

To reduce the costs caused by occasional complexities, we need to understand efficient work methods and industry best practices. All of this can be approached using a unified framework.

When applying this thought framework, we need to ask ourselves some questions:

Where are we now?
Where are we going?
How can we get there?

To apply this framework to our work as programmers, I have provided you with four thinking principles:

Start with the end in mind, define real goals;
Decompose tasks, find implementation pathways;
Communicate and provide feedback, solve problems related to dealing with people;
Automate, solve problems related to dealing with machines.

If there is only one thing you can remember from today’s content, remember this: When faced with a problem, use the thinking framework to ask yourself about the current situation, the goal, and the path.

Finally, I would like you to think about how you would answer these three questions if you applied this thinking framework to your career development plan?

Thank you for reading. If you find this article helpful, feel free to share it with your friends.