Absolutely. The article acknowledges this. Jane Street is pretty uniquely equipped to benefit from this.

1. Scoping. I give juniors projects that are big enough to be valuable, but not so big that they get lost.

2. Instruction. I give juniors frequent, bite-sized lessons related to their tasks. In this, I invest in their skills.

3. Linting. Anything that could be considered a “nit” in a code review is relegated to machine lints. For example, I will never talk about formatting in a code review. That is solved by tooling.

This article makes me wonder if there’s some sort of machine-readable lint for costly abstraction? In a TS project, is there some way to say, “the shadow DOM under this component is too deep.” Or “this object’s inheritance tree is too long.”

Or for zero/cost abstraction languages, is it feasible/productive to lint “this packages dependency tree is too deep”?

How do you identify abstractions that are too leaky to be helpful?