fw-11 — Analysis
The method, and why order matters
"Do not begin with production source. First derive a simple design. Then use production source to discover the constraints that forced additional complexity."
This module is the second half of that sentence and is worthless without the first. Reading Fiber before deriving it produces recognition, not understanding — you will be able to name the fields and unable to say why any of them exist.
The classification, with the tells
| Class | Definition | Tell |
|---|---|---|
| Essential architecture | removing it makes a capability impossible | your derivation independently produced it |
| Production hardening | works in the small, fails at scale or on hostile input | it is a fast path that bails out, or a guard around correct code |
| Accretion | historical; a greenfield design would omit it | names containing Legacy, Compat, Quirks; comments citing a year or a site |
Most engineers classify everything as essential. Identifying the third — with evidence from git history — is the skill, and it is what licenses you to argue for removing complexity in systems you own.
Worked examples from this curriculum
- Fiber's explicit work loop — essential; you derived it.
- Property trees in Blink — essential; without them a transform change re-records.
- Redux listener snapshotting — hardening; correct until a listener unsubscribes mid-loop.
- Blink's fragment fast path — hardening; it bails out, which is the tell.
kScriptDataDoubleEscaped*— accretion; comment-wrapped scripts.[LegacyLenientThis]— accretion, self-labelled by the platform.
A reading procedure that terminates
- Start from your file, not theirs: "where is their version of my
reconcileChildren?" - Read type definitions first — a Fiber's field list teaches more in two minutes than an hour of call-following.
- Skip bailout paths on the first pass. In most production functions the majority of lines are cases your implementation does not have; reading them in order makes the function look incomprehensible.
- Keep a deferred list.
- Stop when you can explain the difference. That is the deliverable — not full comprehension.
Questions beat topics
"Read the scheduler" is not a task. "Why does a Fiber initialise every field to null in the
constructor?" is — and you already know the answer from bi-05, so you can check whether you are
right. A question you can answer wrongly is worth ten times a topic you can read about.