How to learn technologies in bulk or Why-Driven Learning

A chair - I believe you have at least one at home. There are dozens of chair designs, and some of them will make you unsure if it is actually one. But once you know that this is a chair, regardless of whether you have had any experience with this particular chair, you know what to do with it. You will be looking for a way to sit on it. Because you know that the main purpose or "why" of the chair is to hold your butt so you can work or enjoy your time. Why should not it be the same with technologies in Software Development?

There are dozens of tools and technologies you need to know and be able to use as a Software Developer. And there are more tools created regularly. Hence, it is overwhelming to keep up with it. And it is especially overwhelming at the beginning of a Software Development career. With this post, I aim to introduce the approach that was doing a great service for me and will serve you in learning all those technologies and tools. Enjoy the reading.

What is Why-Driven Learning and why it is useful

Here is how I Identify it: Why-Driven Learning - is the way of learning where you start with identifying the "why" or the main reason the subject of learning was created, its purpose of existence, and the problem one was aiming to solve by its creation.

If you need to learn technology, you start by identifying the main "why" of it. Once you identified the "why", it gives you an ability to perform educative assumptions regarding what the technology should be able to do before you opened its documentation. It will give you a clue of what the interface to expect. Then after you learned this tech, you can apply this knowledge to a tech that has a similar "why".

Here are a couple of reasons Why-Driven Learning is useful:

• It allows you to leverage the 80/20 rule. Getting the real "why" of a certain technology is the 20% of effort that will give you 80% of results with this technology. Learning to use this technology is 20% of effort that will give you 80% of results on other technologies with the same "why".
• It allows you to leverage the 40-70 rule. There are often situations when you need to decide which tool or technology to use for a project or for solving a specific problem you faced in Software Development. Especially if you are in a leadership position. Knowing the "why" of technologies will give you the range between 40-70% of the information necessary to make an optimal decision in a constant time.
• It serves as a pillar for defining the "right" and "wrong" ways of using any tool. When you start using new technology, you will often ask yourself: "What is the right or wrong way to use it?". And there will be a lot of controversial information on the internet that will make answering this question an uneasy task. If you know the "why" of the tech, you will have the foundation you can rely on when answering this question.
• It allows you to apply the Abstraction principle in learning. Abstraction is the "why" of technology. The way the technology achieves its "why" is an implementation detail. Implementation can change, but the abstraction should remain as is.

How it was helping me and how it will help you

Why-Driven Learning was a huge factor in my journey to become a self-taught Software Developer. It helped me to become familiar with sets of technologies in no time. As a result, I was able to quickly gain hands-on fluency with those technologies when I needed to apply them for real projects. Why-Driven Learning has done an irreparable good for my self-education skills as well as accelerated my career. So it will do for you if you give it a try.

Here are a couple of examples of how you can apply it in the context of a specific technology or concept, which is how I usually do it:

Programming languages. Their main "why" is to communicate human instructions to the machine.

There are many programming languages around. And there are even many programming languages made of other programming languages. But their main purpose did not change much from language to language. They only speak to the machine through the sequence, selection, and iteration.

Once you learned one programming language, you will notice that the other languages can do similar things. It is just that some languages allow you to do certain things easier than in others as they focused on specific domains. That is the next layer of "why".

For example, you can write a web application using Swift. But the purpose of its creation communicates that this programming language would not be the best choice for writing web applications.

Algorithms. The main "why" of an algorithm is to define specific steps intended to solve a specific problem or class of problems in a most efficient way or at least sufficiently efficient.

Once you understand the "why" of the real-world problem that a certain algorithm exists to solve, you will become more confident while learning this algorithm.

Databases. Their main "why" is to handle the data that is used by the software.

There are many databases created so far. But their main "why" remains the same. As a Software Developer, most often, you would just Crete, Read, Update, and Delete (CRUD) data to databases. And most likely, you would use some programming language for that. You do not necessarily need to dive into specific details of a database system to perform these operations. Well, at least before you have the project that requires this knowledge.

Once you learned how to work with PostgreSQL, you will automatically have fluency with MySQL and similar Relational (or SQL) databases. Then you can dive into learning the details on demand.

Although NoSQL databases differ from Relational databases, their main purpose is still the same. If you start working on a project that uses NoSQL, you can fairly assume that one has some straightforward ways to perform CRUD operations. Hence, you already know what you need to search for in the documentation.

Configuration Management. The "why" of these tools is to control changes and maintain software consistency and integrity. So when certain software uses dozens or hundreds of servers, configuration management will help to ensure that each time something about the software has changed, it is seamlessly and consistently changed in all the servers.

There are a few tools I know in this software category: Chef, Ansible, Puppet. They are different in many ways, but their main "why" is similar. So once you understand what Configuration Management is, it would be a lot easier to start learning any of them. Then when you have, for example, Ansible one under your belt, it will be easy to approach Cher of Puppet when necessary.

CI/CD. CI - stands for Continuous Integration. The main "why" of CI in Software Development is to ensure that the code each team member writes is merged with the main codebase often to decrease the probability of possible change conflicts. CD - stands for Continuous Delivery or Continuous Deployment. The main "why" of CD is to ensure the code the team develops is released frequently. So there is no such thing as the "release day" that skyrockets the heart rate of everyone.

There are many CI/CD tools. Although each of them offers different perks and features, all of them share the same "why". Hence, once you understand the purpose of the concept, it will be easier to get hands-on with at least the first one. Then you will have the confidence to work with all the other tools when necessary.

Caching. The main "why" of this concept is to temporarily store the data that is most likely to be re-requested, in a fast accessed place so that future requests can be served faster.

The main challenge of using the caching systems is to know how to write to cache, so the data is not inconsistent with permanent data storage - Cache Invalidation. And when to evict the cache assuming that this cache becomes one that is less likely to be used - Cache Eviction.

There are many cache systems and tools around, but they all perform within the "why" scope of the caching concept.

For example, assume you decided to use Redis as a caching solution for your project. With the knowledge of what is caching about, you can fairly assume that there should be a way to configure things that are related to caching overall (like Cache Invalidation policy, Cache Eviction policy, etc.) without diving into specifics of Redis. Later, when you faced some other caching tool, for example, Memcached, you can use the same approach and derive from the "why" of the caching as the concept.

Before you go

I was happy to introduce you to the concept I named Why-Driven Learning. We have covered what this concept is about, why it is useful, and how its usage can accelerate your learning of new technologies. Consequently, you can apply it to keep up with the modern world and be on the top of the Software Developer game.

Next time when you approach learning any technology or tool, I encourage you to ask yourself: "Why the technology actually exists and which problem it intended to solve?". Then go deep in answering this question before diving into any details of how to use it. It might not always be easy to define the main "why". But I promise, once you feel the power of this approach, you will never stop doing it.

“He who has a why can bear almost any how.” - Friedrich Nietzsche (originated from)