fw-11 — Broader Ideas

Classification is the exportable skill

Essential architecture / production hardening / accretion, defended with evidence from history. Most engineers classify everything as essential, which makes them unable to argue for simplification.

Apply it to your own codebase: which complexity is forced by a requirement, which is hardening earned by a real incident, and which is accretion nobody has dared remove? The third category is where your simplification budget should go, and the tells — Legacy/Compat names, comments citing a year, code with no test — are the same as in Chromium.

Derive-then-read, as a team practice

The rule that made this curriculum work — build a small version before reading the real one — is a training method you can run for others. Before a team adopts a library, have someone implement the core in an afternoon. The questions they generate are better than any evaluation checklist, and the adoption decision improves immediately.

Reading procedures beat reading

"Skip the bailout paths on the first pass" is the highest-leverage single tip here. In most production functions the majority of lines are cases your implementation does not have; read the main path first and the rest become legible as answers to specific questions.

Combine with a deferred list and a stopping rule and large-codebase reading stops being intimidating and becomes a routine, bounded activity.

Next

bi-16 collects the classifications into the complexity notebook, and asks you to defend each one.