A little space
for clear thinking.

Before choosing tools, write down the one thing a project should help someone do. Then build the shortest complete path to that outcome.

Small does not have to mean unfinished. A single thoughtful workflow, with clear feedback and a way to recover from mistakes, can be more useful than a long list of half-built features.

Keep a separate list of ideas for later. Let actual use decide which ones deserve a place in the next version.

A useful project note answers three questions: what is this for, how do I use it, and how do I know it worked?

Write down the assumptions that are easy to forget. Put examples next to the instructions they explain. When something changes, update the example along with the implementation.

The aim is not to record everything. It is to leave enough context that the next person can take a confident first step.

Every project contains decisions that will outlive their original context. Keeping responsibilities small and interfaces clear makes those decisions easier to revisit.

Before adding an abstraction, look for a real boundary: a different reason to change, a distinct owner, or an independently useful operation. A boundary should explain the system, not merely divide its files.

Favor changes you can understand, verify, and undo. That leaves more time for the work the project was meant to support.