The answer is kinda mean, but... everything's lining up on the "go all out on enforcement" boat, as much as I hate to look at it that way.

I mean, you've said:

• He "produces low-quality code" (even apart from style differences)
• The things you've already let slide have cost your other developers unneeded time.
• He's "very inexperienced".
• He's opinionated and not receptive to changing.

The reason I point these things out is... what if you suddenly just said, "You know what? This guy doesn't get to move any of their code to production until the code completely conforms to our standards."

It's not like the developer is churning out loads of amazingly productive code and that your standards would be seen as frivolous and holding back the company's bottom line. It's not like the developer is receptive to non-forced change, and that this issue goes away after another several months. It's not like the developer is putting out code that doesn't cost your other developer's unnecessary maintenance time due to standards deviations.

... and as sad as it is? It's not like the developer is an extremely valuable asset to the company. That's just what happens when you combine "Inexperienced Junior" with "Unwilling to Learn or Change".

Because of all this, your best bet is probably just draw a line and say, "You don't get to promote code unless it completely conforms to the standards. Period. You'll need to either start following standards when you compose your code, or start budgeting time to rewrite it before you can get it put into production." And don't let anything slip.

The dev's likely going to hate that. Maybe they'll end up improving and writing quality code. Maybe they won't. But... that's the saddest part of it. An inexperienced junior that refuses to learn or change deciding to leave your group isn't all that terrible of an outcome.

EDIT: Oh, something else I forgot to add: they're a "very inexperienced" junior. While I'm definitely not going to say, "Never listen to the junior because they won't have anything to contribute", there's nothing wrong with saying, "Listen, I know a lot more about this, and I'm telling you: this is the way our group operates, and this is what the standard is. You need to change your code to match," and then moving on to the next issue on the code review.

The answer is kinda mean, but... everything's lining up on the "go all out on enforcement" boat, as much as I hate to look at it that way.

I mean, you've said:

• He "produces low-quality code" (even apart from style differences)
• The things you've already let slide have cost your other developers unneeded time.
• He's "very inexperienced".
• He's opinionated and not receptive to changing.

The reason I point these things out is... what if you suddenly just said, "You know what? This guy doesn't get to move any of their code to production until the code completely conforms to our standards."

It's not like the developer is churning out loads of amazingly productive code and that your standards would be seen as niggling and holding back the company's bottom line. It's not like the developer is receptive to non-forced change, and that this issue goes away after another several months. It's not like the developer is putting out code that doesn't cost your other developer's unnecessary maintenance time due to standards deviations.

... and as sad as it is? It's not like the developer is an extremely valuable asset to the company. That's just what happens when you combine "Inexperienced Junior" with "Unwilling to Learn or Change".

Because of all this, your best bet is probably just draw a line and say, "You don't get to promote code unless it completely conforms to the standards. Period. You'll need to either start following standards when you compose your code, or start budgeting time to rewrite it before you can get it put into production." And don't let anything slip.

The dev's likely going to hate that. Maybe they'll end up improving and writing quality code. Maybe they won't. But... that's the saddest part of it. An inexperienced junior that refuses to learn or change deciding to leave your group isn't all that terrible of an outcome.

EDIT: Oh, something else I forgot to add: they're a "very inexperienced" junior. While I'm definitely not going to say, "Never listen to the junior because they won't have anything to contribute", there's nothing wrong with saying, "Listen, I know a lot more about this, and I'm telling you: this is the way our group operates, and this is what the standard is. You need to change your code to match," and then moving on to the next issue on the code review.

The answer is kinda mean, but... everything's lining up on the "go all out on enforcement" boat, as much as I hate to look at it that way.

I mean, you've said:

• He "produces low-quality code" (even apart from style differences)
• The things you've already let slide have cost your other developers unneeded time.
• He's "very inexperienced".
• He's opinionated and not receptive to changing.

The reason I point these things out is... what if you suddenly just said, "You know what? This guy doesn't get to move any of their code to production until the code completely conforms to our standards."

It's not like the developer is churning out loads of amazingly productive code and that your standards would be seen as niggling and holding back the company's bottom line. It's not like the developer is receptive to non-forced change, and that this issue goes away after another several months. It's not like the developer is putting out code that doesn't cost your other developer's unnecessary maintenance time due to standards deviations.

... and as sad as it is? It's not like the developer is an extremely valuable asset to the company. That's just what happens when you combine "Inexperienced Junior" with "Unwilling to Learn or Change".

Because of all this, your best bet is probably just draw a line and say, "You don't get to promote code unless it completely conforms to the standards. Period. You'll need to either start following standards when you compose your code, or start budgeting time to rewrite it before you can get it put into production." And don't let anything slip.

The dev's likely going to hate that. Maybe they'll end up improving and writing quality code. Maybe they won't. But... that's the saddest part of it. An inexperienced junior that refuses to learn or change deciding to leave your group isn't all that terrible of an outcome.

EDIT: Oh, something else I forgot to add: they're a "very inexperienced" junior. While I'm definitely not going to say, "Never listen to the junior because they won't have anything to contribute", there's nothing wrong with saying, "Listen, I know a lot more about this, and I'm telling you: this is the way our group operates, and this is what the standard is. You need to change your code to match," and then moving on to the next issue on the code review.

The answer is kinda mean, but... everything's lining up on the "go all out on enforcement" boat, as much as I hate to look at it that way.

I mean, you've said:

• He "produces low-quality code" (even apart from style differences)
• The things you've already let slide have cost your other developers unneeded time.
• He's "very inexperienced".
• He's opinionated and not receptive to changing.

The reason I point these things out is... what if you suddenly just said, "You know what? This guy doesn't get to move any of their code to production until the code completely conforms to our standards."

It's not like the developer is churning out loads of amazingly productive code and that your standards would be seen as frivolous and holding back the company's bottom line. It's not like the developer is receptive to non-forced change, and that this issue goes away after another several months. It's not like the developer is putting out code that doesn't cost your other developer's unnecessary maintenance time due to standards deviations.

... and as sad as it is? It's not like the developer is an extremely valuable asset to the company. That's just what happens when you combine "Inexperienced Junior" with "Unwilling to Learn or Change".

Because of all this, your best bet is probably just draw a line and say, "You don't get to promote code unless it completely conforms to the standards. Period. You'll need to either start following standards when you compose your code, or start budgeting time to rewrite it before you can get it put into production." And don't let anything slip.

The dev's likely going to hate that. Maybe they'll end up improving and writing quality code. Maybe they won't. But... that's the saddest part of it. An inexperienced junior that refuses to learn or change deciding to leave your group isn't all that terrible of an outcome.

EDIT: Oh, something else I forgot to add: they're a "very inexperienced" junior. While I'm definitely not going to say, "Never listen to the junior because they won't have anything to contribute", there's nothing wrong with saying, "Listen, I know a lot more about this, and I'm telling you: this is the way our group operates, and this is what the standard is. You need to change your code to match," and then moving on to the next issue on the code review.