[ctrwu2843]

I've worked with these super-smart idiot savant type engineers before and often butted heads over stuff, and later in my career lead teams that have those archetypes.

A few things I think - one is stress that they might be clever enough to understand and manage that kind of complexity, but you personally aren't, and would prefer styles, solutions and techniques that are comprehend able by mere mortals such as yourself. This is hard if not impossible to argue with. After all, you need to be able to understand it, because if they leave or are unavailable the maintenance burden will be on you / the rest of the team.

But the flip side is these people are usually very good problem solvers and prolific, so the more you can harness that, the happier everyone will be.

Some of my regrets include stalling a PR for being overly complex, resulting in it not getting merged and deployed for months, when the code would have saved 10k/month in server costs. When I tried to re-write it myself to be simpler I failed, so it was arguably necessary complexity. With that said the team that took the code after us, removed the feature entirely as it was a complicated mess - that was probably the sensible but outside the box solution.

Another one was early in my career working with a senior who liked short/scope relative names. I thought it was bad naming at the time, but now I realise that if you do it properly, the shortness itself can be semantic.

The biggie for me is tests, many people dislike writing them, and occasionally the smarter guys can get away without them, more so than the average. But long term, this creates a nightmare because the team will lose confidence when making changes. Convincing people to write more tests is difficult and I haven't worked out a great way to emphasise why it's necessary.