bi-14 — Broader Ideas

Working in systems you do not own

This is the transferable skill, and it applies well beyond open source: another team's service, a vendor SDK, a legacy subsystem with no owner. The disciplines are identical — small changes, a test that fails first, the right layer, pre-empting the obvious objection, replying to every comment.

Compatibility as a first-class constraint

"Correct per spec" being necessary but not sufficient is the lesson most product engineers find surprising. UseCounter data decides whether a correct change can ship.

Your equivalent: before changing a shared API's behaviour, measure who depends on the current behaviour. Teams that skip this ship correct changes that break consumers, and then learn the lesson expensively. If you own a platform team, the ability to answer "how many callers rely on this?" is worth building before you need it.

Reviewer attention is the scarce resource

Everything about CL hygiene — small, one concern, formatted, tested, with rejected alternatives stated — is optimising someone else's time, not yours. That reframing improves code review inside your company immediately.

The record is the point

Reviewer feedback is the only input you cannot generate yourself: a domain expert telling you what you missed, on your own work, for free. Most engineers fix the code and forget the lesson.

A rejected CL with a clear architectural lesson is a successful lab. Rungs 1–3 are about competence, not merge count.

Next

bi-16 asks you to state honestly which mastery criteria you met — including this one, if the toolchain blocked it.