How to Know What to Learn and Whether I Really Understand It

Status: Learning Confidence: Medium Readiness: Draft / basic understanding Last updated: 2026-07-19

Why I Am Writing This Note

I went through elementary school, high school, and university. Everywhere, I was taught new knowledge. What I was never really taught was how to learn independently.

At school, the direction came from the outside. Someone defined the subjects, topics, tests, and what counted as important. At work it was similar, only more practical: I mainly learned what I needed in order to finish a concrete task. That worked as long as there was clear external pressure. When the work required something, I learned it. When it did not, I often stood still.

Over time, I started to feel that I did not want to stagnate or rest on what I already knew. I wanted to keep growing as a software engineer, but I kept running into the same problem: what should I actually learn?

There were many possible directions: new versions of .NET and C#, frontend, databases, cloud, another language, microservices, distributed systems, or architecture. But the more options there were, the harder it became to know which of them really mattered for me.

And even after I chose a topic, another question appeared: where should I learn it? Pluralsight has good learning paths, but it is expensive. YouTube is free, but almost endless. Newsletters, books, blogs, and recommendations from friends can be useful, but the problem remains: how do I know which source is worth following, and when does learning become only passive consumption?

I came to the conclusion that my problem is not a lack of resources. There are too many resources.

The real problem is that I need a system that helps me decide what matters to me, why I am learning it, how to recognize a good source, and how to verify that I have really understood the knowledge.

I do not want my professional growth to depend only on what my current job happens to require from me. I want to be able to direct my own learning even when no one from the outside tells me what the next step is.

This note is my attempt to describe such a system.

How I Arrived at This Model

At first, I framed the question quite narrowly:

How should I learn so that I become a better engineer, or eventually a senior or staff engineer?

That led to useful answers, but they were still strongly tied to today’s world: job posts, interviews, career ladders, specific technologies, specific resources, and current company expectations.

That is useful, but it still does not answer the more general question. If I change the goal from “senior engineer” to “staff engineer”, or to a completely different ability, I need to know how to find the right direction again. It is not enough to know the answer for one concrete case. I need a process for getting to the answer.

The breakthrough came only when I asked myself a more abstract question:

What if I landed on Mars 1000 years from now, in a completely different world, with different tools, different people, and different sources of information? How would I find out what it means to be a good engineer there?

That question removed a lot of noise.

Suddenly, it was not about YouTube, LinkedIn, Pluralsight, newsletters, today’s interviews, or today’s technologies. A deeper question remained:

In any environment, how do I recognize what it means to be good at something, how do I derive the required abilities from that, how do I learn them, and how do I verify that I am really improving?

The General Learning Loop

A general model should not depend on a specific tool, platform, or format.

The basic loop is:

Goal
-> good model
-> abilities implied by that model
-> learning resources
-> learning
-> verification
-> record of understanding
-> repetition

First, I name what I want to improve in.

Then I look for a good model of what I want to learn or who I want to become. It can be a person, a team, a project, a company, or a specific decision.

From those models, I want to derive the abilities behind them.

Only then do I look for resources that can help me gain those abilities.

Then I learn. In this phase, I mainly acquire knowledge: I read, watch, listen, go through documentation, a course, or an explanation from someone more experienced.

After that comes verification. That is where I find out whether I have only received information, or whether it is starting to become a usable ability. I need to know whether I can explain it, use it, defend it, accept criticism, and recognize the limits of my understanding.

Finally, I record my current understanding somewhere, so that it does not disappear and so I can return to it later.

The form of the record is not part of the universal model. It can be a note, article, diagram, presentation, internal document, or another durable output.

In my case, these records will be Learning Notes.

I had actually known the solution for a long time: find someone who can already do what you want to learn, and learn from them. I just had to dust off that idea and reformulate it a little. I also realized that a person cannot be truly sure they have learned something until they test their knowledge somehow.

How to Choose Resources

Resources differ depending on the question I am currently trying to answer.

One resource can help me recognize what a good solution looks like. Another can tell me what is expected from a certain role. Another can help me gain a specific ability. And another can help me verify whether I really understand it.

For example, Martin Fowler can help me understand how to think about code design, architecture, or refactoring. But by himself he will not tell me whether that knowledge corresponds to a junior, senior, or staff level in a specific company.

When I ask:

I want to be a better engineer. What does good engineering thinking mean?

useful resources might include:

Martin Fowler
Netflix engineering blog
a high-quality open-source project
an experienced colleague whose decisions I see in practice

But when I ask:

I want to be a senior engineer. What abilities are expected from me?

I need different sources:

job posts
career ladders
interview feedback
people who are already at that level

And once I know which ability I want to learn, for example distributed systems or communicating technical decisions, I look for learning resources:

books
courses
documentation
a colleague or mentor
a real project

That is why I do not want to ask only:

Is this a good resource?

A better question is:

Which question does this resource answer for me?

Some resources show a good model. Some describe role expectations. Some teach me something. And some help me verify whether I have really understood the knowledge.

