I have picked up five or six frameworks properly over the last decade, and roughly as many badly. The difference was almost never the material. It was whether the method matched the stage I was at.

Here are the five approaches I keep returning to, in the order I now use them.

This is first because it is the one that works, and the one people skip.

Take a small project you have already shipped — a portfolio, an internal tool, a side project with three screens — and rebuild it in the new framework. You already know every requirement, every edge case and what the finished thing looks like, so all of your attention goes to the only unknown variable.

You cannot get stuck on "what should I build".

You have a correct version to compare against.

The finished result is worth keeping.

The trap is picking something too big. Three screens. If your candidate project has an auth flow, it is too big for week one.

A single well-made tutorial start to finish, typed rather than copied, is the fastest way to get a mental map of a framework’s vocabulary.

The rules that make it work:

• One. Not three in parallel. Finishing beats comparing.
• Type everything. Copy-paste teaches your clipboard.
• Break it on purpose. After each section, change something and predict the error before you read it.

The reason I rank this second rather than first: tutorials teach the happy path by design, and the happy path is not where the framework’s opinions live. It is a map, not the territory.

Nobody reads documentation cover to cover, and nobody should. But there is an order that pays off:

1. The “thinking in X” or philosophy page, if one exists. Twenty minutes here saves a week of fighting the grain.
2. The routing and data-loading pages. This is where frameworks genuinely differ.
3. The deployment page. Reading it early changes decisions you make on day two.
4. Everything else, on demand.

Then — and this is the part that matters — read the upgrade guide for the last major version. It is the most honest document in any project: it tells you exactly which ideas turned out to be wrong, and why.

Not the framework’s source. Something built with it, by someone good, that is small enough to hold in your head — a starter kit, an example app, a plugin.

What I look for:

• How they organise files once the project is past ten of them.
• Where the boundary between framework code and their own code sits.
• What they wrote by hand instead of installing.

An hour reading a well-made example teaches more about idiom than a day of documentation, because documentation shows features and examples show choices.

The last step, and the one that converts “I can do this with the docs open” into “I know this.”

Write the post you wanted three weeks ago. Not a tutorial — a comparison. “Here is how routing works in this framework, here is how it worked in the one I came from, and here is the case where the difference bites.”

Writing it exposes every place where you are pattern-matching rather than understanding, which is uncomfortable and precisely the point.

The schedule I use now

A framework I need for actual work, in about two weeks of evenings:

• Days 1–2 — philosophy page, one tutorial, typed.
• Days 3–7 — rebuild a three-screen project I already own.
• Day 8 — read the routing, data and deployment docs properly, plus the last upgrade guide.
• Days 9–10 — read one good small codebase end to end.
• Days 11–14 — write the comparison post.

Two weeks sounds slow until you compare it to the six months of half-knowing that the “learn as you go on a real project” approach usually costs.

One thing that is not on the list

Watching videos at 2× while doing something else. I have never once retained anything that way, and I have tried more times than I would like to admit.