Basic Concepts of the 80/20 Principle
This principle holds that most effects arise from a small number of causes. For example, a few people get most of the income, a few researchers do most of the innovations, a few authors write most of the books, etc.
You've probably heard of the 80/20 principle -- it's everywhere in the personal productivity literature. There are two reasons for its popularity. The first aspect, as long as you can identify the important things, the 20% of activities that lead to 80% of the results, and focus on these activities relentlessly, the 80/20 principle can keep you relaxed and efficient at the same time. In the second respect, we can observe this principle in so many cases that it has considerable confidence that it is even difficult to think of cases where the effects are equal in number to the causes. Try to find examples of a 50/50 distribution, where 50% of the effects come from 50% of the causes. Of course, the exact distribution isn't always 80/20, the exact numbers can become 70/30, 90/10, or even 95/5, but it's always heavily skewed towards a small number of causes that produce most of the effect.
We use the Pareto distribution diagram to illustrate the Pareto principle, as shown in Figure 2-1.
In Figure 2-1, the Pareto distribution is represented by effect (vertical axis) and cause (horizontal axis). An effect can be any measure of work success or failure, such as revenue, productivity, or the number of defects in a software project. A cause can be any entity associated with these outcomes, such as an employee, business, or software project. To obtain a well-characterized Pareto curve , we rank the causes according to the effects they produce. For example, the person with the highest income is first on the horizontal axis, followed by the person with the second highest income, and so on.
productive forces
By focusing on the critical few instead of the trivial many, you can increase productivity by a factor of 10, or even 100. Do not believe it? Let's do the math where those numbers come from. Let's start by assuming a basic 80/20 distribution.
We will calculate the productivity of each group using a conservative 80/20 parameter (80% of the work comes from 20% of the people). In some fields (such as programming), the distribution ratio may be more exaggerated.
Figure 2-3 shows that in a company with 10 employees, 2 employees produce 80% of the results, while the remaining 8 employees only produce 20% of the results. Dividing 80% by 2 employees yields an average output of 40% for top performers in the company. If we divide the output of the other 20% by 8 employees, the result is that the worst performers produce only 2.5% of the output on average. The performance is a full 16 times worse!
The 16x average performance difference is a fact that exists in millions of organizations around the world. The fractal nature of the Pareto distribution means that differences in performance are even more pronounced in large organizations with thousands of employees.
The difference in results cannot be explained by intelligence alone -- one person cannot be 1,000 times more intelligent than another. The difference in results comes from the specific behavior of individuals or organizations, doing the same thing can get the same result. Before changing behavior, however, it's important to be clear about what outcome you're trying to achieve, because research shows that outcomes are wildly unequal on almost any metric you can imagine.
What it means for programmers
In programming, the results of the Pareto distribution tend to be more heavily skewed towards the top than in most other fields. The distribution is not so much 80/20 as it is 90/10 or 95/5. Bill Gates said: "The salary of a top lathe operator is several times that of an ordinary lathe operator, but the value of a top software developer is 10,000 times that of an ordinary software developer." The difference between software developers is not 16 times, but 10,000 times! Here are a few reasons why the software world is prone to this extreme Pareto distribution.
● Top programmers can solve some problems that ordinary programmers cannot. In some cases, they even gain countless times the productivity of ordinary programmers.
● Top programmers can write code 10,000 times faster than average programmers.
● Top programmers have fewer code defects. Think about what a security flaw could do to Microsoft's goodwill and brand! Moreover, each defect subsequently costs time, energy, and money to modify the code base and add features-a defect that harms the present and affects the future.
● Top programmers' code is easy to extend. In the subsequent software development process , when thousands of programmers work on this code base, their productivity will be improved.
● Top programmers think outside the box, find creative solutions, avoid costly development work, and help teams focus on what matters most.
In practice, these factors work in combination, so the difference may be even greater.
So, the key question for you might be: How do you become a top programmer?
Programmer's Success Metrics
Unfortunately, the phrase "becoming a top programmer" is not a directly optimizeable metric of success. The problem has multiple dimensions. Top programmers understand code quickly, understand algorithms and data structures, understand different technologies and their strengths and weaknesses, collaborate with others, communicate well, be creative, learn continuously, understand ways to organize the software development process, master hundreds of soft and hard skills . However, you can't be the best at everything. If you don't focus on the critical few, you will be overwhelmed by the trivial majority. To become a top programmer, you must focus on the key few.
One of the priorities is to focus on writing more code. The more code you write, the better you will write it. This is a simplified version of the multidimensional problem: Optimizing on the representative metric (writing more code) can make progress on the objective metric (becoming a top software code expert), as shown in Figure 2-8.
The more code you write, the more you understand it and act like an expert. You'll meet better programmers, take on more challenging programming tasks, write more code, and become better. Every line of code you write pays off more and more. You and your company can outsource a lot of trivial work.
Here's an 80/20 activity you can do every day: keep track of how many lines of code you write, and optimize for that metric. Just think of it as a game that achieves daily code averages .
This article is an excerpt from Chapter 2 of The Art of Clean Code .
[German] Written by Christian Mayer, translated by Han Lei, Yan Min, Ma Feixiong
Programmer's practical reference book, the crystallization of years of experience of the founder of the Python website Finxter . Pass the idea of "reducing and simplifying" code writing, and teach you to apply the nine principles to improve productivity and achieve twice the result with half the effort.
Most software developers waste a lot of time on complex code. The nine principles presented in The Art of Clean Code will teach you how to write clean, maintainable, and fully functional code. The guiding principles of this book are simple: reduce and simplify, put energy into important work, save a lot of time, and relieve the burden of code maintenance.
Best-selling author Christian Meyer uses his experience to help programmers perfect their coding skills in this book. He gives professional advice and real-world examples showing how to: use the 80/20 principle to focus on important tasks—the most important 20% of code; avoid coding in silos, create a minimum viable product, and get early feedback; write clean, simple Code, eliminate confusion; avoid premature optimization that leads to overly complex code; balance your goals, capabilities, and feedback to achieve a high-yield flow state; apply the "do one thing well" philosophy to greatly improve code functionality; leverage " Less is more " philosophy, designing effective user interfaces; use the principle of "focus" throughout these new skills learned.
This book uses Python as the example language, but presents concepts in a language-independent manner, suitable for programmers of all levels.