What This Notebook Is For

I’ve been writing software for a while, and most of what I learned doing it is gone. Not the code — the code is in the repos. What’s gone is the reasoning: why I chose one approach over another, what I tried that didn’t work, the thing that took two days to understand and then felt obvious. Commit messages don’t hold that. My memory doesn’t either.

This site is where I keep it now.

It’s a notebook, not a blog. The distinction matters to me. A blog implies an audience and a schedule. A notebook is for the work — written first so I understand what I did, and made public because writing for a reader forces a clarity that private notes never do. If it helps someone else, good. But the primary reader is me, six months from now, trying to remember how something worked.

Three kinds of things go here:

• Project notes — what I’m building and the decisions behind it, written while the reasoning is still fresh.
• AI experiments — I work with these models seriously, which means testing what they actually do rather than what the marketing says. Those results go here.
• Repo reads — close readings of open-source projects worth understanding. Not summaries; arguments for why a particular repo is worth your attention and what you can learn from how it’s built.

The notebook runs on a small pipeline I built: point it at a GitHub repo, and it pulls the code and history into a draft I can edit into something real. That tooling is itself one of the projects I’ll write about here.

The standard I’m holding myself to is simple: every entry should be worth the time it takes to read. No filler, no announcements, no writing that exists to be written. Just the work, explained well enough that it stays understood.