Section · 9 articles
Practice
Migrations, testing, review, incidents and technical debt — the engineering side.
For a separate people-operations perspective, the full explanation covers attendance records and reporting.
Incident Review Without Looking for Someone to Blame
Human error is where the investigation stops, not where it should. How to run a review that finds the conditions, and what to do with the findings.
02Tests That Catch Regressions and Tests That Catch Typos
Coverage measures which lines ran, not whether anything was verified. How to tell which of your tests would have caught the last outage.
03Schema Migrations on a Running System
Old and new code run simultaneously during every deploy, so every change must suit both. The expand-contract sequence, and the locks that bite.
04Feature Flags Without Building a Second Product
Flags decouple deploy from release and quietly multiply the number of systems you ship. The four kinds, and why only one should be long-lived.
05Code Review: What to Look For and What to Leave Alone
Reviews that comment on formatting and miss the concurrency bug are the norm. The categories worth your attention, in order of what they cost when missed.
06Technical Debt: Measuring It Instead of Complaining About It
The metaphor implies a deliberate loan, and most of what gets called debt was never borrowed. How to make the cost visible enough to fund.
07On-Call That Does Not Burn the Team Out
The load is not the incidents — it is the alerts that fire and need no action, and the fear of missing one. What to measure and what to fix.
08Reading Code You Did Not Write
Reading a large unfamiliar system top-down does not work. What does: start from behaviour, follow one path, and write down what you learn.
09Measuring Performance So You Optimise the Right Thing
Most optimisation effort goes to code that was never the bottleneck. How to measure so the answer is trustworthy, and the traps that make benchmarks lie.
For primary background on this topic, consult Site Reliability Workbook.