On the shape of tools

There is a kind of stubbornness in choosing tools. Not the bad kind — the principled kind. The craftsman who insists on a hand plane when a router would do. The writer who refuses a word processor. The programmer who reaches for the simplest language that can express the problem.

This is not nostalgia. It's leverage.

When the tool is the right complexity for the job, something flows. The tool disappears. You think in the problem space, not the tool space.

When the tool is overengineered, you pay in cognitive overhead. You spend energy on the tool. That energy doesn't go into the work.

This site is built from three formats:

YAML for structure. Every page is a YAML file. Title, slug, sections. The schema is loose — you can add fields and they flow through to templates without ceremony.

Markdown for prose. Long-form content lives in .md files, referenced from YAML via @filename.md. This keeps YAML clean and lets prose be prose.

Go for everything else. Templates are Go's text/template. The build process is Go. There's no DSL, no custom syntax. Just Go.

The result: a page is a YAML file and a Markdown file. To publish, run lyt build. To deploy, copy the dist/ directory.

The best tool for any job is the one that gets out of the way. Sometimes that's a complex framework. Sometimes it's a shell script. Sometimes it's pencil and paper.

The mistake is believing there's a universal best tool. The better move is to know your tools deeply enough to choose the right one, and to stay honest about when you've chosen wrong.

This site is an experiment in choosing smaller. In seeing what happens when the toolset shrinks to the minimum that can do the job.

So far, it feels right.