Practice30 min–1 weekend

Challenges

Five exercises that turn the course into muscle memory. Four are small; the fifth is the one that changes how you see yourself.

How to use this page

Do them in order on a real project — yours, or the one you're about to start.
Progress saves in this browser only.

01Make a repository real

Time: 45 minutes · You produce: a repo that runs from a clean clone

Take an empty folder or a messy project. Add the eight things from module 02 — pinned runtime, one command to run, one command to test, formatter, linter, git history, honest README, CI. Then prove it: clone into a temp directory and run it.

I cloned it fresh and it ran without asking anyone anything
The README has what / run / test, copy-pasteable
CI is green on a push
There are at least five meaningful commits

02Three commits, one rule, three tests

Time: 2 hours · You produce: a small feature with history and tests

Pick one real rule your project needs (a calculation, a permission, a filter). Implement it in three commits: the test that fails, the minimum code that passes, then the cleanup. Add two more tests for the boundaries — empty, maximum, unauthorized.

The first commit contains a failing test and nothing else
The second makes it pass with as little code as possible
I have tests for at least two boundaries
Each commit message says what and why

03Break it on purpose, then bisect

Time: 45 minutes · You produce: the commit hash you would never have found by reading

In a repo with real history, introduce a subtle bug in a new commit. Then, without reading the diff, use git bisect (or plain binary search on commits) to find it. Write down how many runs it took.

I used git bisect start / good / bad rather than reading code
I recorded the number of test runs it took
The fix came with a regression test

04Review something real

Time: 30 minutes · You produce: five substantive comments

Review your own last change, or an open pull request in a project you use. Leave five comments that are about correctness, tests, security, operability or clarity — not style. At least one should be a question rather than a verdict.

Five comments, each naming a consequence rather than a preference
At least one is phrased as a question
I flagged the most important issue first, not the easiest

05Capstone: ship it

Time: one weekend · You produce: a URL, a README, and one real user

Build the smallest useful version of a project from module 10. Deploy it. Then hand it to one person and watch, in silence, while they use it.

It runs from a clean clone with one command.
The core rule has tests; the suite is green in CI.
It is deployed at a real URL, with a smoke test of the main journey.
Secrets are not in the repo; auth is checked server-side.
One person who isn't you has used it.
You wrote down the first thing they got wrong — that's your next change.

It has a URL someone else can open
CI is green and runs the tests
A real person used it
I recorded the first failure they hit
No secrets in the repo or the logs

How to judge your own work

No certificate. The test is whether another engineer would be comfortable inheriting what you built.

Signal	Beginner	Solid	Ready to work on a team
Setup	It runs on your machine	One command, documented	Clean clone in CI, same artifact everywhere
History	One giant commit	Small commits with clear messages	Reviewable PRs, feature branches, revertable releases
Tests	None, or only happy path	Rules and boundaries covered	Fast suite, regression test per bug, no flakes
Design	Everything in one file	Cohesive modules, clear names	Seams that isolate change; blast radius understood
Debugging	Change things until it works	Reproduce, isolate, prove	Bisect, traces, postmortem with a follow-up fix
Shipping	Manual copy to a server	CI + a deploy step	Flags, canary, rollback plan, smoke tests
Security	Hope	Secrets out of repo, auth server-side	Scanned dependencies, validated inputs, least privilege

If you get stuck

Make the scope smaller, not the effort bigger. Almost every stalled project is three projects wearing one name. Cut it to a single screen and a single action, ship that, then add the second thing.