Programmer A writes straightforward code that's easy to change and understand.
Programmer B writes convoluted "clever" code that completely falls apart when requirements change, or even just in production because their clever solution didn't account for all of the edge cases.
Now Programmer B has to save the day consistently, and therefore is seen as the person saving the company, when the problems were all of Programmer B's construction to begin with.
If you are a CTO and you haven’t had the “no more heroes” conversation with your employees, then it is my long reasoned opinion that you are being negligent. I can’t trust “leadership” like that.
And if you don’t take “I can’t trust you” as the highest insult a developer can give, then you are in the wrong line of work.
A lot of teams are a cult of personality around one developer. Particularly if there are a bunch of juniors on the rest of the team, Programmer B can usually get anything through code review with the 'ol "of course it's complicated, that's why _I_ am the one working on it. It's not for mortals to understand".
Treat every question about your code as feedback. If multiple people ask the same question you have a problem that needs to be fixed. Documenting the gotcha should be your last resort. Implying incompetence isn’t even in the board.
Programmer A writes straightforward code that's easy to change and understand.
Programmer B writes convoluted "clever" code that completely falls apart when requirements change, or even just in production because their clever solution didn't account for all of the edge cases.
Now Programmer B has to save the day consistently, and therefore is seen as the person saving the company, when the problems were all of Programmer B's construction to begin with.