Ship it safely

The four checks that stop a Tuesday afternoon becoming an incident: review the change, review the migration, find the cause when it still goes wrong, and write it down so it does not happen twice.

• Debugging Systematically — Finds the cause of a bug by reproducing it, forming one hypothesis at a time and testing each against evidence, instead of changing code until symptoms disappear. Use when something fails intermittently, works locally but not in production, or when several attempted fixes have not held.
• Writing Postmortems — Turns an incident into a blameless postmortem with a timeline, contributing factors and owned action items, using language that describes systems rather than assigning fault. Use after an outage, a data loss event, a failed deploy, or when the user asks for an incident report or RCA.
• Reviewing Database Migrations — Reviews a schema migration for locks, downtime and irreversibility before it reaches production, and rewrites unsafe steps into an online sequence. Use when reviewing a migration or DDL change, adding a column or index to a large table, renaming or dropping anything, or when a deploy needs zero downtime.
• Reviewing Pull Requests — Reviews a pull request or diff for correctness bugs, missing tests and unclear naming, ranked by consequence rather than line order. Use when the user asks for a code review, shares a PR link or a diff, or asks whether a change is safe to merge.