I supervise the contributions that juniors make to our codebase. To do this effectively, I use three tools:
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?
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?