4 ms·
One man's "readable code" is another person's trash. As the number of commiters in a codebase increases, the chances that you find at least one person's code to
by Daishiman 5y ago
One man's "readable code" is another person's trash. As the number of commiters in a codebase increases, the chances that you find at least one person's code to be an irritating annoyance increases exponentially.
The only way to avoid it is to have the political power to call out the team member that's annoying. Easy enough to do if you're the lead and nobody will question your decisions.
The worst and dumbest fights I've encountered is with people with 30 years of experience who have diametrically opposed opinions. I _especially_ despise having to call out very senior engineers when their own code misbehaves.
- altgeek 5y agoYes, 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 ;)