Learning Technical Subjects: Why Following Along Is Not Learning

Technical subjects have a particular trap: following a tutorial feels exactly like learning, and produces almost none of it.

You type what the instructor typed, it works, and you conclude you understood. The gap only appears when you try to do something slightly different — often weeks later.

The difference between following and building

• Following tests whether you can copy. It requires attention, not understanding.
• Building requires deciding what to do next, which is the actual skill.
• The moment you make a decision the tutorial did not make, you are learning.
• Change something deliberately in every tutorial you follow — a different input, an extra requirement, a removed piece. The point at which it breaks is the point you did not understand.

Build the mental model, not the recipe

• Ask why each step exists, not just what it does. Steps you cannot justify are steps you will misapply.
• Predict before running — say what you expect to happen, then check. Being wrong is the most valuable event available.
• Find out what the underlying thing is doing rather than memorising the interface. Interfaces change; the model does not.
• Learn one layer down when you are ready — knowing what sits underneath makes the layer above make sense.

Debugging is the skill, not the obstacle

Most people treat errors as interruptions. In technical work, handling them is the job:

• Read the error message properly. Most of them say what is wrong; most people skim past.
• Change one thing at a time so you know what fixed it.
• Narrow the problem — find the smallest case that still fails.
• Check your assumptions rather than the complicated parts first. The problem is usually somewhere you were certain.
• Explain the problem out loud as if to someone else. A large share of problems resolve during the explanation.
• Take a break when stuck. This is not procrastination — it is one of the most reliable debugging techniques there is.

Keep a mistake log

The single most useful document you will maintain:

• Record each problem that cost you real time and what fixed it.
• Include the error you saw, so you can search for it later.
• Note what you assumed that turned out to be wrong — this is the part that generalises.
• You will consult this far more than your lesson notes.
• Patterns emerge after a few months, and they show you what you have not yet understood properly.

Getting unstuck

• Set a time limit before asking — long enough to try properly, short enough not to lose a day.
• Search the exact error text first.
• Read the documentation, which is usually more reliable than the tutorial that got you here.
• When you ask, include what you tried, what you expected, and what happened. Questions in this form get answered; vague ones do not.
• Produce a minimal example — this often solves the problem before you send it.
• Do not paste large blocks with no explanation and expect help.

Using AI assistance without hollowing out the learning

Worth addressing directly, because it is the biggest change in how technical subjects are learned:

• It is very good at unblocking you and very good at preventing you from learning, depending on how you use it.
• Attempt first, then ask. The struggle before the answer is where the learning is.
• Ask it to explain rather than to produce — why this approach, what this line does, what I misunderstood.
• Never use output you cannot explain. If you cannot say why it works, you have not learned anything and you cannot maintain it.
• Verify everything — confident wrong answers are common, and they are hardest to spot in exactly the areas where you are least experienced.
• Be careful with sensitive or proprietary material — check what you are permitted to share.

Practice that builds capability

• Build something you actually want — motivation carries you through the difficult middle in a way exercises do not.
• Start smaller than you think. A finished small project teaches more than an abandoned large one.
• Rebuild something from scratch after following a tutorial, without looking.
• Read other people's work — a heavily undervalued way to learn.
• Return to old work after a few months. Being able to see what is wrong with it is direct evidence of progress.

Managing the frustration

• Being stuck is the normal state, not a sign you are unsuited to this. Experienced people are stuck constantly; they are just used to it.
• Progress is uneven — long plateaus then sudden jumps.
• Comparing yourself to people further along is not informative; you are seeing their finished work, not their process.
• Stop for the day when frustration is making you worse. It usually is by the second hour.
• Keep evidence of what you have built — on bad days it is the only accurate measure available.

One thing worth remembering

In technical subjects, the reliable test is not whether you followed the explanation.

It is whether you can close everything and build a slightly different version. Everything above is a way of reaching that point sooner.

FAQ