[bsvalley]

It's not just about "you should code like that because that's how we code here" type of problems. That makes you, the arrogant person in the story. You should create a list of bugs generated by his code. If the list is significant AND if you believe these bugs could be avoided by incorporating %100 of your code review feedback, then setup a 1-1 quality meeting with him and go over the list. Tell him how this could be avoided in the future and that the goal is to stay away from bugs and to focus on fun things. Don't use "you should", use "we should", act like it's a team effort.

If he doesn't accept your invite, or doesn't want to cooperate during this meeting, resend an invite and include your manager and QA and all the other engineers. Update your list of bugs and add bugs from the whole team not only his bugs. Then make it a real team exercise. The problem will raise during this meeting and everyone will clearly see that this dude is a bug-generator.

It is a long process, but that's how you do it professionally. What do you earn from this big effort? People will thank you for taking initiatives and to raise the bar in terms of quality. In other words, you'll get a bonus ;) He will regret not listening to you when he had a chance to fix his mess "secretly".

[dlubarov]

IMO you shouldn't try to prove that his code is bad and the feedback is good. Even if his code is perfect and the feedback is bad, he should still respond to the feedback with a justification for his approach. If his way is really better, then he can educate his peers about it.

[fnbr]

Also, "you should code like that because that's how we code here" isn't a good reason. If you don't have a good rationale for the changes, I would consider not making them.

[wallstprog]

On the contrary, that is a very good reason, and sometimes the only one that matters.

In any group of "n" developers there are likely to be "n+m" different ways to do the same thing. This increases the "cognitive load" to understand others' code (a fancy way of saying it makes the code hard to understand).

Personal preference is not a valid reason to eschew standards, even (especially) de-facto ones.

If there is a "better" way to accomplish a particular task, then the entire team should adopt it (and go back and change existing code to conform to the "better" approach). If that's not worth doing, then leave well-enough alone. (Another way of saying "If it ain't broke, don't fix it").

[mbrameld]

Right, but simply saying, "that's the way we do it here" doesn't communicate all that. Hence, "that's the way we do it here" is not a good reason. "That's the way we do it here, and here is why we do it like that..." is how it should be phrased.

[wallstprog]

Agreed -- if you can't explain why "that's the way we do it here", then that's a problem.