Maintaining systems is a balancing act. Your take seems kind of at the conservative end of the spectrum. Whether a certain degree of complexity is 'unnecessary' is so subjective and based on values and experience. You might be able to learn a bit by being more flexible. It's easy to get into a habit of avoiding changing a system because of it's complexity because there are definitely benefits to doing that, but at some point the business starts to see that system as a problem if they can't make improvements and add features at the rate they'd like.
To me the whitespace/code style issue is separate. Personally I think there are more benefits to letting people make these choices according to their own preferences rather than trying to come up with some consensus and then enforce it.
> Your take seems kind of at the conservative end of the spectrum.
Nah. Their take is from an engineering standpoint. The type of brilliant people they're talking about can reason about terrible code, but most software engineers aren't like that, and it doesn't make sense for these brilliant people to ignore good engineering practices because no company can afford to hire only geniuses.
> Personally I think there are more benefits to letting people make these choices according to their own preferences rather than trying to come up with some consensus and then enforce it.
Having various styles of code on the same codebase is inefficient. Most styles are chosen arbitrarily (e.g. where to put opening braces in C) and you should follow whatever style the codebase uses. Once you push code to a repo it is no longer yours. There is no engineering value in mixing in your own preferred style.
I respectfully disagree with you on the whitespace/code style issue. In most teams, you are writing code first and foremost for the compiler. It has to work. Once that hurdle is cleared the next most important audience is people who will be working with the code in the future. You write it once but maintain it forever. You're job is to make that as easy as possible and following a style used by the entire group makes that easier. Insisting on doing things your way is selfish.
I don't disagree with any of these points. Where I disagree is that style differences make code less understandable or more difficult for others to work with to any meaningful degree. To me, it's roughly equivalent to stylistic differences in how people choose to communicate in written form. I'd genuinely be surprised if someone has more difficulty understanding code because a brace is on a line all by itself or not. I'd not be surprised to hear they have a preference or that they're annoyed to work with code that is not in their preferred style.
To me the whitespace/code style issue is separate. Personally I think there are more benefits to letting people make these choices according to their own preferences rather than trying to come up with some consensus and then enforce it.