DEV Community

Cover image for I finished the Tenzies "toy" and immediately hit a wall
BlackJosh007
BlackJosh007

Posted on

I finished the Tenzies "toy" and immediately hit a wall

So I wrapped up the basics course, played around with (and extended) the Tenzies app — a tutorial toy, not a real problem, as I keep reminding myself — and figured I was ready to build something real. Something that actually solves a problem, not just proves I can follow along.

I had an idea. I streamlined it. I felt good about it.

Then I did something that wrecked that feeling: I pulled up a proper list of React concepts and checked off what I'd actually covered.

✅ derived state
✅ forms and controlled inputs
✅ (medium) state management
—  complex component architecture
—  reusable components
—  custom hooks
—  API calls
—  loading/error states
—  routing
—  optimistic updates
—  pagination/filtering/search
—  authentication
—  local persistence
—  performance considerations
Enter fullscreen mode Exit fullscreen mode

Three and a half out of fourteen. Omo.

The fork in the road

This left me with a real decision, not a vibes-based one: do I stop and take a structured advanced React course, or do I keep building and pick up the missing concepts as the project demands them?

I was already skeptical of the second option going in — and for a specific reason. If I build while leaning on AI to fill every gap, I could ship something that looks like my project while understanding almost none of the concepts that made it work. That's not learning, that's assembling.

So before picking a side, I had to answer a harder question: what actually stops "learning while building" from turning into "pasting while building"?

Here's where I landed — the rule I'm holding myself to for this build:

  1. Get the overview of a concept first (with or without AI help) — not the implementation, just the shape of the idea.
  2. Attempt the feature that needs it, myself, before asking anything.
  3. If I'm stuck after real reasoning and research — not five minutes of staring — then I bring Claude in, and only for a hint, not the answer.
  4. The overall sequence of what to learn when is planned out for me, since I don't yet know this territory well enough to sequence it myself.

That last point matters more than it sounds — it's the difference between "I'll learn as I go" (vague, no accountability) and having an actual curriculum sitting underneath an unstructured build.

I'm treating this as a real test, not a permanent decision. If a few weeks in this path isn't producing real understanding, I'll stop and go take the structured course instead. No shame in switching — just data either way.

A quick contrast: learning Tailwind was the opposite of this

Small aside, but it's stuck with me. I picked up Tailwind CSS purely by reading the documentation — no tutorials, no courses. It just clicked. If you're learning Tailwind: skip the tutorials, the docs are enough.

React, at this depth, is not that. And honestly, that gap in difficulty is part of why I needed an actual system before diving in, instead of just winging it.

What's next

The project this is all in service of — a progress-tracking app for an accountability group I'm part of — deserves its own post, because the scoping conversation alone was a whole thing. That's coming separately.

For now: if you've gone through this same fork — course first vs. learn-by-building — I'd genuinely like to hear which way you went and whether you'd choose the same again.


Top comments (0)