Learn by Building

The tutorial plateau

You finish courses. You follow along. Everything works. Then you open an empty file to build something of your own and freeze.

That gap has a cause: following a tutorial exercises comprehension, and building exercises decision-making. They're different skills, and only the second one is what a job actually consists of.

Claude can collapse the two hardest parts of starting a project — deciding what to build and knowing whether your code is any good — without doing the middle part for you.

Rule one: ask for the spec, never the code

Wrong:

Build me a Python CLI tool that tracks expenses.

You now own 200 lines of code you didn't write and can't debug. This is the tutorial plateau with extra steps.

It looks like progress and behaves like technical debt. The first time it breaks you'll have no mental model of it, and debugging unfamiliar code is harder than writing it. If you couldn't have written a line yourself, you haven't saved time — you've deferred it at interest.

Right:

Act as a tech lead scoping a practice project for me.

I've completed [Codefinity course/track] and I know [skills].
I want to build [rough idea] in about [8 hours] to consolidate what I learned.

Give me:
1. A one-paragraph spec — what it does, what it explicitly does NOT do.
2. 5 milestones, each independently runnable, hardest concept last.
3. For each milestone: the 1–2 concepts it forces me to use.
4. Three edge cases I'll probably forget.
5. A "done" definition.

Do NOT write any code. I'm writing all of it.

You get a real plan, and every line of the implementation is still yours to earn.

A spec states what the thing does and — critically — what it does not do. A milestone is an independently runnable slice, so you always have working software rather than a half-built whole. A definition of done is the condition that stops you polishing forever. All three are project-management basics, and having Claude produce them is how you practise reading a brief before you have to write one.

Unbounded scope is why practice projects die at 60%. Forcing an explicit list of exclusions turns a vague idea into something finishable, and finishing is what converts a project into confidence.

Rule two: get reviewed like a junior hire

Once a milestone runs, submit it. But name the rubric — an unguided "review my code" gets you style nitpicks.

Review this as a senior [language] developer reviewing a junior's PR.

Rate 1–5 and give specifics on:
 - Correctness — does it handle the inputs it claims to?
 - Idiom — is this how an experienced [language] dev would write it?
 - Readability — could I understand this in 6 months?
 - Edge cases — what breaks it?

For each issue: say what's wrong and WHY it matters. Do not rewrite my code —
describe the change and let me make it.

[paste your code]

That final constraint is the whole discipline. A rewritten file teaches you nothing. A description of the change makes you implement it, and implementing it is the lesson.

Log the four numbers for each milestone. By milestone 5 you'll have a visible curve, and you'll know which axis is your weak one. That's more useful career information than a course completion certificate.

Rule three: interrogate the review

Reviews are opinions. Push back:

You said [X] is unidiomatic. Show me a case where my version actually causes
a problem, and if it doesn't, say so.

Sometimes the answer is "you're right, it's fine." Learning to tell the difference between real advice and reflexive advice is a senior skill, and this is how you practise it.

Claude will produce plausible criticism on request, including of code that's perfectly fine. Asking it to demonstrate the concrete problem is how you separate real advice from reflexive advice. If it can't produce a failing case, you can keep your version.

The full arc

SPEC (Claude)  →  MILESTONE 1..5 (you)  →  REVIEW (Claude)  →  REVISE (you)
                          ↑                                        │
                          └────────────────────────────────────────┘

Notice where Claude appears: at the boundaries. The middle — where the actual skill forms — is entirely yours.