Writing on product work that we keep coming back to, gathered from across the internet.
Every title opens the original on the publisher’s own site. We point at this writing and credit the people who wrote it. We do not host it.
Rewritten in 2024 and considerably sharper than the 2000 original. Fowler lists the practices that make integration cheap, from self-testing code to daily merges, and he is honest about the team conditions the approach depends on.
Defines the four DORA measures and walks through the pipeline Google built to collect them from real systems. Read it before adopting the metrics, because how your organisation defines a deployment decides what every one of the numbers means.
Works through unit, integration, contract and end to end tests with running code rather than a diagram. The rule to push each test as far down the pyramid as it will go is what keeps a suite fast enough to run on every commit.
Sorts toggles into release, experiment, ops and permissioning categories, each with a different lifespan and a different owner. The section on retiring toggles is the reason to read this before your codebase fills up with them.
Rolling a change out to a small slice of users before everyone gets it, with the routing and capacity questions that come attached. Pairs naturally with feature toggles if you are assembling a release strategy from first principles.
Splits debt along two axes, prudent against reckless and deliberate against inadvertent. Handy when you need to show a stakeholder that some shortcuts were a business decision while others point at a gap in skills or review.
North traces how behaviour driven development grew out of teaching test driven development, and where the given when then template came from. The cash machine example is still the clearest short illustration of the idea.
Fournier lists what actually decides whether a senior engineer is effective, from writing a design document to running a meeting that ends in a decision. Good raw material for a levelling framework or a growth conversation that keeps stalling.
A catalogue of branching patterns and the forces that push a team towards each one, from mainline development through release branches to long-lived integration. Read it when a team is debating trunk based development without having agreed what the alternative costs.
The article that named responsive design and set out the fluid grid, flexible image and media query combination behind it. More than a decade on it remains the clearest statement of why a layout should adapt rather than fork.