loading...
Cover image for The ONE search you should perform before you start learning

The ONE search you should perform before you start learning

pavlosisaris profile image Paul Isaris Originally published at paulisaris.com ・4 min read

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! ;-)

Posted on by:

pavlosisaris profile

Paul Isaris

@pavlosisaris

Software Engineer @SciFY. Live to learn something new -and write cleaner and more sustainable code- every day. Passionate with learning and discovering new technologies, history, and psychology.

Discussion

markdown guide
 

Excellent stuff Paul! I want to add a few caveats to when I believe your proposed approach is appropriate.

1) The understanding sought is more of a tool than a piece of foundational knowledge. This should not be something you intend to understand deeply and fully from this learning project. You are looking to get on board quickly, evaluate the technology, and may learn more about it from there if you like the tool and feel the need to master it.

2) The thing that you are wanting to learn is not part of your theoretical foundation as a professional. It is instead part of a wide variety of useful tools which are all a little different but relate to a much smaller set of core ideas that you have an extremely good intuitive grasp of.

If these conditions are met, I believe your approach is wise!

For true beginners, learn a lot about any one language before playing around with frameworks and random tools. The former is gold and enables you to understand the rest with ease. The Pareto principle does not apply in this way to the type of learning you need to do at this stage - you need immersion rather than distraction.