Thanks for sharing - I disagree with the approach, but understand it. Or rather, I feel that can work for individual coding, or possibly very small teams - but

Thanks for sharing - I disagree with the approach, but understand it. Or rather, I feel that can work for individual coding, or possibly very small teams - but in the end I feel it usually works out to be unintentionally anti-team behavior. It trades off "I need to learn and understand this black box of behavior for instead I have this code that I know and can easily reason about". While for the entire rest of your team it went from "there is this common pattern that most of all 20 (or however many) of us know - and instead makes it 19 of us now need to learn this non-standard behavior/implementation, but at least one person knows well." Essentially everyone else has to learn more code, so that one person doesn't. Agreed it's usually not the most complex of code, but it's usually buggier and shifts to cost / burden to everyone else. The opposite of economies of scale and leveraging prior fixed costs of learning. But again, I don't know your situation and will readily admit my opinion above doesn't in anyway make it factually a better approach. Just my opinion on it same as yours.