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

Question

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?

Answer 1

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.

Answer 2

I am going to post a different view on this. What your reviewer is doing could also be considered "tough love". Have you considered using the reviews to improve your skills? I realize this is not easy, but getting to the point behind the critiques will likely teach you quite a lot. That doesn't mean simply doing what is put in front of you, but asking for reasons behind the comments, and following that logic to see where it goes.

Once you're able to discuss the points of the review at a similar level, I would expect reviews to become more lenient, like for his friend - if my take on this is correct, John is not critiquing his friends work as harshly because John knows the lessons he is trying to get across have already been learned.

While snide remarks and sarcasm are not helping, and definitely something John needs to work on, I would advise not to pass up this opportunity. I've been in similar situations, and managed to come out with a better understanding because of it.

If John still ends up being a smart a**, that's him losing the opportunity to better himself, but I think you should take away from this what you can.

Answer 3

I know you haven't said much about your side of the interactions, but that might be a crucial element. You've said you praise when they've done good stuff, and mentioned that you've tried assessing his code the way he does yours, but there isn't a great deal of info on how you deal with him the rest of the time. You've admitted you're not the same style of programmer he is, so going toe to toe in code reviews isn't going to be your best strategy. By doing this, you're just confirming his superiority. Similarly, you've said your co workers slate you in meetings but it's not clear how you respond. It sounds like he doesn't have a great deal of respect for what you do bring to the table- possibly because he doesn't realise what that is (some people only recognise talent when it mirrors what they do!). I'd suggest starting to bounce stuff back at him a little, with your perspective. For example, if he is overly critical of a piece of work unnecessarily, go back and say 'thanks for your input, but for this project I don't think that X is as important as y. Can you explain why you feel this is so important?' If you keep things polite but firm and push back in a way that makes it clear you're not just doing stuff that he thinks is wrong, but are doing it for specific reasons, he might start to realise that actually, although you don't work the same as him, you do have skills.

Similarly, I think it's probably important to start politely disagreeing in meetings when he pulls you apart. Something like 'I'm sorry you disagree with that method/how I've done that, but the functionality that we wanted is present' or similar means that he'll come across as overly pedantic, rather than you incompetent. If he pushes further, you can always say something like 'that's an interesting method. If you feel it's essential to implement that, could you show me why it's superior when we redo the code?'.

It might also be worth having a chat with Mike about the meetings. Something along the lines of 'hey, I've noticed you seem to be a lot harsher on my work than John's. Is it because you have similar working styles, or is it something about my work in particular?'. You should do it in person, at a fairly informal time- water cooler, drinks after work etc, and make it conversational rather than accusatory. He might be just trying to fit in with his friend and not realised how much it's affecting you, or could possibly give you some concrete advice in a less active way than John would. It might also break the dynamic of being ganged up on if he has to justify their behaviour.

Finally, if nothing changes, the management is aware John's abrasive but are doing little about it, it's making you miserable and your performance reviews are glowing, it might be time to look around discreetly for something else. You know you're good, you just need to be in a better team- see what else is out there!

Answer 4

The fact that John has some distinct strengths in his skills and chooses to "punch down" on your weaknesses and even use sarcasm against you, points very strongly to two possibilities and maybe a 3rd:

1. John is replicating the behavior of mentors in his past. Many people get treated to "trial-by-fire" at some point in their careers and end up feeling that this is the way to behave when the tables are turned and they're in any position of authority. John himself might call this "tough love" (see @bytepusher's answer). It's very far from love, but that's how people often think.

2. John is insecure and this is a defense mechanism. As @millimoose indicated in his comment, whether or not he has reason to be insecure is beside the point. Emotions drive such behavior. It is childish and wrong, but a way to deal with feelings of inadequacy within oneself is to make another person feel even MORE inadequate. Acting smug and dismissive is a common way of compensating for insecurity of status in the organization or even lack of self-confidence.

3. It could just be that John is "an asshole." I think that is the least likely possibility.

Unless things become intractable, I would refrain from taking this to management. John will likely put on an "objective" demeanor and try to weasel past accountability and point to you as the problem. He will then become even more malignant to you.

The best way to deal with this, regardless of possibilities 1, 2 or 3, is to somehow get John on your side by gaining his trust. You do this by building rapport and showing your human side. To do this it is really important to maximize face-to-face time with John. Interaction by email, pull-requests, or code-reviews are not a good way to build trust. You can't tell John in a code review in front of everyone, "Hey, I didn't appreciate that sarcasm!" You can pull him aside at the water-cooler and ask "I detected some sarcasm in your remark earlier, that hurt, what's going on man?" It will lead to difficult conversations, but there is a good chance to make progress if John knows he won't "lose face" by interacting with you.

You might try to praise John's work in areas where he demonstrates expertise and good behavior. Try to defer to him when you can as a way to show that you're not trying to edge-in on his work. It sounds kind of ridiculous, but lots of adults lack the ability to understand how they're being perceived by others, it's a mild developmental defect-- to some extent you (and other people-savvy folks) need to use strategies similar to what you might use on a child or petulant teen.

Answer 5

I don't think the problem is what you say it is.

" 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 would go nuts if someone contradicted me in meetings with a manager/other person. It would be both professionally and personally insulting. I suspect that is the real issue you're facing, rather than boring code reviews.

To that end, you need to escalate to your manager. Tell him/her that when John does this it negatively impacts how you feel about working in the team, your motivation and rattles your self-confidence. Ask him/her for help, because you're not enjoying the workplace.

Ok, so now that that is getting paid attention to, you want to deal with the code reviews.

Are your code reviews in person? And if so, why? Seems like a titanic waste of time - just do them in everyone's spare time online using fisheye or crucible or whatever it's called.

The best thing about this is that you can just ignore people's comments. And you don't have to spend an hour all together looking at code minutia.

But the real issue seems to be the knowledge disadvantage you're at, compared to your coworkers. I'd suggest that, in place of the meeting time that you have to do code reviews, you do knowledge sharing. Don't worry, there's always compiling time to check other people's code.

Ask them to go through their code with you - go into a room, and get them going over it with you. They don't really need to consult you to add features - but they should be sharing what they're doing with you in a way you can understand.