[SassyGrapefruit]

When I read your postI can't help but read smart as "smart". You vacillate between holding their intelligence in esteem "but eventually I came to understand that he is so good at reading code..." and condescending "... I can only describe as being a little too smart for their own good"

Now the real question is do you believe you are right? Do you really(and I mean really deep down) think these people are smart. Do you think you have a better way? Do you wish they'd realize that what you are doing is best path forward?

I have seen this sort of conversation pattern in the past. In my case it was a younger programmer that wanted the team to take a different approach, but at the same time were struggling with the "what if I'm wrong?" dilemma. They didn't want to throw their weight behind a proposed change in direction because of insecurities and fear of rejection. What it came across as to the rest of the team was a person that didn't want to lead but at the same time was always finding fault. When confronted they would say things like "I'm not one of the smart ones ..."

If you really are not smart as they are then trust them and learn from them. If you think you have a better path and are committed then stand up and say "This is wrong and here is a better way". If you are right and they reject you then maybe its not the place. If they are able to demonstrate that you are wrong you should accept it and move on. If you are right and they agree then you are in the promised land.

[nullsense]

I think one of the key tensions in this kind of scenario is individuals combination of traits massively influence the way they view the code and they're generally blind as to what the world looks like to engineers with a different combination of traits.

Just because someone has a higher IQ doesn't make them objectively better on all measures. It usually does mean they have cognitive access to things that others do not, and this can be beneficial as well as detrimental. It's seriously beneficial when they are able to come up with a simpler, more elegant solution when the rest of the team can't where that solution ratchets down the level of complexity and/or the cognitive load on the team. It's seriously detrimental when they propose solutions that do the opposite simply because they can conceive of it and it solves some problem they think exists and/or that needs solving and ratchets up complexity and increases cognitive load.

I like the example of the engineer arguing for less whitespace because he personally doesn't need it where others do, but he's unable to see the effects it would have on other people were it to be removed and how in aggregate that would likely result in a worse outcome.

There's an engineer that I work with occasionally who is like this. He loves complexity and absolutely thrives on it. It's like oxygen to him. He's very smart. He's also a 20+ year veteran, 10+ of which is with the current company. There are things which I know he is uniquely capable of producing, and in such a scenario I want what he would produce as it would be significantly better than what almost anyone else would do. However, 99 times out of 100 I want what almost anyone else would produce than what he would, as he optimizes only for himself and not the wider team. We have an upcoming overhaul of a legacy system that were both chomping at the bit to get stuck into, and I've been told to "get in line", but I'm not just going to lie down and take an attitude like that when I know what the result might be. Needless to say I think it will require being both firm and diplomatic.