> I can't directly speak to any particular work you're describing, but "smart" people don't usually add significant complexity and aren't hard to work with.
I feel that's really unrelated to how "smart" person is. It's more due to experience when you start to appreciate the simplest approaches to solve the problem.
Many people chase some new and cool features and want to use them just because it is more interesting that clapping out boring code day in day out and that's where you get those overly clever blocks of code. I've seen every level of competence fall into it. Hell, I suspect like 3/4 of k8s and related deployment are exactly that, devs bored and wanting to play with new toy.
To build on your comment…I think picking simple or anti-complexity is a values call perhaps enabled by emotional intelligence and being secure in who you are.
I have met many people whose identity is wrapped up in being smart. When faced with choosing a clever solution or an understandable solution they will choose the former. This is where preserving their identity outweighs empathy for you or even for themselves. Some people also like to be the hero. If they are the only ones who get the solution then they are more likely to be the hero to fix it in some future moment of need.
There is a balance too between simply being older and being young and feisty, though. This smacks a bit of old arguments to 'just use assembly' or the like.
It is true there is an overproliferation of reinvention of syntax, but I have seen often older developers claim something is 'easier to read' not because it is actually so but because they are used to a certain cognitive load.
A good example is an aversion or misunderstanding of properties - these were first popularized by flash as3, informally entrenched against by get/set in Java, and finally enjoyed better syntactical support and syntaxes in C#. I have experienced a degree of pushback that properties are 'complex' or unreadable, when in fact the syntax is evolving to create something simpler and more cognitively manageable.
What is easily understood over time also changes, as newer frameworks become popular or more widely taught and understood, so the esoteric becomes widespread and the widespread becomes esoteric.
A good way to manage this tension for experienced yet aging developers and young yet inexperienced I think is two fold - make regular yet conservative pushes for 'modernization', so that there is room for the new concepts to enter without wholesale refactoring being necessary, while still allowing for the codebase to be understood by both new and old. The other is to require new features, styles, to be well documented, both externally and with in source commenting. This pushes even the new developers to consider the cognitive ramifications of the code they are creating, while also making the code clear to those less gifted or less syntactically experienced.
Been writing code for almost 20 years and never found the get/set paradigm useful. I’m fact it’s introduced a lot of incidental complexity when I tried it. Objects and functions to transform objects immutably to the extent possible are much better imo. I don’t use Classes anymore unless they’re static.
Immutability is nice when you have it, however the languages and paradigms you speak of I imagine the OP would also complain are "clever code".
Otherwise it's not a "paradigm", simply having mutable state means you will want to retrieve and modify state on a part of an object/struct/array, in this case the alternative is "plain" getter/setter methods, however these are not guaranteed to even be named the same much less be in a similar area of code. Get/Set properties have two objective advantages that setter methods and raw properties do not. 1. They are always named the same, and thus you can always find them. 2. They are debuggable, where a plain property is not, which is very useful for widely modified properties.
You of course can feel what you like about using them, however I posit them as a fairly neutral example of language evolution where things got objectively better over time, where there are many "stupid", specifically looking at Java, conventions which were/are needlessly enforced for reasons not to do with code clarity at all but rather old people being set in their religious ruts.
There are many, many examples which are much more controversial, but I think it is also illustrative that something as dirt simple as setting or getting a variable can have such illogical and emotional reaction from a wide range of individuals, making up nonsense about how they know the best way of doing things, and claiming things about "young" developers.
I feel that's really unrelated to how "smart" person is. It's more due to experience when you start to appreciate the simplest approaches to solve the problem.
Many people chase some new and cool features and want to use them just because it is more interesting that clapping out boring code day in day out and that's where you get those overly clever blocks of code. I've seen every level of competence fall into it. Hell, I suspect like 3/4 of k8s and related deployment are exactly that, devs bored and wanting to play with new toy.