The Truth About Learning: Why Some Things Never Stick After Three Attempts

The Truth About Learning: Why Some Things Never Stick After Three Attempts

I've learned Python three times.

Not an exaggeration—literally three times. From basic syntax to data types, from loops to functions, I've gone through tutorials again and again, filling notebooks upon notebooks. Yet every time I want to actually build something, my mind goes blank. I have no idea where to start.

But English? That's a different story. I never deliberately memorized vocabulary lists or systematically studied grammar. I just read English articles and watched English videos daily. Now I can read books in English fairly fluently.

This puzzled me for a long time. Why such a stark difference in outcomes with similar effort?

Eventually, I figured it out—I didn't fail to learn programming; I simply never knew what programming actually looks like in the real world.

The "Black Veil" and the "White Veil"

I've come to think of this phenomenon in terms of two kinds of veils.

English is a "white veil" to me. Though there's still a layer between me and mastery, I can see through it—how articles are written, how conversations flow, how speeches are structured. Not only can I see through this veil, I can grab hold of it anytime, because the use cases are everywhere. Want to read? Read. Want to write? Write. Want to speak? Speak.

Programming is a "black veil." Those syntax rules, functions, and loops I learned—they're just the veil itself. I know its texture and pattern, but I can't see what's behind it. How are real projects actually built? How do programmers debug when they hit errors? How does code come together piece by piece? I couldn't see any of this because tutorials only taught me "what this is," never "what this does."

Later, I discussed this with Claude (an AI tool), and it told me this was completely normal—even senior programmers Google things and ask AI for help. That's when it hit me—I always thought I needed to reach a level where I could code without looking anything up, but even professional programmers don't work that way.

In other words, I didn't even know what was inside the "mystery box," just kept fumbling around outside it.

The "Activation Energy" of Learning

Why do some things become usable skills while others remain dormant knowledge, even with equal time investment?

I realized it's like activation energy in chemistry. Knowledge needs to cross an energy barrier to go from "knowing" to "using."

English has low activation energy. Whenever I want to use it, I can—read an article, write something, chat with someone. The contexts are everywhere, feedback is immediate. If you make a grammar mistake, you notice right away. When you understand a passage, you feel it instantly.

Programming has high activation energy. Want to write code? First, set up your environment. Want to build a project? First, understand the architecture. Hit a problem? Don't know how to debug. Every step has invisible barriers, and tutorials never mention them because they assume you're already in a "real context"—but you're not.

All "useless knowledge" is essentially knowledge with activation energy too high to overcome.

My medical anatomy studies were the same. Memorizing anatomical structures from textbooks had impossibly high activation energy because you had no idea what they were for. But in the operating room, the activation energy dropped to zero—the context forced you to use them. You couldn't make a single incision without recalling your anatomy knowledge. That's when you realized how it all actually worked.

What Reading Changed

I should probably go back to my university days.

Before that, I was an obedient student. Whatever the teacher said, I believed. Whatever the textbook stated, I memorized. It never occurred to me to verify things myself. Not because I was lazy—I simply didn't have the concept of "active exploration."

The change came from developing a reading habit.

In high school, I read some required classics, but honestly, I found little joy in them. Later I sporadically read some popular science books out of interest, but they were expensive and my time was limited, so I never went deep. It wasn't until university, seeing that massive library, that I truly started exploring freely.

I loved wandering between bookshelves, hunting for interesting books. Every time I discovered a good one, I'd feel this inexplicable excitement. I still remember reading Nassim Taleb's Fooled by Randomness for the first time—his ideas captivated me so much that I hunted down all his other books. That feeling was like suddenly opening a door to a completely different world.

What reading taught me wasn't knowledge itself, but the ability to "actively explore." I stopped waiting for others to tell me what to learn and started following my curiosity to find answers.

With reading came the desire to share. Wanting to share meant I had to write. And writing pushed me to think more deeply and read more broadly. This cycle made me realize—reading, writing, and thinking form the core of self-learning ability.

With this core, learning other things became much easier. Want to learn English? Just switch your reading materials to English. No need to deliberately memorize vocabulary—you'll remember words naturally by encountering them repeatedly. Want to learn programming? Same principle—read code, write code, think about code logic.

But here's the thing—some feedback loops are short; others are long.

English has a short feedback loop: Read an article, immediately know if you understand; write a passage, immediately see if it's correct; say something, immediately get a response. This instant feedback makes learning feel rewarding.