Example: I Want to Be a Better Engineer

When I say:

I want to be a better engineer.

the first step is not to immediately find a course.

First I ask:

Who or what represents good engineering thinking well?

I can look, for example, at Martin Fowler, the Netflix engineering blog, a high-quality open-source project, or an experienced colleague.

Then I ask:

What do these people or systems do well?

From that, I can derive abilities such as:

maintainability
system design
distributed systems
observability
trade-off thinking

Then I choose one ability that matters to me.

For example:

distributed systems

Only then do I look for learning resources: a course, book, documentation, colleague, or small project where I can try it.

Learning can mean going through a course, reading documentation, or having someone explain the topic to me.

Verification can look like this:

I explain retry and idempotency in my own words
I build a small proof of concept
I ask someone more experienced to critique my design

And I write down the result as the current state of my understanding.

Example: I Want to Be a Better Senior Software Engineer

When I say:

I want to be a better senior software engineer.

I first need to find out what the senior level actually means.

Here, the useful sources are different from general “good engineering” sources. It makes sense to look at job posts, career ladders, interview feedback, or senior colleagues.

From that, I can derive abilities such as:

system design
end-to-end ownership
communicating trade-offs
production responsibility
mentoring

Then I choose one specific ability.

For example:

communicating technical decisions

Learning resources can include technical proposals, RFCs, architecture decision records, feedback from someone more experienced, or my own proposal in a real project.

Learning can mean going through good examples of technical proposals, reading an explanation of how RFCs are written, or having someone more experienced show me how they think about a decision.

Verification can look like this:

I write my own technical proposal
I present it to someone more experienced
I update the proposal based on criticism

That way, I am not learning only information. I am training an ability that matches the target level.

Learning

Learning is the phase in which I acquire knowledge.

It can be a course, book, article, documentation, video, conversation with a colleague, or studying an existing project.

In this phase, I try to understand new terms, find connections, and create my first mental model.

That matters, but it is not enough by itself.

When I finish a course, it does not automatically mean that I can use the topic. It means that I received input material.

When I read an article, it does not automatically mean that I gained an ability. It means that I became familiar with someone else’s explanation.

Learning is therefore input.

Verification shows what actually stayed with me.

Verification

Verification is the phase in which I test whether information has become usable knowledge.

This is where the truly active part of learning begins. I am not only receiving content. I am doing something with it.

For me, verification can mean:

I explain the topic in my own words
I create my own example
I use the knowledge in a small experiment
I compare my understanding with feedback

I want to distinguish between these levels of knowledge:

I have heard of it.
I can explain it.
I can use it.
I can defend the trade-off.
I can recognize when it does not fit.

This helps me avoid confusing familiarity with real understanding.

For example, with distributed systems, it is not enough to know that retry, idempotency, or eventual consistency exist.

A better verification is:

I can explain why retry can create a duplicate operation
I can design a simple idempotency mechanism
I can say what limits such a solution has
I can accept criticism from someone more experienced

If I cannot explain a topic simply, I probably do not understand it well enough yet.

If I cannot use it in an example, maybe I only know the definition.

If I cannot answer follow-up questions, my understanding is probably fragile.

The goal is not to look smart. The goal is to expose my understanding to reality.

Record of Understanding

After verification, I want to record the knowledge.

In general, the record can have any durable form. In my case, it will be Learning Notes.

For me, a Learning Note is not only an excerpt from a source. It is a record of:

what I was learning
why I was learning it
how I understand it in my own words
how I verified it
what is still unclear to me

That turns the note from an archive of information into an audit of my own understanding.

Some notes can be raw. Some can become cleaner engineering notes or articles over time. But their first purpose is to help me think, verify knowledge, and return to what I have learned.

Repetition and Calibration

The loop does not end when I write something down.

After some time, I need to ask again:

Is my goal still the same?
Are my models still relevant?
Has what the industry expects changed?
Which ability is now my most important gap?

That does not mean I have to regularly go through all old notes.

Most notes can remain a snapshot of how I understood a topic at a given time.

It makes sense to return to them mainly when:

I want to use the topic
I want to explain it to someone
I received new feedback
I found out that my model was wrong

The important thing is not to maintain a perfect archive.

The important thing is to maintain the current direction.

Current Summary

My current understanding is:

Learning should not start with a course, tool, or random resource. It should start with a goal.

If I want to improve at something, I first need to find a good model of what I want to learn or who I want to become.

From that model, I derive abilities.

Only then do I look for resources that can help me gain those abilities.

Then I learn. That means I acquire information, terms, connections, and a first mental model.

Then I verify. That means I test whether I can explain the knowledge, use it, defend it, accept criticism, and recognize its limits.

Then I record the result, so that I know what I understood, how I verified it, and what I am still missing.

The final loop is:

Goal
-> good model
-> abilities implied by that model
-> learning resources
-> learning
-> verification
-> record of understanding
-> repetition

In my specific case, “record of understanding” will mean Learning Notes.

Tools, resources, and technologies can change. The loop should remain.