In this article, we will go deeper into a simple principle: the 80/20 rule. And what are its implications. And how it can help us improve as programmers.
What is the 80/20 rule
With the 80/20 rule we refer to the Pareto principle, also known as the Law of the Vital Few. This rule says that when a group of people contributes to a common effect, it is the smaller proportion, 20%, that contributes the most to the common effect.
Another way to express it would be to say that for many events, 80% of the effects come from 20% of the causes.
The 80/20 rule can be applied to many cases and always helps to optimize our tasks. Let’s look into it now with specific examples, to understand how this principle can be applied to a programmer’s working day:
Taking into account the flexibility of the day
Flexible jobs have certain advantages over classic jobs. It often happens, for the worker who has to be from 9 to 5 in the office, that the last two hours become difficult. It is usually easier to work in the morning, when you are fresh, than in the afternoon, when you are tired and have spentmany hours. Here we see this rule applied: we did most of the work when we were fresh, in the first 20% of the day.
Therefore, adopting a more flexible work schedule with longer breaks and rest periods can help us optimize our work: every time we get to work we will do it freshly. And we’ll stop before fatigue sets in.
In this way, one can work in two three-hour shifts, putting a generous break in between, and surely produce the same or more than with eight hours of continuous work.
If we apply the 80/20 rule to the classic task list, we will see that of most tasks, 20% of them will take up 80% of your time, and then you will have many micro-tasks that you can do in a moment. Thinking about it, you can generate two lists:
- Tasks that can be completed quickly
- Slow tasks or tasks that require several days/sessions
Sometimes you start with a difficult task and spend your day invested in it. At the end of the day, you have the impression that you have not made any progress. With a double list based on the abstract criteria 20/80 we can finish some tasks from the quick list, and then be clear that the long projects are long term, and break them down into parts.
Making this kind of classification allows you to have more tasks finished in absolute terms and that is an element of motivation.
Join our Dev Area
Certify your coding skills through real-world tech challenges and get detailed feedback from senior engineers. With your skills validated you will be able to apply for our top job offers.
The 80/20 rule when creating a program
If we apply again the 80/20 rule to something more specific of the programmer’s work, making programs, we have the following statement: The final user will use only 20% of the total tools of the program. In that 20% you must put 80% of your effort.
Applying this rule to the set of features of a program, you can separate those that will be more used and focus first on them, thus having a defined priority criterion.
The 80/20 rule when studying
We can also apply the 80/20 rule to learning. You only need to learn 20% of a new subject to be able to start controlling it. In this sense, you must understand what that 20% is. If we speak of a programming language, we will seek to understand its logic and its foundations, before entering into the details of its functions, for example.
If we were talking about learning to play the guitar, we would focus on learning the chords and scales, and the general functioning of the instrument. By focusing on that we would have the basis to develop an infinite number of things. If, on the other hand, when studying we focus on secondary elements from the beginning, we can take much longer to understand something
Applied also to the debugging process
80% of errors are concentrated in 20% of the code. If you look carefully at this logic you will see that it makes sense. Where we make mistakes we are likely to make more mistakes than usual. So if we detect an error in the code, we should focus very much on that whole piece of code: we will probably find more errors nearby.
In the same way that in the previous cases, this simple rule gives us guidelines that somehow optimize our time and our work. In essence the rule tells us where it is worth to pay more attention to obtain a better result.