Programming has a long feedback loop: Write some code, don't know if it works (because you might not have a runtime environment); want to build a project, don't know where to start (because you don't understand project architecture); hit a bug, don't know how to debug (because you lack experience). This delayed feedback makes it easy to give up.

All efficient learning shortens the feedback loop. That's why internships beat reading books, building projects beats doing exercises, and writing beats passive reading—because feedback is immediate, real, and unavoidable.

Mystery Boxes Are Normal; The Key Is How to Open Them

I now realize that almost every new field starts as a "mystery box." Some boxes are just easier to open than others.

English is a semi-transparent box—you can vaguely see what's inside; use cases are everywhere. Programming is a black box—you have no idea what's in it; real workflows are hidden inside. Medicine is a nesting-doll box—open one, find another; the learning never ends.

The difficulty of learning isn't in "learning" itself, but in "finding how to open the box."

And traditional education's biggest problem is—it pretends the box doesn't exist. Teachers tell you programming is important (there's treasure in the box), teach you syntax and functions (describe what the box looks like), but never show you what actual programming work looks like (how to open the box).

So you see this absurd phenomenon:

• We study math for over a decade but don't know how mathematicians work
• We learn lots of programming syntax but don't know how programmers build projects
• We accumulate vast medical knowledge but don't know how doctors diagnose patients

Knowledge can only be activated in "visible use contexts."

That's why:

• Interns grow fastest—they watch senior staff open the boxes
• Open-source contributors improve rapidly—they see how experts write code
• Apprenticeship never goes out of style—masters show you how to open boxes hands-on

There's only one way to open mystery boxes: enter real contexts and observe how others do it.

Error Tolerance Determines Exploration Radius

This reminds me of another experience.

I used to be terrified of ranking last in exams—felt like such a humiliation. But after failing a few courses in university, I somehow adapted to that state. I'm not advocating for failing courses, but the retake mechanism gave me room for error—failure wasn't so scary after all, you could always retake and try again.

This error tolerance gave me the courage to try. I started daring to take courses that sounded difficult but interesting, daring to attempt things that might fail. I discovered that a person's exploration radius depends on how much room they have for trial and error.

The core reason we don't dare try new things is fear of risk. When society and family don't construct spaces for error tolerance, we can only huddle in our familiar comfort zones, afraid to step out, ultimately seeing only the most insignificant corner of this rich world.

But more insidiously, insufficient error tolerance leads to "invisible self-censorship."

You've probably already abandoned many things you wanted to try in your subconscious—not because of external prohibition, but because you predicted "the cost of failure is too high." This self-censorship is silent, automatic, so much so that you don't even realize you're limiting yourself.

For example:

• Why not dare to intern at a company? Afraid of looking bad if you mess up
• Why not dare to publish code on GitHub? Afraid of being ridiculed
• Why not dare to submit PRs to open-source projects? Afraid of rejection

These are all forms of "psychological activation energy"—even if you have the capability, the psychological barrier is too high for you to take the first step.

A truly innovation-friendly environment should lower this psychological activation energy. Tell you: It's okay to fail, there's always another chance; it's okay not to do well, at least you tried; it's okay to be rejected, try again next time.

Perhaps the purpose of schools should be to provide students with this kind of space for exploration and trial-and-error, with teachers playing a guiding role. But due to various factors we can't fully understand, teachers often exercise too much control, while students fear stepping out, leaving schools with nothing but walls protecting students' physical bodies. This isn't what we hope to see, but it's probably the reality many have experienced.

The Essence of Learning: Not "Learning" but "Using"

After this long journey, I've found that the truth about learning is actually quite simple—learning isn't fundamentally about "knowing"; it's about "being able to use."

All "useless knowledge" falls into one of these categories: either you don't know what it's for (use context invisible), or its activation threshold is too high (activation energy too large), or you simply have no opportunity to try using it (insufficient error tolerance).

Back to my programming struggle. Now I understand—I don't need to go through another tutorial. What I need is:

• To see how real projects are actually built (lower cognitive activation energy)
• To browse code repositories on GitHub (watch how others open the box)
• To intern at a company and observe programmers' workflows (enter real contexts)
• Or just build a terrible project and learn from mistakes (shorten the feedback loop)

Learning isn't linear knowledge accumulation; it's building cognitive frameworks through use. Only when you know how a skill operates in the real world can you truly master it.

This principle applies to all domains.

Finally, I want to ask myself a question: Do I really need to "learn programming"?

Sounds absurd, but think about it:

• If my goal is to "solve problems with technology," maybe I don't need to "write code" but rather "learn to use AI tools to direct code"
• If my goal is to "understand technical thinking," maybe I don't need to "write code" but rather "understand code logic"
• If my goal is to "become a programmer," then yes, I need to write lots of code, but only after entering real projects

Maybe my struggle isn't "can't learn programming" but "don't know why I'm learning programming."

Why did English work? Because I had clear use contexts—reading, sharing, thinking. Why didn't programming work? Probably because I hadn't found what truly drives me to write code.

The motivation for learning isn't "I should learn this" but "I can't do what I want without learning this."

When you encounter a problem and realize you can't solve it without writing code, you'll find—learning programming suddenly becomes easy. Not because programming got simpler, but because the activation energy disappeared. You skip the "learning" phase and jump directly into the "using" phase.

So, the truth about learning isn't "pick up and put down," but rather "find a reason to use it, and you'll never put it down again."

If you also have something you've tried to learn for ages but never mastered, ask yourself:

• Can I see how it's actually used in the real world?
• Do I have a way to shorten the feedback loop?
• Do I have enough error tolerance to experiment?
• Do I really know why I'm learning this?

Figuring these out might be more useful than going through another tutorial.

After all, learning was never the goal. Being able to use it is.