How to Learn Anything Faster: Build Before You Feel Ready

<!-- SEO title: How to Learn Anything Faster: Build Before You Feel Ready Meta description: The fastest learning loop I have found is simple: build a sandbox, practice the real thing, get feedback, retrieve what you know, and repeat before you feel ready. Target keyword: how to learn anything faster Status: Draft for Graham review. The exact article is not live. It links to the earlier just-in-time learning and AI-era skills posts, while focusing on the newer sandbox, retrieval, feedback, and AI-assisted practice loop. -->

I used to think the way to learn anything faster was to consume enough information first: watch the course, read the book, take notes, highlight the important parts, and save a few threads for later.

Then, at some undefined point, you would know the thing.

That approach helps. Consuming gives you language, examples, and a rough sense of how a subject works.

It just has not been the fastest way for me to learn.

I wrote about just-in-time learning: learn something when you have a real use for it instead of storing information you may never apply. I still agree with that. What I did not have was a clear practice loop for using it. This is the version I use now: build a sandbox, try the real work, retrieve what you know, get feedback, and drill whatever keeps breaking.

The times I've learned fastest were the times I forced myself to do the thing before I felt fully ready. I would build something real, get stuck, figure out how to get unstuck, and move to the next problem. Each project showed me what I needed to learn next.

I noticed this most clearly when I started learning to build software with AI.

I studied engineering, but I spent my career in product and growth. I had not written production code. The normal path would have been to take a programming course, learn Python fundamentals, work through tutorials, then maybe build something small once I felt ready.

Instead, I took Nat Eliason's Bring Your Own Apps course and started building immediately. First it was the course test projects. Then it was a product and user-feedback analysis tool. SEOTakeoff came next and became a real product with paying customers. After that I used NHL stats, AI agents, and workflow tools as new sandboxes. My vibe-coding workflow kept changing as the tools improved.

I was underqualified for every step, which was the point.

The gap between what I knew and what the project needed showed me what to learn next.

School trains the wrong instinct

Traditional school has a lot of good parts, but it can teach a bad default for self-directed learning: wait for someone else to give you the syllabus, lecture, reading list, and assignment before moving to the next chapter.

That works fine when the path is stable.

It breaks down when the thing you want to learn is changing quickly, or when the only real test is whether you can do it in the real world.

Vibe coding is a good example. There was no perfect curriculum, and the tools changed every few weeks. The best people to learn from were often not teachers. They were people posting what they were building, what broke, what prompts worked, what tools were suddenly good, and what had stopped working since last month.

I stopped treating learning like a content problem and started treating it like a practice problem.

Nat Eliason has a useful frame for this called the sandbox method. Build a low-stakes environment where you can practice the real thing without pretending the practice is the final outcome.

For coding, that was GitHub and side projects. For writing, it can be a blog. A marketer can use a small site to test positioning, keywords, pages, and offers; a designer can use a Figma file and public portfolio.

The important part is that the sandbox is real enough to create feedback.

Reading about coding gives you information. Shipping a broken app gives you information you can actually use.

The same thing happened with the building project. I did some necessary learning first because the stakes were physical rather than digital. I had to understand enough to plan safely and avoid obvious mistakes.

But the real learning started when I forced myself to build a small building.

The plan met the materials. The measurements had to work in the real world. The things I had only understood in theory became obvious because I had to make decisions, fix mistakes, and keep going.

Then the next build was better. The stakes got a little higher. The decisions got cleaner. I was still learning as I went, but I was no longer learning in the abstract.

The fastest loop I know

The learning loop that has worked best for me is simple:

1. Get the basics.
2. Build something real.
3. Get stuck.
4. Try to explain the problem before looking it up.
5. Get feedback.
6. Fix the weak spot.
7. Repeat at a slightly higher level.

That is basically the overlap between Nat's sandbox method, Scott Young's Ultralearning, and the research-backed learning ideas from Make It Stick: retrieval practice, spacing, interleaving, and feedback.

The research matters because it pushes against what feels comfortable.

Rereading, highlighting, and watching one more video all feel productive. But retrieval practice, spaced learning, and interleaving tend to be better for long-term retention than simply reviewing material. They also feel harder while you're doing them.

Trying to explain an idea from memory exposes the holes. Spacing practice out means you have to reconstruct the idea after it starts fading. Interleaving forces you to tell similar problems apart instead of cruising through one familiar pattern.

None of this feels as easy as watching a great explainer video, but easy is not the goal.

Learning has to create friction somewhere. The trick is making sure the friction comes from the skill, not from fake academic hoops around the skill.

Build before you feel ready

The biggest thing I have to push against is the urge to wait until I feel prepared.

I want to understand the whole system before touching it. I want the right sequence, the best practice, and the clean version before I make a mess.

But the sequence gets clearer after you start.

When I started building with AI tools, I didn't know what I didn't know. I could have spent months reading about databases, authentication, deployment, frontend frameworks, background jobs, and testing.

Some of that would have helped. A lot of it would have bounced off because I had no real problem to attach it to.

