A few months back, a teammate asked me how long it would take to prototype something in Vue. We’re a React shop. I hadn’t touched Vue in years. I said “a day, maybe two.” He was surprised — not at the estimate, at the confidence. He’d been “learning Vue” on the side for a few weeks and didn’t feel ready to ship anything.
That gap is what this post is about. Not Vue. Not React. The gap between studying a framework and building with one.
Framework expertise is the wrong unit
Our industry sells “X developers” — React developers, Python developers, Java developers. Job listings ask for years of Angular experience. Boot camps promise to turn people into Full Stack JavaScript Developers in twelve weeks. The framing leaks into how people learn: pick a framework, study it for months, then maybe build something.
The framing is wrong because frameworks change. jQuery was the future once. AngularJS was the future once. Whatever you tie your identity to today will get replaced in five years. Framework knowledge depreciates fast, and the depreciation rate is mostly out of your control.
What doesn’t depreciate: authentication, state management, data persistence, API design, async patterns, error handling. These exist in every stack. Once you understand them as concepts, the framework is mostly syntax — somebody else’s opinions on where to put things.
That’s the actual unit of competence. Not “I know React.” More like “I know how to design a state-management story, and React happens to be where I’m typing it today.”
How I actually pick up a new stack
I don’t read the docs cover to cover. I skim the table of contents to get a mental map — where’s routing, where’s forms, where’s auth — and then I jump straight to whatever the current task needs.
Then I start building. Not a todo app. The thing I’m actually trying to ship. Hello World, then one endpoint hitting a database, then auth on that endpoint, then validation, then the real feature. Each step is small. Each step gets a commit. The git history becomes the learning journal.
Twenty percent understanding is enough to start. The remaining eighty percent fills in when something breaks, because debugging real code teaches you patterns that no tutorial ever will. Context is the only thing that makes documentation stick.
The reason this works isn’t a productivity trick. It’s that the question “do I understand this framework yet?” doesn’t have an answer. The question “does my endpoint return the right JSON?” does. Working in terms of the second question keeps you out of the trap of preparing forever.
The choice question
Once you’ve shipped in four or five stacks this way, the question “should I learn X?” stops mattering. The real questions are about the project: what am I building, what does the team already know, what’s the ecosystem like, what are the performance characteristics. “Do I personally know this framework yet?” stops being on the list, because the answer is always “I will by the time it matters.”
That’s a different relationship with technology than the one the industry trains you into. It’s the difference between collecting tools and using them.
What changed with AI
The friction in this approach used to be syntax hunting and boilerplate. Trying a new stack meant hours of “how do I configure this,” “what’s the import path for that,” “why does the build fail.” Painful enough that most people gave up and went back to tutorials.
That friction is mostly gone now. Coding assistants — Claude Code, Cursor, Copilot — handle the syntax layer well enough that you can describe what you want in plain English and get runnable code back. The interesting work moves up a layer: reading the generated code, recognising the patterns, deciding what to keep and what to change.
This is good news for the building-blocks approach. The AI takes the tedious part — the part that was never intellectually interesting — and leaves you with architecture and design, which is what transfers between technologies anyway.
I used Claude Code recently to prototype something in a Rust web framework I’d never touched. In the old workflow I’d have lost most of a day to the borrow checker. Instead I described the feature, read the generated code carefully to understand Rust’s patterns, modified what didn’t fit, and asked follow-ups when something looked off. Working feature in about ninety minutes. I learned more Rust in that session than I would have from a week of “Rust By Example,” because every line had a reason and a context.
The actual prompt
Pick something you’ve been meaning to learn. Give yourself two hours. Build something you’ll actually use — a script that automates an annoying thing, an API for a side project, a small tool. Don’t read the docs first. Don’t watch the tutorial. Run the quickstart and start building the next brick.
You’ll surprise yourself. More importantly, you’ll stop asking “should I learn React?” and start asking “what am I building?” — which is the only question that was ever worth asking.