Person A, a programmer, who writes easy-to-understand code, but takes a bit more time to finish their tasks
Person B, a programmer, who writes dirty code, but takes much less time to finish their tasks
The current non-technical manager will see only one part of the picture and promote Person B. Moreover, Person A might get in trouble, and pressure to “compromise on quality.”
Within a short-term, it is understandable.
Within a long-term, this is a disaster scenario!
So should the “code quality” be part of a performance portfolio of the developer when it gets to promotion time? And how do we get there?
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.
Person A, a programmer, who writes easy-to-understand code, but takes a bit more time to finish their tasks
Person B, a programmer, who writes dirty code, but takes much less time to finish their tasks
The current non-technical manager will see only one part of the picture and promote Person B. Moreover, Person A might get in trouble, and pressure to “compromise on quality.”
Within a short-term, it is understandable.
Within a long-term, this is a disaster scenario!
So should the “code quality” be part of a performance portfolio of the developer when it gets to promotion time? And how do we get there?