The thesis being argued here isn't supported by the poor anecdata. > Every time one of us would post our code for review, he would slaughter it. Where a normal

The thesis being argued here isn't supported by the poor anecdata. > Every time one of us would post our code for review, he would slaughter it. Where a normal review would often contain a handful of comments and suggestions, he would regularly end up in the hundreds. Most of the comments were opinion and personal preference. He had good reasons, and he was more often right than not, but he never even tried to be kind. He never took the opportunity to teach or mentor. He just stated his opinions as fact. > [...] At first the rest of us tried to have constructive conversations, then we often just gave in, then I realized that we were actively avoiding him altogether and skirting our process. [...] He was so good. Was it worth even arguing or talking to our manager about him? Surely if we just put up with his attitude, we’d accomplish more because of the sheer volume of his contributions. The solution here is indeed to talk to the manager. A brilliant jerk with strongly held opinions about code should be pretty easily convinced based on efficiency grounds. Repeatedly leaving hundreds of detailed review comments is not a good use of time, while writing up something that could be referred to that explains the reasons for the coding standards would prevent such comments from needing to be made in the first place (and could be used by others to distinguish stylistic preferences and opinions from truly necessary standards). Repeatedly having the same "constructive conversations" is an even worse use of time. While I'd question the "brilliance" of somebody stating "opinion as fact", someone leaving hundreds of comments in a code review clearly cares and thus can be reached by an argument grounded in the things he cares about.