codeLabs

My weekly build log format

Deploy & ship · updated aug 2026

build-logworkflowwriting

I write a build log every week, and the reason it’s survived past the first month (unlike a couple of earlier attempts at journaling my work) is that I stopped trying to make it comprehensive. Early attempts tried to cover everything I’d touched that week, and that turned writing it into its own multi-hour task I started resenting and eventually skipping. The current format takes twenty minutes on a Sunday and I’ve kept it up for months.

The structure is loose but consistent: what shipped, what I decided against and why, and one thing that didn’t work. That last section is the one I almost cut early on because it felt like admitting failure publicly every week, and it’s turned out to be the most useful section both for readers and for me. Writing down what didn’t work, specifically, forces a level of honesty about the week that “what shipped” alone doesn’t. A week can look productive in the shipped list and still have burned three days on an approach I abandoned, and if I don’t write that down somewhere I tend to forget it happened and risk repeating the same dead end later.

I don’t force it into a fixed number of bullet points per section. Some weeks “what shipped” is one substantial thing, some weeks it’s five small ones, and padding a thin week out to match a busier one, or trimming a busy week down to a tidy list, both felt dishonest once I noticed myself doing it. The format should reflect the week, not the other way around.

I write it project by project rather than chronologically, because RaceLink, HostLink, and Liquid Lava don’t share a narrative and forcing them into one just makes the post harder to follow for anyone who only cares about one of the three. A reader following HostLink shouldn’t have to wade through a paragraph about Liquid Lava’s onboarding flow to get to the part relevant to them.

The other rule I’ve kept is writing it the same day something happens rather than reconstructing the week from memory on Sunday. Memory compresses toward whatever felt most dramatic at the time, and the boring-but-important decisions get lost first. A running note through the week, even a rough one, means Sunday is assembly and light editing rather than trying to remember Tuesday’s reasoning from four days out.

Nic

builder, codelabs.com.au

Stay up to date with AI coding

New articles roughly every couple of weeks. No spam, unsubscribe any time.