I have a habit that looks irrational from the outside: I rebuild things that already exist. A Pomodoro timer. A note-taking app that mimics Obsidian. Pieces of a terminal, to understand how the kernel talks to it, detail by detail, step by step.
None of these will be products. That was never the point.
The question behind the habit
A while ago I tried to write down what separates a top 1% software engineer from a junior. Not in vibes — in skills you could actually name: domain-driven design, BDD, recognizing code smells, design patterns, system design, taking a feature end-to-end from writing code to running it in production.
The list was useful. But reading about design patterns is like reading about swimming. The knowledge only becomes real when you rebuild something and hit the wall the pattern was invented for.
Rebuilding as a learning protocol
My protocol, refined over many side projects:
- Pick something you use daily and take for granted (a timer, an editor, a shell).
- Rebuild the smallest version that is honest — not a toy that fakes the hard part, a small thing that does the hard part.
- Write down where you got stuck. The stuck points are the curriculum. Everything else was already easy.
- Compare with the real implementation only after you've suffered. Reading Obsidian's architecture before building your own teaches you trivia. Reading it after teaches you decisions.
Why "in public"
Publishing the stuck points is uncomfortable, which is exactly the signal that it's worth doing. A blog post that says "I didn't understand how PTYs work, here is what finally made it click" is more useful than ten posts that explain PTYs correctly but anonymously, as if the author was born knowing.
This site is the public part of that protocol. The garden grows slowly. Like garoa — it doesn't storm, it accumulates.