Standardising how teams assemble configuration, you require the weakest of mapping, combining and chaining that expresses each step — what does that buy, and where does the rule cost more than it returns?
answer
- least power that expresses the step
- the rung is a dependency claim
- independence is what chaining cannot say
- derived combining is still sequential
- enforcement is review, not the compiler
basics
~20 sRequiring the weakest sufficient rung keeps real dependencies visible: a combining step advertises that neither load needs the other, so it may be evaluated in any order and both results stay reachable. It costs review effort, and it stops paying when the work is genuinely sequential.
solid answer
~50 sThe rung a step uses is a claim about dependency that every later reader will act on. Chaining says *this step needed the previous value*; combining says it did not; mapping says no new context is produced at all. Requiring the weakest rung that expresses the step therefore turns the pipeline into its own dependency graph, keeps the freedom to evaluate independent loads in any order, and stops one missing setting from hiding every other. The costs are real: it is a review-time judgment rather than a compiler check, it adds vocabulary a new engineer must learn, and it returns nothing on a path where each step genuinely consumes the previous value. It also promises less than it appears to when the context derives its combining operation from chaining, because the derived version is sequential anyway.
go deeper
Recall the test the rule is built on: use the plain-function operation unless the step needs a context, and reach for the dependent one only when it needs the previous value.
Explain why the choice is observable rather than cosmetic — the stronger operation fixes an evaluation order and stops later steps once an earlier one is empty.
Argue the rule against a real assembly path, naming which settings are independent, what an unnecessary chain cost during a misconfiguration, and how you would enforce the convention in review.
Own the trade-off explicitly: state what the standard promises, what it cannot promise on a context whose combining is derived, and the conditions under which you would not impose it at all.
## What the rule actually says The rule is one sentence: **express each step with the least powerful of the three operations that can express it.** Mapping if the step is a plain function of a value. Combining if the step needs several contexts but none of their results. Chaining only if the step's input is the previous step's output. It is a convention about expressiveness, not about performance, and it applies wherever contexts are assembled — most visibly where one application configuration object is built from several independently loaded settings. ## What it buys - **A readable dependency graph.** A reviewer can see, without opening any step, which settings are genuinely sequential. Chained steps are the graph's edges; combined steps are its independent leaves. - **Preserved freedom.** Independent contexts may be evaluated in either order, or at the same time, because nothing in the expression demands otherwise. The rule keeps that freedom available instead of spending it by accident. - **Reachable information.** When two loads are combined, a missing first setting does not prevent the second from being examined. When they are chained, the second one never happens, and a person debugging a misconfiguration is told about one problem per run. - **A cheaper review question.** "Does this step use the value it was handed?" is a question anyone can answer by looking, which makes the rule enforceable rather than aspirational. ## What it costs 1. **It is a judgment, not a gate.** No type checker rejects an unnecessary chain, because an unnecessary chain is perfectly well typed. Enforcement lives in review, and review attention is the scarcest thing a platform team spends. 2. **It widens the vocabulary.** Three operations with three shapes is more to learn than one, and the weakest-rung rule asks every engineer to choose deliberately every time instead of reaching for the familiar one. 3. **It can be argued about.** Whether a step "really" needs the previous value is occasionally a design question in disguise, and the rule turns that into a review conversation. ## Where it stops paying The rule is worth its cost in proportion to how many steps are genuinely independent. Two places where that ratio collapses: - **Genuinely sequential work.** A path where each read is keyed by the previous read's result is a chain by nature. Applying the rule there produces chaining everywhere, which is what a team would have written anyway, so the rule contributes only ceremony. - **A context whose combining operation is derived.** Any context supporting chaining also supports a derived combining operation, built by chaining and then mapping. The derived version inherits the fixed order and the short-circuit. So on such a context the rule still buys the readable claim of independence, but not the order freedom — and a standard that was sold on concurrency will be judged on a promise it cannot keep. | what the rule promises | delivered when the context defines combining itself | delivered when combining is derived from chaining | |---|---|---| | dependencies visible in the code | yes | yes | | evaluation order left free | yes | no, the derived form is sequential | | both contexts reachable after one is empty | yes | no, the chain short-circuits | ## How to make it enforceable A standard that lives only in a document decays. Three things make this one stick: - **Write the check as a signature question.** A step returning a plain value must be mapped; only a step returning a context may be chained. That is mechanical enough to be a review checklist item. - **Flag the tell.** A chained step whose function ignores the value it was handed is a dependency claimed but not used — the exact shape of the violation, and one a tool can look for. - **State what the standard does not promise.** If the shared context derives its combining operation, say so in the standard, so no team designs around concurrency that will not happen. ## The judgment a lead actually owns The decision is not "which rung is better" — it is whether a codebase-wide convention about expressiveness is worth its enforcement cost *here*. In a system where configuration is assembled from many independent sources and misconfiguration is diagnosed by people who did not write the code, the readable dependency graph pays for itself quickly. In a small service with a short, inherently sequential startup path, the same rule is overhead with a rationale. Deciding which of those you have, and being willing to say the rule does not apply to the other, is the whole of the call.
- How would you make the rule checkable rather than a matter of reviewer taste?Reduce it to a signature question: a step returning a plain value must be mapped, and only a step returning a context may be chained. The mechanical violation to look for is a chained step whose function never uses the value it was handed — a dependency claimed but not used, which tooling can flag.
- When does the rule stop earning its cost?When nearly every step genuinely consumes the previous step's value, so the weakest sufficient rung is chaining everywhere and the rule adds only vocabulary. Also when the shared context derives combining from chaining: the derived operation is sequential, so the order freedom the standard was sold on is never delivered.
saying these in an interview costs you the question
- Argues the strongest rung everywhere is simpler because it is one rule
- Promises concurrency the context's combining operation cannot provide
- Treats the rule as style with no observable consequence
- Applies the rule to steps that genuinely need the previous value
- Assumes a weaker rung is automatically cheaper at run time