Learning by Building Small Things in Public

Finishing a course and finishing a project feel similar from the inside, but they test different things. A course tests whether the material was presented clearly. A project tests whether the pieces work together when nothing says which piece is wrong. Building small things is one of the fastest ways to find where understanding stops, and sharing them adds feedback no course can supply.

Choose a project that asks one question

A useful small project is built around one open question, something the builder cannot yet answer. Keep the scope narrow enough to finish in a few sessions. One example is comparing keyword search with embedding-based search over twenty personal notes, to see which approach finds the passages that were actually wanted. The project is small, the question is clear, and the result can be checked by reading the notes yourself.

Avoid projects whose main difficulty is setup. If three weekends disappear into configuration and the question is never reached, the project has taught installation, which is useful once but rarely the thing you set out to learn. Pick one where the dependencies are already in place or easy to replace, and where the data is in a form you can open without help. Good sources are material you already own, such as your own files, the logs of a tool you use every day, or a public dataset whose license allows reuse. Check the license before building on a dataset, and keep a copy of the exact version you used, since public files change.

Keep a short build log

A build log is a running record of what you tried. Each entry needs five things: the date, what you attempted, what happened, what you think caused it, and what you will try next. Five lines is enough. An entry might read: split the notes by paragraph; retrieval returned headings only; suspect the chunks are too short; next, split by fixed length with some overlap. The log keeps a failed attempt from being repeated a week later, and it becomes the raw material for explaining the project to someone else, including in an interview.

The cost is a minute or two at the end of each session. Entries are easy to skip on a productive day, which is exactly when the reasoning is freshest, so make the entry the last step of the session rather than an optional extra.

Share before it feels ready

Public work is simply work that someone else can read. It might be a repository, a short written account, or a demonstration at a study group. Sharing early is uncomfortable, and that discomfort is part of why it helps. A reader who sees an unfinished method will ask about the gap you did not know was there. A first share can be small: a page that states the question, shows one result and lists two things you are unsure about. Small shares are easier to start and easier to correct.

Share the question, the method, the result and the failures. The failures are often the most useful part. What to keep private matters just as much. Remove credentials, personal data, anything from an employer's codebase or data, and any material you do not have the right to publish. If there is doubt about whether a project touches employer material, check the policy before posting. Sharing is a choice, and it is reasonable to keep some projects private while learning. Public work has costs as well. A post that attracts little attention can feel like a verdict, and comments are sometimes careless. Presenting a project as a learning record rather than a product launch makes both easier to bear and sets a fair expectation for readers.

Ask for feedback that changes the next step

"What do you think?" usually returns politeness. Specific questions return something you can act on. Ask where the approach would break on a larger input, which assumption a reviewer would question first, or what result would convince them the method was wrong. Give the reader context: what was expected, what was measured, and what remains uncertain. It also helps to ask directly for the weakest part. Reviewers tend to be polite about parts that look finished, and the weakest part is where the learning is.

A useful request names the single decision you want checked. Reviewers can then read with a purpose, and their answers become evidence rather than general approval.

A finish line you write down

Perfectionism is the usual reason small projects never end. The remedy is to define the finish line before starting. Write one sentence that says what the project must show to count as done, then set a date a week or two away. Build a version that meets that sentence and nothing more. Features that occur to you later go onto a list for the next project. The finish line also limits a common pattern, in which one unfinished project is dropped for a new one until the unfinished pile grows and none of it teaches anything.

Try this on your next project. Write the finish line in one sentence. Share the draft with one reader and ask which claim in it is not yet supported. Revise until the reader agrees that each claim is either supported or deliberately out of scope. Then build only what the sentence requires. The result will be smaller than first intended, and it will teach more, because all of it can be seen at once.