Teach It Before You Learn It

Most of us learn in the same order. You read the docs, you try it, you get decent, and someday, if you stick with it, you teach it to somebody else. Teaching is the victory lap. You earn it by knowing the thing first.

That order is backwards.

A faster way to learn something new is to decide who you are going to teach before you know anything about it. Name the student first. Then open the docs. Researchers call this the protégé effect. People who do this remember more of what they read, in better order, and they get that gain before they teach a single person. Teaching for real within the week is what makes it last.

This used to be a nice study tip. In a year when a specific skill can expire in months, it is closer to a survival skill, and the best student you could ask for is already open on your desk.

Why We Learn It Before We Teach It

Look at how we build learning. Courses run intake first and the project at the end. Onboarding hands a new engineer a reading list and a calendar of shadowing before anyone asks them to explain anything. Certifications test you once you have studied. Every one of them assumes you fill up first and pour out later.

AI added a second argument on top of the first. If the model already knows the answer, why learn at all? Ask it, ship the result, move on. The other camp says the opposite: do not let the model do your thinking, learn it the hard way, earn it.

I am firmly in the first camp for most things. I ask the model for the regex, the flag, the date format, the config I will touch once a year. Learning those by heart would be a waste of a good afternoon.

Both camps miss the same thing. For the material you have to own, meaning anything where you will later judge someone else’s answer, what matters is the order you learn it in, and the default order is the slow one.

The Protégé Effect: Expecting to Teach Changes How You Read

The protégé effect comes down to this: people learn more when they are learning for someone else. One of the cleanest tests of it came in 2014, from John Nestojko, Dung Bui, Nate Kornell, and Elizabeth Bjork. Two groups read the same passage. One group was told they would be tested on it. The other was told they would have to teach it to someone. Then both groups took the same test, and nobody in either group ever taught.

The people expecting to teach remembered more. They also remembered it organized. Their recall clustered around the main points instead of scattered details. The only thing that changed was what they believed was coming, and that belief changed how they read.

Watch yourself read something when nobody is coming. You highlight and nod along, recognizing each sentence as it goes by, and recognition feels like knowing. Then someone asks a simple question and you have nothing.

Reading for a student is a different activity. The whole time, part of your head is asking what you would say first and which example would make it click. The part you could not explain jumps out while the page is still in front of you and you can still fix it. You are building the explanation as you go, and building it is the learning.

A year earlier, Logan Fiorella and Richard Mayer found the second half. Students who prepared to teach did better on a test right away. Students who then actually taught, explaining the material to a camera, were the ones who still had it a week later. Expecting to teach gets you started, and teaching for real is what makes it stay.

Seneca put it in a letter to his friend Lucilius almost two thousand years ago: “Men learn while they teach.”

One detail matters for how you use this. In that 2014 study, the gain came from what people expected while their eyes were on the page. Telling yourself afterward that you now have to teach it cannot go back and change how you read, so name the student before you start.

Skills Expire in Months Now. Learning Speed Does Not.

I go fast with models. They write most of the code on my desk now, and that is the right call. What the model cannot do for me is know enough to tell when it is wrong. Someone has to say what done looks like, read the diff, and notice that the retry logic will hammer an API that rate-limits at ten requests a second. When my name is on the approval, that someone is me. “The model wrote it” will not explain a bug I signed off on, so I have to understand the thing.

The thing keeps changing. A new agent framework, a new way of wiring tools, a new API, a pattern that was best practice in the spring and dead by the fall. Being a beginner used to happen once or twice in a career, and now it happens every quarter.

The people who stay at the front edge have a faster way of being a beginner, and that counts for more than how much they already know. I wrote about learning velocity as the compound advantage a while ago. This is the method under it.

The Feynman Technique Gets Better When the Student Talks Back

The Feynman technique, as people usually teach it, goes like this. Pick a topic. Explain it in plain words to someone who does not know it. Find the spots where you wave your hands. Go back to the source and fix them. Repeat until the explanation is simple.

It works. Its weak point is the student. Most people run it with an imaginary student, and imaginary students are polite. They never interrupt, and they never ask the obvious question you were hoping to skip.

