Split View: 배우는 방법을 배우기 — 기초와 유행을 가르는 기준, 깊게 팔 하나를 고르는 법

Learning How to Learn — Telling Fundamentals From Fashion, and Choosing One Thing to Go Deep On

• Start From the Fact That You Cannot Learn It All
• The One Question That Separates Fundamentals From Fashion
• This Is Not an Argument for Ignoring Fashion
• Three Criteria for the One Thing
• Reading Is Not Learning
• Leave Learning Behind as Evidence
• Try It This Week
• Further Reading
• Sources

Start From the Fact That You Cannot Learn It All

The candidate list always exceeds the available time. So when a learning strategy arrives as a list of things to learn, it has already failed. Lists have no ceiling; weeks do.

What is needed is the other side: a criterion for what not to learn. Same structure as the non-goals in part 6, and it works for the same reason. Once the not-doing is decided, time actually reaches what is left.

The One Question That Separates Fundamentals From Fashion

The word "fundamentals" gets mixed up with hard, academic, and old. All three are inaccurate as criteria. There is one usable question: if this disappeared, would the understanding standing on top of it collapse too?

Understand congestion control and a cluster of things get explained together: why timeout values are set where they are, why retries can make a situation worse, why a queue suddenly grows. Memorize one framework's routing rules and you use them inside that framework. The first is a load-bearing layer; the second is a leaf.

A corollary falls out. Where a tool is the point, learn the idea the tool implements. Learn an orchestrator by way of the control loop that keeps reconciling desired state with current state rather than by way of command names, and the concept survives in other products and survives the renaming. Tools are variables; ideas are axes.

This Is Not an Argument for Ignoring Fashion

People who only dig into fundamentals go stale in the other direction. Not knowing what is changing means not knowing where your fundamentals get used.

Two layers works better. The broad, shallow layer holds names, purposes, and rough position. The goal is being able to recall it when needed, and stopping there is fine. The deep layer holds one thing at a time.

The shallow layer costs less than people expect — an hour a week maintains it. The trouble starts when it gets mistaken for the deep layer. The distance between knowing a name and being able to judge whether something is right is enormous, and in a meeting that distance is nearly invisible.

Three Criteria for the One Thing

First, do you touch it often? Count how many times a month your work reaches it. Frequent contact returns faster, and fast return keeps the learning from stalling.

Second, does everyone avoid it? Every team has an area people quietly route around. Usually it is avoided for being messy rather than for being hard. Messy areas have little competition, and once one person understands it, the organization calls that person.

Third, can you get all the way down? You need to be able to see the implementation, run experiments by hand, and check whether you are wrong. Where there is no way to check, what accumulates is not depth but opinion.

The third connects back to this series. Depth is more accurately measured as the range over which you can judge for yourself than as the quantity you know. If you can judge, you can review someone else's result too — and that is the expensive side from part 1.

Reading Is Not Learning

The most common waste is trying to learn by reading. Reading produces familiarity, and familiarity feels remarkably like understanding. The two only separate under test.

Psychology has a long-standing observation that touches this, called the testing effect or retrieval practice: devoting part of the learning period to retrieving information from memory increases long-term memory, and it produces less forgetting than studying and restudying. Spacing the repetitions has been observed to increase the effect further.

The transfer gives one rule. After reading, you have to close it and pull. Close the document and write down what you just read on a blank page, or explain it to someone, or write a prediction and run it to see whether you were right. Reading without that step leaves only familiarity.

Example — five lines written with the document closed

what it does:        in one sentence
what it does not do: what this tool or concept does not cover
why it is shaped this way: your best guess at the reason
when not to use it:  one situation where it does not fit
what you still do not know: what you have to reopen and check

Write the five lines, then reopen the document and compare. The wrong lines are what to read next.

Attach a caveat. These observations mostly come from memory tasks under controlled conditions, and transferring them directly to the practical work of understanding an unfamiliar system has limits. What transfers is the direction, not a precise multiplier.

Leave Learning Behind as Evidence

Learning that never leaves your head goes unverified. Part 3 noted that the output of reading is understanding and understanding cannot be inspected directly; all learning has that shape.

Evidence takes one of three forms. First, something you can re-run: a small reproduction repository, an experiment script, a number you measured yourself. Months later you can go back and check. Second, a short piece of writing: a one-page summary of what you learned and what you still do not know. Third, someone else's confirmation: explain it to a person who knows and get told where you are wrong.

If you pick only one, the third is cheapest and most accurate. Fifteen minutes, and it finds the holes you could never find alone.

There is a side effect. Accumulated evidence gives you things to put on a résumé. But that is a consequence, not a purpose. Make it the purpose and you end up learning only what leaves a good artifact, and what leaves a good artifact and what is worth learning frequently differ.

Try It This Week

Pick a technical document you read recently and write the five lines above with the document closed. Ten minutes. How many of the five will not write is your answer to how much of that document you actually read. Then compare, and the wrong lines become this week's study list.

• Engineering Skill Path — the Linux, networking, database, Kubernetes, AI/LLM, and FDE tracks are built as assembling commands, predicting output, and finding bugs. Being built around pulling rather than reading is the same point this post makes.
• Problem-Solving Trainer — practice with nine named moves for when you are stuck. Its own first screen says the tool will not make you smarter, and learning tools are rarely that honest, which is worth noting.

Where this does not apply: under a deadline, most of this is a luxury. A technique you need next week is something to use shallowly and move past, not something to dig into, and at that point making the work reversible beats any amount of retrieval practice. Learning strategy is an allocation problem for when you have slack; it is not a method for handling something urgent.

Further Reading

• Related post on this blog: What to Learn Deeply, What to Skim — A Learning Strategy for the AI Era

What Stays Expensive series

• Previous: Working With AI Tools as a Skill — Where the Delegation Line Sits and How to Verify
• Next: Why Domain Knowledge Is a Defensible Line — The Engineer Who Knows the Business

Sources

• Testing effect — Wikipedia — the definition that long-term memory increases when part of the learning period is spent retrieving from memory, the statement that retrieval produces less forgetting than studying and restudying, and the note that spaced repetition increases the effect all come from here. Read 2026-08-15.
• The question that identifies load-bearing knowledge, the three criteria for choosing one thing, and the three forms of evidence are not from that source; they are what this post assembles.