Start Here

There are over 500 articles on this site, going back more than twenty years. This page has a sampling of these articles grouped under the main themes.

If you only read one, read Why open source for product development.

Release first

• Release First, Ship Faster an overview of Release First and why it matters.
• What do we mean by “First”? covers the whole idea in a few lines. Build the release mechanism before the thing you are releasing.
• Why are releases important? on what a release actually does for a team beyond shipping bits.
• A release is what unifies Engineering and Business frames the release as the container that useful and confidence both flow into.
• Isn’t it risky to update your dependencies? takes on the lock-it-down-to-an-LTS instinct by asking how often you update your phone, and whether you worry about it.
• How can Arch Linux get by without releases? argues that a distribution release is an artificial cadence stacked on top of the cadence each package already has.
• How to make releases painless is the concrete version: push a tag, let CI do the rest.

Platform thinking

• What is YOUR Platform? (v2) is the definition in about twenty words, and worth reading first.
• Do you own your platform? a discussion with Khem on this topic.
• False vs Real Platform Development separates the endless tinkering people have been burned by from the real thing, which is focused on shipping early and improving after.
• The smaller you are, the more important YOUR Platform is on why the small company, not the large one, is the one that cannot afford to be locked in.
• The Platform Test is four questions. If you can answer all four, you own your platform.
• The three legs of YOUR Platform is automation, collaboration, and process, in about sixty words.
• Platform thinking vs Product thinking on how the two perspectives differ without the first one ignoring the second.
• The Ability to Improve is the longer read on what happens when a product stops changing, and how a team quietly loses the ability to change it.

Developer experience

• Start with the developer experience is the thesis for this section, and the reason yoe build exists. A build system optimized for one goal, whether that is security or reproducibility, loses to one optimized for fast iteration on a small team. Go is the analogy: neither the fastest nor the safest language, and pretty good at most things with usability that carries the rest.
• How can we increase developer productivity? starts from Steve Jobs on the line of code that is fastest to write, never breaks, and needs no maintenance, then lists seven ways to avoid writing it.
• The defining characteristic of a good workflow tool is integration. Information, collaboration, and automation in one place beats three excellent tools that do not talk to each other.
• The Power of Git* workflows on getting local speed and offline work alongside cloud review and CI, without having to choose between them.
• The importance of small Git commits and pull requests gives five reasons, including the one people skip: a large pull request tends to get rubber-stamped rather than reviewed.
• Keep documentation close to the design and code on why docs in the repo get updated, reviewed, and shipped along with everything else, and why that matters more now that agents read them.
• Document “why” not “how” is four lines. AI can regenerate the how any time you need it. Only you have the why.
• How to iterate quickly on hardware applies the same feedback loop to PCBs, where cheap fast prototypes and CI in KiCad have quietly made it possible.

Borrow the process, not just the tool

• Why open source for product development is the long-form version of the argument: value, change, complexity, and control, and why most successful technology companies landed on open source for all four.
• Why small teams have to be good at borrowing puts a number on it. A small team’s skill at borrowing sets how much time is left for the part only that team can build.
• Exercise: Build vs Borrow is something you can do this afternoon. Draw a line, list what you build above it and what you borrow below it, and write down why.
• Tools or Processes? on why a good enough tool makes the process obvious, and why nobody has to be forced to use one.
• Accepting Constraints in Build Systems follows a hand-rolled Makefile out five years to the point where it collapses, and shows what the constraints of a real build system were buying all along.

---

I write most days. If any of this is useful, the newsletter will send new posts as they go out, and I would genuinely like to hear what you think I have wrong.