post link post archive

On Writing Software for Yourself

There is a particular satisfaction in writing software that only you will use. The constraints are different. You don't need to handle every edge case or write documentation for a team. You can make assumptions. You can be opinionated in ways that would be irresponsible in shared code.

I've been thinking about this while building the server that runs this blog. It's a single Go file. No database, no CSS framework, no build step. Markdown files on disk, served as HTML. The entire thing fits in my head, and that's the point.

The right amount of abstraction

When you're the only user, you can skip the abstraction layer. You don't need a plugin system. You don't need configuration files. You can hardcode the port number because you know where it runs. This isn't laziness — it's precision. Every abstraction you skip is a surface area you don't have to maintain.

The fmt.Sprintf calls that generate HTML in this blog are a good example. A template engine would be "better engineering," but for three HTML shapes that rarely change, string formatting is honest work.

The best tool is the one that disappears. You stop thinking about it and start thinking about the thing you're making.

What changes when you're the audience

You become more willing to experiment. If something breaks, the blast radius is your own afternoon. You can rewrite the whole thing on a Saturday and lose nothing but time. This freedom is underrated.

Weekend Projects

I spent Saturday morning rewriting the deploy script for this blog. The old version had accumulated enough conditionals that I couldn't read it anymore. The new one is twelve lines of shell. Sometimes the best refactor is rm followed by starting over.