One trick that I used in a similar situation that was simple and effective worked like this: (imagine a conversation with engineer) Me: Hey, I got a question I

One trick that I used in a similar situation that was simple and effective worked like this: (imagine a conversation with engineer) Me: Hey, I got a question I was hoping you could answer. What do you think is harder, writing code or reading code? Them: That depends who are we talking about? Me: Idk, I mean it sort of generally. Let’s start with which you think is easier/ harder for other people. Them: Probably reading code. Me: like how much harder? Them: Maybe 2-3x harder ———————- Then, next time you have a one on one, or you do like a team meeting bring up this point and say that if reading code is 2-3x harder than writing code, then we should strive for our code style to be within an understandability budget. If we write code at our max intelligence, let’s say one of your team mates has a super 10/10 intelligence, then it requires a 15/10 to understand it and it’s therefore out of budget. I’m an engineer and I’ve used different versions of this argument to great success in convincing people as to the merits of why it’s good to write code that’s intentionally “dumber”. Roadblocks that I’ve had in the past have come down to communication issues, where in one situation in particular a fellow engineer didn’t want to give answers to the question or be pinned down to even rough easier/harder for reading/writing code. In general, engineers like this don’t understand how they’re perceived by others and they can’t understand how their work affects others, and what can you do? I’m not sure, nothing works 100% when it comes to people.