> But the overall system becomes a little more brittle, and a little harder to reason about
> minimize the amount of brainpower I needed to understand my code
> weighing it against the larger system.
If you haven't try converting these items into something more measurable, and put these problems in front of the smart engineer and let these be their problem?
Sort of delegating these stuffs as their problem too instead of taking it all your own.
I might have picked the wrong word "measurable". It's better to stay away from ultra-narrow measurement. "When a measure becomes a target, it ceases to be a good measure" Instead, put the phenomenon in their head. Make it their responsibility. Point out the impact of readability to the team velocity.
Or maybe, examine if the introduced complexity is actually incidental and not essential. IF it is essential, it makes more sense to upskill the rest of the team. Hold sharing session to hear everyone's thought. Hear what the smart guy thought about the code. Sometimes, what someone need to unlock a heap of more horse power forever is just a little nudge that makes them click. Create team conventions for making things easier for everyone, e.g. indirection through naming in which you need to pay a bit in performance.
> minimize the amount of brainpower I needed to understand my code
> weighing it against the larger system.
If you haven't try converting these items into something more measurable, and put these problems in front of the smart engineer and let these be their problem?
Sort of delegating these stuffs as their problem too instead of taking it all your own.