bi-14 — Analysis

Why this module is the falsification step

Reading Blink is unfalsifiable — you can believe you understood it. A CL is not: it forces you to locate the subsystem, identify the invariant, write the right test at the right layer, and defend the design to someone who owns the code and owes you nothing.

It also teaches the thing you cannot learn in your own codebase: making a change in a system you do not own.

Required invariants of a landable change

  1. One change per CL. A fix plus a refactor plus a rename is three CLs.
  2. A test that fails without the fix, at the layer the bug lives.
  3. The right layer. Fixing a symptom at a call site because the cause is in unfamiliar code is the most common rejection.
  4. Correct handle types and lifetimes (bi-06).
  5. Compatibility evidence if the change is web-visible. Correct per spec is necessary and not sufficient.

The step that surprises product engineers

If your fix changes what pages can observe, the conversation is about compatibility, not correctness. UseCounter metrics answer "how much of the web does this?", and a removal proposal without usage data does not proceed.

In a product you change behaviour and watch your own metrics. Here you must show the web will survive it. That is a genuinely different discipline, and treating it as bureaucracy is the fastest way to be dismissed.

Choosing a bug that will land

Bad first bugs are interesting; interesting bugs are unfixed because they are hard, contested, or blocked on a design decision. A good one is in a subsystem you have already studied, has a reliable reproduction, a spec-defined expected behaviour, is small, and is not in a directory being actively rewritten:

git log --since=90.days --oneline -- <directory> | wc -l

Thirty seconds; saves weeks.

Why the record matters

Reviewer feedback is the only part you cannot generate yourself: a domain expert telling you what you missed, for free, on your own work. Most engineers read it, fix the code, and forget it. Writing it down converts a review into a durable lesson — and a rejected CL with a clear architectural lesson is a successful lab.