The first time authentication broke in a real project, auth stopped being an abstract topic. Deployment, database schema changes, environment variables, and tiny UI decisions that burn an afternoon all became easier to understand once they were attached to something I was trying to ship.

Once authentication broke in my own project, I understood it well enough to remember the fix.

This is why "learn by doing" is both true and incomplete.

Doing random things badly is not enough. You need a project that pulls you slightly beyond your current ability, then a feedback loop that helps you correct course.

Too easy and you coast. Too hard and you quit. Slightly too hard is usually where the useful learning happens.

There is some research behind that idea. One paper calls it the Eighty Five Percent Rule: in certain learning tasks, the fastest progress happened when the learner was succeeding about 85% of the time and failing about 15% of the time.

I would not treat that as a universal law. If the stakes are high enough, people can sometimes push through much harder things. But as a default learning target, it feels right: hard enough that you have to adapt, not so hard that every step becomes a fog.

AI changes the feedback loop

AI did not make learning effortless for me. It made the gap between copying and understanding more obvious.

You can paste an error into Claude, accept the fix, and learn almost nothing. I have done that. It feels great for about five minutes, until the same class of problem shows up again and you still do not understand it.

The better use is slower in the moment but better over time. I ask why the error happened and what concept I am missing. I try to predict the fix before applying it, then rewrite the explanation in my own words or break the code on purpose to see what changes.

A lot of the skill is learning how to ask useful questions when you do not yet know the subject well.

That habit was familiar from working in product and growth. You often sit between the user, the business, and the technical system without knowing every detail. You learn to ask what changed, what the constraint is, what evidence would settle the question, and what small test you can run next. Those are also among the skills that still matter as AI improves.

AI rewards the same habit.

It shortens the time between "I'm stuck" and "I can try the next thing." You can get a decent first explanation immediately, ask follow-up questions, compare examples, request a simpler version, test your understanding, and keep going.

Before AI coding assistants, a debugging loop might look like this:

Write code. Run it. Get a cryptic error. Google the error. Read three Stack Overflow threads. Try one fix. It fails. Try another. Lose the thread.

Now the loop can be faster:

Write code, run it, get the error, ask for an explanation, try the fix, ask why it worked, and move on.

That speed matters because learning is partly about feedback volume. You see more cause-and-effect pairs per hour, make more guesses, get corrected faster, and spend less time stuck on the mechanics of being stuck.

AI can also hide the work. If it does the thinking, you get the output without learning the skill. If it keeps you working on the problem, you get more chances to understand it.

The hard part is being a beginner again

The part I like least is feeling bad at the thing.

Shunryu Suzuki wrote, "In the beginner's mind there are many possibilities, but in the expert's there are few." He was writing about Zen practice, but it gets at a real learning problem: becoming attached to being competent can keep you from trying something you do not yet understand.

That gets harder as you get older. Kids are bad at things all day. They are used to it. Adults build identities around competence, then avoid situations that threaten that identity.

This is probably one reason learning slows down. Not because adults cannot learn, but because we get better at avoiding the feeling of being obviously bad.

Fast learning requires some tolerance for that feeling.

You have to publish the rough draft, build the ugly version, ask the basic question, miss the obvious thing, and come back again anyway.

How I would learn a new skill now

If I were starting a new skill from zero, I would not begin with a giant course queue.

I would do this instead.

First, get the basics.

What are the sub-skills? What do good people actually do? What are the common beginner traps? What does a small finished project look like?

Not weeks of research. Just enough to avoid walking into the wrong room.

Second, build a sandbox.

A repo. A blog. A landing page. A spreadsheet. A mock sales process. A tiny app. Something real enough that it can break.

Third, pick a project that is slightly too hard.

Not a toy exercise if the real skill is building products. Not flashcards if the real skill is speaking. Not reading about sales if the real skill is having uncomfortable conversations.

Practice the thing itself as soon as possible.

Fourth, create retrieval and feedback loops.

Before looking something up, try to explain it from memory. After getting feedback, write down the mistake in your own words. Come back to the same concept a few days later and see if you can still use it.

Fifth, drill the weak spot.

This is the part I usually want to avoid. If my UI looks bad, I want to keep working on product logic. If my writing hook is weak, I want to keep polishing the body. If my sales call goes sideways, I want to blame the lead.

The thing that keeps breaking is the next thing to study.

Find it and spend focused time there.

The part nobody likes

Fast learning still feels slow while you're inside it. You can choose better projects, use AI to get unstuck, and spend time with people who are ahead of you. You still have to be bad at the thing for a while.

People often quit because confusion feels like evidence that they are not built for the work. A lot of the time, it is simply the middle of learning something new. The Rule of 100 is another way I have tried to make that awkward middle harder to abandon.

When I was first building with AI, I felt lost constantly. Then less constantly. Then only when I hit a new layer. That pattern keeps repeating. AI agents, SEO automation, product workflows, coding projects. Same loop, different domain.

The faster learners I know are not always smarter. They trust the loop sooner: start before they feel ready, build something real, get feedback, fix the weak spot, and come back again.

Pick the skill and build a sandbox. The first rough project will show you what the course could not: exactly what you need to learn next.