Lesson 3.1 · Pick your first project

Where this gets you: one real project chosen (the thing you’ll carry through every remaining lesson), and a clear, written definition of done for it.

The idea

Back in Lesson 2.1 you wrote three candidates. Pick one. It becomes the thread for the rest of the course.

A good first build has three traits.

Small. A few files, or something you could finish in a weekend. Not a monorepo, not “rebuild our internal dashboard.” Ten moving parts means you’ll spend the course fighting scope instead of learning the skills.

Real. Something you actually want to exist. A toy you don’t care about gets toy-level effort, and the habits won’t stick.

Checkable. There’s a plain answer to “does it work?” A command that runs. A page that loads. A bug that’s fixed or isn’t. If you can’t say what “working” looks like in one breath, tighten it or pick another.

What a bad pick costs you. Two learners start Lesson 3.2. One chose “an expense tracker.” Every later exercise stalls on a design question: should it sync? multi-user? which database? By Lesson 4.1 they’re still arguing with the agent about architecture and have shipped nothing. The other chose “a CLI that reads my bank CSV and prints this month’s three biggest expenses.” Done in an evening — and every later lesson had something real to practice on. Same course, same agent. One of them finished it.

The bug you’ve been avoiding is a good pick. So is a small CLI or one-page tool. Save the sprawling idea for later.

Here is the sizing rule by learner:

Do it

Look at your three candidates. Cross off anything too big, not real, or with no clear finish line. Pick from what’s left. If two survive, pick the smaller one.

Now write a definition of done. One paragraph, plain language: what the project does, who uses it, and the exact thing that proves it’s finished. Keep it somewhere you’ll see it — a NOTES.md in the repo, a sticky note, anywhere.

Your exercise

Choose your project and write its definition of done.

Then say it back in two sentences: one for what it does, one for how you’ll know it’s finished. If you can’t do that cleanly, it’s still too fuzzy. Keep cutting until you can.

You’re done when you’ve picked one project and can state, in two sentences, what it does and how you’ll know it’s finished.

Practice proof: create PROJECT.md or NOTES.md with three headings: What I am building, How I will know it works, and What I will not build yet.

Build on it: if nothing on your list survives the three traits, take one of these as your course project — a CLI that renames the screenshots cluttering your desktop by date and app, a one-page tool that turns a CSV into a sortable HTML table, or the oldest bug in a repo you already own.

Why this matters

Every lesson left in this course ends with “do it on your project.” If the project is vague or too big, each exercise turns into a fight with scope instead of practice with the skill. A small, real, checkable project is what makes the rest of the course compound. Pick well now and every lesson after this gets easier.

Previous: Lesson 2.4 · Staying in control · Next: Lesson 3.2 · Plan before you build