Skip to main content

TECH VEDA

Linux kernel & Device drivers starts on 31st Oct 2026 enrollingCorporate on-site training - Submit proposal Pick your modulesSharpen your kernel skills: deep dives, drivers, Yocto, CVEs, careers — updated daily. Read the blog →
Career

Why Learning Should Be a Process, Not an End Goal

A goal you finish ends on a date. A skill you keep needs a plan that continues. Here is how to write a learning goal as a repeating loop.

Why Learning Should Be a Process, Not an End Goal

A goal you finish ends on a date. A skill you keep needs a plan that continues.

Many learning goals are written as things to finish: a course, a certificate, a list of topics. Such a goal can be completed without a lasting change in what you can do, and it loses its meaning when the tools change. A better plan is a repeating loop with a regular practice, a check on a new problem, and a dated revisit. This post shows how to write one.

Why finishing the course does not finish the learning

Here is an illustrative example. A student writes a goal: “Learn Yocto by December.” In December the student has finished the course and received the certificate. The goal is complete. A month later the student opens a new project and cannot start without the course videos open. Or a new release arrives, and part of the notes no longer applies.

Nothing went wrong with the goal. It did what it said. But it measured the wrong thing.

What an end-point goal measures, and what it leaves out

A goal worded as an end point measures completion: modules finished, hours watched, a certificate received. These show what you did. They do not show what you can do now, and they do not show how that changes over time.

The useful measure is different. It asks what you can do on a problem you have not seen, and how quickly you can work again after a break or after a change in the tools. This post on four levels of knowing explains why familiarity with a topic is easy to mistake for the ability to use it.

A completed goal tells you what you finished. It does not tell you what you can still do next month.

Write the goal as a loop

I suggest a loop with three parts.

  • A regular practice. A fixed pattern of work, such as two evenings a week on one small exercise.
  • A check on a new problem, without notes. The reasons this check works are in this post on why understanding does not become the ability to apply. If you use an AI assistant, the same check applies once the assistant is switched off, as this post on learning with AI describes.
  • A dated revisit. A date in your calendar when you repeat an earlier task and ask two questions: what did I forget, and what has changed?

Here is the same goal in loop form, as an illustration: “Each week, make one small change to a Yocto image without notes. On the first Sunday of each month, repeat last month’s change on the newest release, and write down what broke.”

The second version cannot be completed. It can only be kept up, and it tells you each month what you can still do.

Why this matters when tools keep changing

Tools, versions and methods change. What to learn, so that your knowledge survives those changes, is covered in this post on tool knowledge and fundamentals. This post is about how to organise the learning itself.

When the target moves, a single result tells you little. How quickly you can work again after a change tells you more. There is some support for this way of setting goals. In one experiment, students ran a business simulation in which earlier strategies stopped working partway through. Those told to find strategies did better than those told to reach a target. The students were a small sample, the task was a simulation, and it ran in one session, so treat it as a hint and not a rule.

When the target moves, the useful measure is how quickly you can work again.

Goals still have a place

This is not an argument against goals. A fixed end date for a stretch of study is useful, because it makes you look at results. This post on postponing practice recommends one for that reason. The difference is what the end date is for. It is a checkpoint where you look at what you can do. It is not the end of the skill.

Nor does a process mean endless study. The loop above is small and regular. If it grows until you stop doing it, make it smaller.

Set an end date for each stretch of study. Do not set an end date for the skill.

Mistakes that turn a process back into an end point

  • Counting modules or hours as progress. These measure effort and completion, not ability.
  • Doing the check with notes open. The check then shows only that you can read.
  • Setting a revisit date with no question. A revisit should ask what you forgot and what changed.
  • Making the loop too large. A plan you stop after three weeks is an end point of its own.

Try this week

Take one learning goal you have now. Rewrite it with three blanks filled in: what I will practise and how often; what I will do without notes on a new problem; and the date when I will repeat an earlier task and note what changed. Put the date in your calendar today.

A good learning goal still makes sense after the tool is updated.

The repeated problems in a TECH VEDA session are one example of the check described above. The sessions are live and led by a mentor, with attendance enforced. Between sessions and after them, you set the practice and the revisit dates yourself.

— Raghu Bharadwaj

Was this worth your time?
RB
Raghu Bharadwaj

Founder, TECH VEDA — 20+ years teaching the Linux kernel, device drivers and embedded systems.

Follow on LinkedIn

Get new posts by email

Kernel, embedded Linux and AI-era engineering — a few sharp reads a month. No spam.

We email occasionally and never share your address.