Writing a new post

Every post starts with a short block of settings, called front matter, between two lines of three dashes. Everything after that is the post itself, written in ordinary Markdown.

---
title: The Headline Goes Here
slug: the-headline-goes-here
section: Ideas
dek: One or two sentences that sit under the headline.
date: 2026-11-02
---
Your first paragraph starts here.

What each field does

• title is the big serif headline.
• slug becomes the post's link, so keep it short and use hyphens.
• section is the red label above the headline. Each new section you use appears in the menu automatically.
• dek is the subtitle. Aim for one sentence that tells a reader why to keep going.
• date sets the order. The newest post leads the home page.

The details you get for free

The first letter of every post becomes a drop cap. Readers can share any post or save it to read later; saved posts live in their own browser, so there is no account to create.

Write the post first. The design has already been decided.

The other posts on the home page are samples showing what longer essays look like. Replace them with your own whenever you are ready.

The writing that survived all of it was the writing I kept in plain text.

Durability is a feature

A plain-text file has no owner. It does not depend on a company's roadmap or a subscription that lapses. Any computer made in the last forty years can read it, and any computer made in the next forty almost certainly will.

That durability does something to the writer, too. When the file is just words, there is nothing to fiddle with. No fonts to pick, no margins to nudge. The only thing left to improve is the sentence.

The tools that last are the ones that ask the least of you.

Markdown is the right amount of structure

Pure text can be too bare for publishing. Markdown adds just enough: a pound sign for a heading, asterisks for emphasis, a dash for a list. It reads cleanly as raw text and converts cleanly into a web page.

That is the whole system behind this site. A folder of files, each one readable on its own, each one mine.

One promise, kept

A good homepage answers a single question for the person who just arrived: what will I get if I stay? For a journal, the answer is the writing. So the writing should lead, set in type that is a pleasure to read, with nothing competing for attention.

Magazines figured this out a century ago. A strong headline, a subtitle that earns the click, a byline that tells you a person wrote this. Everything else is navigation, and navigation should get out of the way until you need it.

Hide the map until it is wanted

That is why the menu here folds away behind a single button. Sections, the archive and your saved posts are one click away, but they never crowd the page you came to read.

The goal is a page that feels finished at rest, and generous once you start exploring.

Speed hides decisions

When you move fast, you make dozens of small decisions without noticing them: a name, a default, a shortcut through the data. Each is harmless alone. Together they become the shape of the thing, and that shape is hard to change later.

Building slowly means noticing those decisions while they are still cheap. It means writing down why you chose one path over another, so that future you does not have to guess.

A few habits that help

1. Write the explanation before the code. If it is hard to explain, it will be hard to maintain.
2. Ship the smallest real version, then live with it for a week before adding anything.
3. Keep a running list of things you chose not to build. It is often more useful than the roadmap.

Slow is not the same as late. It is the pace at which you can still see what you are doing.