“This is the 11th day of my participation in the Gwen Challenge in November. See details: The Last Gwen Challenge in 2021.”

preface

Hello everyone, I’m L La Rami, today to share with you how the average programmer advanced for the legendary clock “ten times programmer”.

01 Efficiency problem

The more efficient programmers are, the more productive they are, and the more productive they are, the more capable they are, creating an enhancement loop. However, as far as I am concerned, most programmers in reality do not think about learning efficiency with heart.

In 1975, Frederick Brooks published his seminal work on the software industry, The Myth of the Man-Month. He calculated that good programmers were 10 times more productive than average programmers.

More than 40 years on, this number has gained general acceptance in the industry, and becoming a 10X programmer is something many programmers aspire to. So, the question comes, as a programmer, how should we improve our work efficiency?

02 Thinking Frame

Before polishing 10x efficiency, we asked ourselves three questions:

  1. Where do we want to go?
  2. Where are we now?
  3. How are we going to get there?

We can try to answer:

  1. I want to be an architect
  2. I’m just a rookie now
  3. I plan to get an introduction to architecture design through half a year’s training

or

  1. I want to transfer from technology to product manager
  2. I currently know nothing about product managers
  3. I plan to study for two months as a product manager

It seems that no matter who you are or what you do, you can think in this three-part way. It’s a frame of mind. It’s simple, but it works, and SOMETIMES I find it works for kids, like

  1. During the summer vacation, I will prepare my English for the next grade
  2. I am now at the level of the second semester of grade two
  3. I intend to accomplish the task through project management

Why this frame of mind?

  1. Where exactly is it goingObjectives and directions
  2. Where is it clear nowStatus and coordinates
  3. What are you going to do to be clearMethodology and thinking path.

In turn:

  1. If you are uncertain about the future, even though you know to work hard, butWhere should I push? If you push in the wrong direction, the harder you push, the farther you may go on the wrong road.
  2. If you have a clear goal and you’re not realistic about it, you may be halfway thereFall into a pit.
  3. If you have a clear goal, you know what’s going on, but your approach is too lower and your thinking is too confused, the result may beThe wasted effort.

You can try to use this frame of mind, or some variation of it, and maybe you don’t have to remember that much, but that’s okay, you just have to remember this picture up here.

03 Change the query object

We further practice the framework through regular communication with product managers. In the above hypothesis, we ask ourselves. In the process of communicating with the product manager, we can also change the question:

  1. Why this feature, and what value will it bring to users?
  2. Not now, is it a must, or is it a pseudo requirement?
  3. How will users use this feature, in what situations, and how?

If the product manager can answer these questions well, it shows that he has thought the job through, and then I feel comfortable with the details.

Let’s frame the question. Why? Generally, we know the current status of the system before development, so I am more concerned about the final goal, here “why do this function” is to ask the goal, “what value to the user” is to ask the rationality of the goal, to ensure that it is not fake requirements. Next I’ll look at the implementation path, how users will use it, and whether there are alternatives. I need to know if the product manager’s thought process for designing is deliberate or brainless. To measure effectiveness, the goal is to ensure that my work is not wasted.

04 Practical Principles

Above we understand how to use the framework, you may say I understand why to do this, but how to ask specific questions, are there any practical principles? Here are five principles to consider:

  1. To begin with the end;
  2. Task decomposition;
  3. Risk management;
  4. Reflection review;
  5. Automation.

These principles are in fact consistent with our mental framework:

  1. To start with the end is to identify yourself at the beginning of the jobThe targetWe need to see real goals.
  2. Task breakdown is the breaking down of a large goal into actionable tasks. The more detailed the task breakdown, the better we can control the taskThe path.
  3. Risk management is to ensure that the process is controllable, multi-party communication channels are unimpeded, opinions are consistent, and work omissions caused by misunderstanding should be reduced.
  4. The purpose of reflection is to iterate the working method, improve the shortcomings in the work, and make better preparation for the next round of the cycle.
  5. Automation is the advantage of programmers, can rely on the machine to do things as far as possible do not manually executed, this is the most worthy of optimization of our work.

The above principles are based on the project management approach, of course you can add variations, but the backbone remains the same.

As shown in the table:

  1. Now I know where I am, what I have, what I give up, and if I don’t know, I’ll beat myself on the head.
  2. Where do we want to go is the beginning of the end, what results should we deliver by the deadline of the milestone?
  3. How to plan to go is the means and implementation path, here draw lessons from the project management method.

With these principles in mind, let’s look at best practices:

The product manager puts a list of features in front of us, and from a start-to-finish perspective, I need to understand what the real goal is, so I care about why I’m doing this feature. In order to ensure that the goal is effective, I care about the value it brings to the user.

With the perspective of task decomposition, I need to break down a big goal. If I want to achieve this goal, the overall solution is far from enough, and I need to break down the task into small parts. So, I’m going to be concerned about specific usage scenarios. On the one hand, I learn more details, and on the other hand, when time is tight, I talk to the product manager about which scenario to prioritize.

Why learn risk management? Because I need to make sure that I really understand the requirements submitted by the product manager, and that I am consistent with the content explained by the product manager? What is the worst that can happen? Can you bear it? The purpose of risk management is to ensure that the task goes smoothly on schedule.

Some people wonder, why is there no communication feedback? The purpose of communication is to reach agreement and act immediately. If communication fails, that is a way of managing risk, so there is no independence here.

In fact, risk management involves a very wide range of areas, throughout the whole research and development life cycle, because of the risk of demand changes, design may have bugs, development bugs, incomplete testing, etc., can not be overemphasized.

Automation is the means, and the solution we do is usually an automation solution, but we need to understand how the solution was done before automation. If not automated, how will users use it? So I would care if there were alternatives, like buying an off-the-shelf service.

Reflection reflection is an important closed loop of the process. If this link is missing, the whole thinking frame may be solidified and die out due to the lack of flow injection.

05 summary

Most of us are unproductive because we don’t have an effective mental framework, and the occasional complexity of our work naturally diminishes our “real” productivity.

To reduce the cost of accidental complexity, it is necessary to understand efficient ways of working and industry best practices, all of which can be thought through in a unified framework.

Using this framework, we need to ask ourselves three questions:

  1. Where are we now?
  2. Where are we going?
  3. How can we get there?

To apply this framework to our work as programmers, I give you a few practical principles:

  1. Take the end as the beginning, determine the ultimate goal;
  2. Task decomposition, find the implementation path;
  3. Risk management and control to solve problems that may occur in the process;
  4. Reflect on the review, preserve the vitality of the thinking frame;
  5. Automation, solve the problem of dealing with machines.

If you can only remember one thing from today’s lesson, remember this: when confronted with a problem, always use a mental frame to ask yourself where I am going, where I am, and how I should get there.