Yes, very true. One has to prove their point of view. It's easier when the engineer in question has proven themselves in the org (I would say industry, but when

Yes, very true. One has to prove their point of view. It's easier when the engineer in question has proven themselves in the org (I would say industry, but when you arrive at a shop, you generally need to start over.) I should have made the distinction between "senior in years" vs "senior via software admired by peers". Since code is skewed heavily to the left of "read:write", the primary issues that formatting should address are [1] muscular eye fatigue induced by "formatting" or non-formatting that leads to excessive eye saccades (i.e. eyes "jumping" from point to point, or obliquely) [2] formatting that obscures logic leading to cognitive fatigue. Another thought experiment I've used is: Imagine that you replaced [A-Za-z0-9] with squares and made it black and white. Leave the language's keywords alone. Does the shape of the code suggest the logic and flow? etc. That's more in the zone of cognitive load. That's why it's an art and craft, to me. My thinking is also colored by smaller shops, since a stint as a cog in some large orgs burned up my soul. And yes, I've been in a few dumb fights ;)