Skip to content
Time to Signal

How these notes are written

Structure

Most notes follow the same shape: what the thing is, why it is harder than it looks, the method, where the method misleads, and how to tell whether it worked.

The sections on what does not work are not optional. A description of caching that omits the reproducibility requirement describes a cache that will not hit.

No benchmarks

Deliberately. Build times depend on codebase size, language and hardware; delivery metrics depend on deployment risk and on definitions; and published figures are self-selected, because organisations with poor numbers do not publish them.

Where orders of magnitude are offered, they are directional and are not targets. The comparison that survives scrutiny is your own trend.

Measuring the system

A principle running through the collection: every measure here describes a toolchain, not a person.

Where a measure could be attributed to an individual — pipeline triggers, local build telemetry, the resource field in an event log — these notes recommend aggregating at ingestion, and explain why the practical argument is stronger than the ethical one: attributed measurement degrades the data it collects.

The uncomfortable material

Most programmes measure without acting, and become a dashboard nobody reads.

Coverage as a gate produces tests without assertions and punishes deleting dead code.

Adding capacity can make execution slower, because new runners start cold.

Build performance work becomes architecture work, eventually and unavoidably, and saying so early is better than after six months of tuning.

Commercial position

No vendor material. No sponsored content. No affiliate links. No product rankings.