How to Learn new Technologies: Prometheus Example

Illustration of a child carrying a large teddy bear past a box labeled 'MEMOS' overflowing with toys and heading towards an empty box labeled 'TRASH'. Illustration of a child carrying a large teddy bear past a box labeled 'MEMOS' overflowing with toys and heading towards an empty box labeled 'TRASH'.

People with not so much experience in programming or related IT areas normally do not know what to focus on when learning new technologies and concepts.

Because of lack of focus, they tend to spend a lot of time on learning not so important things.

If you struggle with figuring out how to learn effectively, this article is for you.

I've learned and used a lot of different technologies during more than a decade of my career. I distilled a simple rule that allows me to pick up any new technology in the shortest time possible. This rule sounds like this:

Learn the concepts and principles, never memorize technical details.

Let's take a popular monitoring system, Prometheus, as an example.

You need to understand that Prometheus is capable of automatically discovering monitoring targets by using Kubernetes API.

You do not need to memorize configuration options to achieve this. Do not attempt to store in your brain how exactly to define certificate path or the API token. This information is always one internet search away from you.

It's tempting to delve into miniscule details. You might have a fear that someone will ask you about those details on an interview. I get it, I've been there. To conquer this fear, let me give you one more rule:

If during interview you are asked questions that require rote memorization of easily searchable information, then, most likely, you are being interviewed by a fool and probably you should not work for that company anyways.

Any senior developer knows, that what counts is the understanding of principles and concepts and the ability to solve problems.

The questions you might have now are "how do I figure those principles and concepts out?", "how do I understand what matters and what doesn't?".

The answer is simple and universal: if you are not able to explain in clear manner how something works, then you don't know it yourself.

Imagine a colleague of yours drops by and asks you to explain something related to your work.

If instead of a clear, structured explanation you start overloading your colleague with random facts and unrelated details, then you don't understand it yourself.

In addition to this rule I gave you, there are 2 additional sub-rules to remember:

Delving into details matters for an important project

If you are tasked with a new project that requires you to make a lot of technical decisions, you have to go beyond principles.

At this point, it's not about learning the technology.

You have to compare available options, read as much available information as possible, check the bug tracker of projects, seek experience of people who worked with this technology and so on. You also have to conduct proof of concepts, do performance tests and what not.

Principles do not substitute the experience

Even if you truly understood some technology, do not pretend in your CV to be an expert in it.

Only when you actually worked with this technology and, ideally, worked with it in a production environment, you can claim that you've learned it.

You can't fake the experience. And experience is not, once again, about rote memorization. Do not overload your brain with memorizing things you can quickly lookup in the internet.

To sum it up, simply reading books and memorizing documentation won't get you far. Focus on understanding the principles and acquiring as much practical experience as possible.

Here's the same article in video form, so you can listen to it on the go: