This article originally appeared on my personal blog.

Introduction

As software engineers, there is quite often a need to learn a new programming language, framework or library so as to use it in a new project or enhance an existing codebase.

Continuous learning is integrated into our workday and often times it requires time after work (evening or weekends) which can turn out to be a dull process and add to an already growing burnout feeling.

It is obvious that we always try to optimize this learning process, to have better results. This optimization doesn't really mean to learn as much as possible in the shortest possible period of time, but to manage to adapt the Pareto Principle in learning.

What’s the 80/20 Principle?

The 80/20 principle, also known as the law of the vital few and the Pareto principle, is very popular among people who want to become more productive. The principle states that 20% of causes attribute for 80% of the effects. The remaining 20% of effects are caused by the remaining 80% of the causes.

Consequently, when learning a new technology/ framework/ language, one should strive and identify the 20% of characteristics that will allow one to use the 80% of the technology/ framework/ language's attributes and functionality.

To set an example, while in the process of learning Angular, I found out that in order to use the 80% of the framework's functionality and start building apps, I had to learn about 20-25% of the entire framework, which can be summed up to a list:

1. Components
2. 2-way Data Binding
3. Observables
4. Singleton Services and Angular's DI
5. Routing

Disclaimer: I know that many might disagree and argue that there are more in Angular than those characteristics, but remember that the requirement is to learn the minimum that will let you start building apps and, to be frank, be able to build the 80% of an app ;-). If indeed you find the list above preposterous, absurd or ridiculous, just keep reading, since it was posted just for the sake of the argument.

Having said that, the Pareto principle is indeed a "sweet spot" for studying, especially when, as a software engineer, one has to study different technologies every day, not just for the sake of studying or to get a college grade, but in order to build production systems that people pay for.

So, back to the article's main subject! In my opinion, before start studying a new technology, you should perform the following search:

"Why [TECHNOLOGY/FRAMEWORK HERE] is bad"

Googling "Why [TECHNOLOGY/FRAMEWORK HERE] is bad" when learning about[TECHNOLOGY/FRAMEWORK HERE] is definitely not the first thing one does when start learning. Most times, we Google about tutorials, official documentation pages, guides, and begin building "Hello worlds" and simple applications (given that we managed to install all the dependencies...).

The "problem" with tutorials

Tutorials and documentation guides are the standard way we learn a technology or a framework. We usually go to the official documentation website or find a popular blog and dive right in.
These tutorials are indeed great in advertising and promoting the pros of the framework. They give you examples that are meant to be really easy to implement. This is what we call "Happy path" or "Sunny day scenarios". Everything goes exceptionally good, no exceptions are thrown and no compilers are whining and warning.

But we know that this is a software utopia and deviates much from what we experience in a normal workday.
Googling about the cons and weaknesses of a framework will let us observe what engineers stumbled upon in their learning journey before us (and made them write an article about it...). It will show us the perspective of someone who was in our shoes sometime before and tried to do exactly what we are right now, and felt the urge to document it so that someone will learn from it.

So, why skip the opportunity to talk to our future self?

Sure, learning the syntax and gaining confidence in how the framework is used is important. After all, we are the ones who will use it so this time investment is definitely not in vain.

However, every time I have used the Google search I described above, it has helped me identify the weaknesses of the framework, or even made me reconsider whether the framework is indeed the best solution for the project. As you can imagine, this persuaded me to pick another technology and saved me tons of time, of course.

Reading other people's "struggling stories" about something gives us a better overview of the subject under consideration. We have the opportunity to learn even before failing and to see how a person who is like us fought the same difficulties as we are about to face.

When searching for a new technology or framework, the key is not to be attached to it, but learn how to identify whether it will actually be of help or not. Do not be that guy that is seen as an "Angular fanboy" or a "Java know-it-all". Frameworks and technologies are tools for building applications, not something to be obsessed about.
They weren't here since the beginning of time, nor will they still be here forever.
They will be succeeded by other technologies, which will require additional learning and searching.

Learning how to detach from feelings about a technology or a framework, makes one more pragmatic. It builds up a level of wisdom in us and makes us better at deciding whether a technology is the best solution, or which parts of a framework are to be invested in.

So, next time you are about to start learning, begin by Googling! ;-)