A few working notes I use while building things.
Planning, documentation, refactoring, and tooling can all help. They can also become a way to avoid the next real step.
At the end of the day I want to know what changed: a bug fixed, a page shipped, a test added, or a decision written down.
If nothing changed, the next step probably needs to be smaller.
Finished beats almost-finished. A rough but usable project is easier to learn from than one that never gets wrapped up.
Starting is easy because nothing has gone wrong yet. Finishing means dealing with the awkward parts: the bugs, missing docs, rough edges, and choices that need to be made before something is actually usable.
Once a thing is finished enough to use, I can either keep improving it or move on without carrying the whole thing in my head.
Simple things are easier to understand, change, and delete. Every abstraction adds something the next reader has to keep in their head.
The right time to add complexity is when the simple version has stopped working. Not before.
Start with the direct version. Add structure when the code asks for it.