On publishing slowly

I have a drafts folder full of technical writing that never shipped. Some of it was too half-formed to post; most of it was fine, but I kept pushing it to “after I run one more benchmark,” and after enough rounds of that, the piece stops feeling urgent to anyone, myself included.

This site is an attempt to fix the second failure mode without giving in to the first. The plan is narrow: four to eight posts a year, each one about something I actually had to work out, and nothing in between. No weekly cadence, no “thinking out loud” threads, no TIL dumps. If I have a half-formed thought worth sharing, a Mastodon post is the right shape for it, not a page on a domain with my name on it.

What goes here

Most of what I’ll write about lives near compilers and systems. I spend my days on Perry, a TypeScript-to-native compiler, and the questions I get stuck on tend to be the kind that take a week of measurement to answer honestly. Things like: what does for...of actually cost in a lowered IR, where is the line between “clever abstraction” and “extra two memory loads per iteration,” and when is the answer to a performance question “the benchmark was wrong.”

Before Perry I spent years on Swift server-side work and contributed to Vapor; some of that will show up here too, when I have something to add that isn’t already in the docs.

What does not

No company updates. No product announcements. No “10 things I learned this year.” If you’re looking for Skelpo news or Perry release notes, those live on their own sites and will stay there.

The first real post

There’s a benchmark investigation in the queue — a longer piece on the cost of abstraction in the Perry front-end, with enough numbers attached that I’d rather over-verify before publishing than push it and have to correct it in public. That article is the reason this site exists now instead of in six months.

Until then, this is the note on the door.