how do I deal with a talented, but difficult & overly-critical coworker?

manpreet Best Answer 2 years ago

I'm having some trouble dealing with a talented, but difficult & overly-critical coworker, and could really use some advice.

I have worked with -- lets call him "John" -- for a little over a year on a very small engineering team. He joined the team about a half year prior to me.

John is one of the most intelligent engineers I have ever met, and has very strong technical skills, however socially he can be quite abrasive and blunt/rude -- not only to me, but to other employees as well. I know this is the case because I have witnessed it, and my manager has even discussed with me John's abrassiveness in the past, telling me that John is "working on it".

In contrast, I am not nearly as skillful or quick of an engineer as John, however (at the expense of tooting my own horn) feel I have great soft skills, and always try to create a supportive and positive environment for myself and my coworkers. I like being around people who are happy and supportive of one another while we make cool things.

One point of contention between us is that John comes from a very strong CS background, with a heavy understanding of algorithms and the complete stack. I'm on the opposite end, from a mostly-design background, and my undergrad, while programming-focused, was comparable to a 4 year web-dev bootcamp. More broad than deep. We're both working together on a handful of fairly complex web applications.

Most of John's abrasiveness comes in the form of bluntness, snide, or dismissiveness. because he understands a particular problem, whether that be algorithm or api or what-have-you, he acts like it should be easy/trivial for everyone. He is very critical during my code reviews, and while not pointing out stylistic differences (we have that covered with linter rules), he just nitpicks the crap out of my work. All the way down to the point on micro-optimizations of extreme edgecases that are just not relevant for the web app we are building.

Conversely, if I try to critique his code with the same granularity, he writes my comments off as "unnecessary", "pre-mature optiizations" or some other handy-wavy "I know more than you" type comment.

I've tried for a long time to not let this bother me, but it is. We recently hired a third engineer to our team (lets call him Mike), who is equally as sharp as John, but fortunately not as abrasive. But now I feel like the odd one out. The two are/were friends prior to Mike joining, and both are way more lenient on each others code reviews than on mine. Frankly I feel like im being picked on, these two guys are friends and are way harsher on my work than each others. They will contradict me in meetings with our manager/other departments, and make me look bad, but never do it to each other. They will implement features and practices without consulting me, that I don't understand as they are more hardcore about CS, and that makes me feel more confused with the product.

I know im a good engineer because all my performance reviews are glowing, but my coworkers are really turning this from something that excited me in the mornings into something I dread.

What can I do to restore some equality and balance to my team?

manpreet 2 years ago

First of all I want to recommend against psychoanalyzing John, I.E. you shouldn't assume things like that this behavior comes from a place of insecurity on his part or otherwise try to deduce the root of why he is acting the way he is. This isn't particularly productive and your focus should be on how you should respond and not on what he is doing wrong or why (I am mainly addressing other answers here).

That said, if you are truly confident that you are a good engineer then you should incorporate this confidence into your interactions with John. Regarding your code review: you should make sure that your code is entirely up to the highest standard that you can achieve. Then, when he nitpicks your code, it will either be the case that a) you have a justification for why the code is the way it is, or b) you don't have a justification in which case you should consider his advice in accordance with how good you think his recommendations are.

If the former case is true (you do have a justification for your code being the way it is) you should make your case and defend yourself with the confidence that your way of doing it is right. You don't have to accept his answer just because he has more experience with the specific technology / software / etc. you are working with; you only have to (or rather should be expected to) accept his answer if he is correct in his assessment and you genuinely can't reason why it should be done your way better than he can.

Lets say he rejects your merge request for some truly inconsequential and utterly nitpicky reason. Something like "you should use periods in your comments rather than colons." An engineer's time is extremely valuable, especially for a good engineer as you are confident you are. You shouldn't be expected to have to devote time to such an insignificant change just because he likes it better that way even though it doesn't add any value to the project if it is one way over the other. You should, then, voice this concern with him. Assuming he is not a completely disagreeable person, it will register with him that he probably shouldn't waste your time with such nitpicks.

The same logic in the context of meetings. If he calls you out for something, defend yourself. Don't sound too desperate, as though it is very important to you that you be perceived positively, but rather just make it clear that a criticism was openly made of one of your design decisions and that you thus feel it necessary to defend that design decision. Don't ever go on the attack, e.g. by trying to knock him down a peg like he seems to do to you. Even if you could reliably identify a potential means of doing this it could still backfire on you if he defends his decisions with confidence. Instead make sure all of your work is in order and that you are prepared to defend your decisions.

The bottom line here is to a) have confidence, and b) project confidence. This is actually a rather challenging endeavor that takes a lot of practice, and so it is far easier said than done, but you should work on it a little every day. In cases where you fail - perhaps he calls you out in a meeting and you fail to defend yourself - do a sort of after action report and ask yourself how you could have defended yourself or how you could have better prepared yourself for having had to defend yourself, etc.