In 2009, a Stanford group found that students worked harder to learn science when they had to teach it to a computer character than when they learned it for themselves. That study is where the name protégé effect comes from. It was software that could barely hold a conversation. The student on your desk today can.

Before I open the docs for something new, I tell Claude I am going to explain the topic to it in an hour. Then I read with that hour in mind. When I come back, I tell it to play a sharp new engineer who has never heard of the thing. Stop me every time I hand-wave. Ask the dumb question first. Push back if an example does not hold up. When I finish, list everything I got wrong or skipped.

My first explanation is always worse than I expected, and that is the reason to do it. Every gap it finds is a gap I would have carried into a design review or a pull request. Ten minutes with a student that talks back finds them while they are still cheap.

The model answers my questions all day. For the few things I have to own, I flip the roles and let it ask the questions.

How to Learn Faster by Teaching

1. Name the student and the date before you open anything. A person, the team, or the model. Write it down. “Thursday I walk the team through how the new deploy pipeline handles rollbacks.” The sentence changes how you read the first page.

2. Read for the explanation instead of the coverage. While you read, look for what you would say first, the one example that carries it, and the place your student will get confused. This is the same move as reading with a job in mind, pointed at learning instead of building.

3. Teach the model, then let it grade you. Run it as a beginner first and a skeptic second. The beginner exposes holes in how you explain it, and the skeptic exposes holes in what you understand. End every session by asking for the list of what you got wrong, then go back to the source for each one.

4. Then teach a human inside the week. The model gets you through day one. A ten-minute walkthrough at standup or a Slack post with a diagram is the half that still holds next week. Real people ask questions the model did not think of, and having said it out loud to a colleague makes it stick.

5. Leaders, assign the teach-back with the learning. “Go learn the new framework” usually gets you someone who skimmed the docs, and “Friday you walk us through the new framework” gets you someone who read them hunting for the explanation. The difference costs you one sentence. It is the teacher-side companion to leaving room for people to figure things out.

When to Ask and When to Teach

Run every question through a teach-back and you will never ship anything, so I sort with one question. Will I have to judge someone else’s answer to this later? If the answer is no, ask the model and move on. If the answer is yes, because I will review it, defend it in front of a team, lead people who build on it, or decide whether to bet on it, then I learn it, and I learn it by teaching it.

Over time the habit runs without the checklist. You start something new and you are already sketching the explanation in your head, already picturing who will be confused and where. At that point you are always reading as if somebody is coming, because somebody usually is.

Final Thoughts

We learn in the order we were taught to learn, and that order puts the most powerful part at the end, where most people never get to it. Moving the student to the front costs one sentence and ten minutes of hearing where you are wrong, and it changes how every page reads. The explanation is where you find out whether you know the thing or only recognize it.

The student can be your team, a new hire, or the model on your desk, which is the most patient student ever built and will point at every gap you skipped. Use it. The next thing you have to learn, name the student before you read the first page.

If you want a room full of builders who learn new things in public and teach each other as they go, MasteryLab is where that happens.

FAQ

What is the protégé effect?

The protégé effect is the finding that people learn material better when they learn it in order to teach someone else. Stanford researchers named it in 2009 after students worked harder to learn science for a computer character they had to teach than they did to learn it for themselves. Related studies found that simply expecting to teach changes how people read: they remember more, and they remember it organized around the main points.

Does expecting to teach really help you learn faster?

Yes. In a 2014 study, people told they would teach a passage recalled more of it, and recalled it better organized, than people told they would be tested, even though nobody actually taught. A 2013 study added the second half: expecting to teach helped right away, and actually teaching is what held up a week later. Name the student before you start, then follow through and teach within a few days.

How do you use the Feynman technique with AI?

Study with the expectation of explaining it. Then tell the model to play a sharp beginner who has never heard of the topic, stop you every time you hand-wave, and ask the obvious question first. When you finish, ask it to list what you got wrong or skipped. Go back to the source for those gaps. The model is a better student than an imaginary one because it talks back.

Should you learn something yourself if AI can just answer it?

For most questions, let the model answer and move on. For anything you will have to review, defend, lead, or decide, learn it yourself, because you will be judging someone else’s answer to it, including the model’s. A simple sort: if you will need to tell a right answer from a wrong one later, teach it back before you rely on it.