Continuous Integration
CI as a feedback system, not a task runner: what to check, in what order, how to parallelise it, what to cache, and why a slow pipeline changes engineering behaviour.
Merging everyone's work into a shared mainline often enough that divergence stays small, and proving the merged result actually works.
The product of a pipeline is a trustworthy verdict delivered while the author still has the change in their head; everything else is overhead.
Order checks by signal per unit of cost, gate on the cheap ones, and be explicit about which checks run on a branch, on trunk, and nightly.
Wall-clock time is set by the longest dependent chain, not by total work — so parallelism helps exactly as far as the graph and the shared resources allow.
A pipeline should be a DAG of real dependencies; stages, sequential steps and path filters are approximations of it, and each approximation has its own way of being wrong.
A cache key is a claim that two inputs are equivalent; when the claim is wrong the pipeline does not get slower, it gets wrong.
A red pipeline has four common causes with four different correct responses, and telling them apart quickly is a learnable procedure.
The pipeline is a privileged production identity that executes code from anyone who can open a pull request — and those two facts have to be kept apart.
A test that passes and fails on identical input destroys the verdict for every other test in the run, because it teaches people to re-run until green.