bi-12 — Broader Ideas

Instrument your own systems the way Chromium instruments itself

Trace events are literal strings in the source, so a timeline entry greps straight to the code that produced it. Structured, correlated, cross-process, low-overhead, and enabled by category.

Your equivalent is OpenTelemetry spans — and the design questions are the same:

• Are span names greppable identifiers, or interpolated strings? (Interpolated names destroy the bridge back to source.)
• Are they categorised, so you can enable a subset?
• Do they carry flow/parent links across process boundaries?
• Is the overhead low enough to leave on?

The minimum instrumentation test: could a stranger diagnose this subsystem from a trace alone, without reading the code? If not, you are relying on tribal knowledge.

Perturbation is a property of your instrument

A debugger destroys timing; tracing perturbs it far less; a log line has no timeline at all. Any bug whose existence depends on ordering is a tracing problem, and reaching for a breakpoint makes it disappear — the most frustrating way to lose an afternoon.

The same caution applies to your own observability: a render-count tracker that holds references leaks, and a profiler that adds 40% overhead is measuring itself.

Handoff discipline

The debugging exercise's "write the handoff note" is not busywork. In a codebase this size, an unrecorded finding is a finding you will re-derive. The note format — observed, ruled out, next step, reproduction — is worth standardising on your team.

Next

bi-13 turns reproduction into a test; bi-15 uses tracing as the primary instrument for all eight vertical traces.