How to deal with a nit-picky coworker

Question

I'm a self-taught software developer here. I am wondering if anyone has advice about how to handle a coworker (with about 1 month of experience at my workplace compared to my 18 months) who takes every possible opportunity to insistently criticize my work at every step of the process, from choices of software packages down to whether to put spaces between an equals sign and a variable assignment (I kid you not).

This happens somewhere between several times a week to several times a day. It happens on an increasingly regular basis, and increasingly in front of colleagues who are beginning to treat me differently because of it.

There is objective evidence that I am, in fact, good at my job. This week I received an 18% pay raise. Every performance review I have ever received has been stellar, and I am frequently suggested for leadership roles by management. However, like most coders, if anyone looks closely enough at my work there are of course constructive criticisms to be made. I normally enjoy code exchange/review and see it as a productive learning opportunity.

What has happened over the last month since my new coworker started is something entirely different. I have tried multiple strategies to deal with this: ignoring it and going about my business, politely but firmly explaining why this person is wrong, asking this person to lighten up, and using humor to point out the ridiculous nature of some of the more nit-picky criticisms. NOTHING WORKS.

This is my dream job. For the past 17 months before he started, I woke up every day excited to go to work. Now it's bad enough that I'm seriously considering quitting.

Answer 1

My input is take this to your manager.

Constructive feedback in a code review is one thing. Calling you out up to several times a day in front of peers is pushing bullying.

Tell your boss straight up

It is hurting my morale. I used to enjoy work. Constructive structured feedback is great but calling me out up to several times a day in front of peers to me is not appropriate.

Answer 2

You need to be direct. What you've done so far is hinting at the problem and sending signals that his input is unwanted and inappropriate. That will work fine on reasonable people. Your new colleague is obviously not reasonable.

So talk to him. Because you've been at the company for nearly 2 years and he's new, you do have some informal standing to discuss this with him and that goes double for someone who just entered the workforce. Talk to this colleague in private and say something like:

I've noticed that you have a pattern of commenting on my work or criticising the choices I make. I've tried to make it clear that this feedback is unwanted and unwarranted but it seems like you haven't got the message. If you have questions about why I do X or why we use package Y then I'm happy to answer those for you but I need you to stop criticising my coding practices. It's not your place to give me that kind of feedback and it's especially strange coming from someone who just joined a new software development environment. Since you've just started I'd recommend that you focus on learning about and adopting the kind of coding practices and tools we use here. The kind of black-and-white programming they've taught you at college doesn't usually translate to a productive environment and you should take the time to familiarise yourself with a system before criticising it. Maybe you don't realise this but that kind of uncalled-for criticism can really damage your standing and reputation and it's a bad habit to adopt in a workplace.

That's a lot of text and fairly harsh so I'd suggest picking out what works for you and adjusting the tone as needed. But whatever you do, don't resort to "I'd like you to" or "maybe it would be best if". You have the experience to speak about this topic and you have a clear and reasonable request to make of you colleague. Don't soften the message as it risks hiding it.

After this, the next time he does this drop what you're doing and call him out on it immediately:

Hey, this is what we just talked about. I don't need you to criticise my choice of syntax here and as I said I need you to refrain from doing this in the future. Can you do that?

It might take a few tries but this should work for all but the most asinine coworkers. If you've got one of the latter at that point you need to raise this as a performance problem with your/his manager.

Answer 3

Sophie, you said that nothing works. Actually, your very polite attempts at changing his behaviour haven't worked.

You tried "ignoring it and going about your business, politely but firmly telling explaining why he is wrong, asking him to lighten up, and using humor to point out the ridiculous nature of some of his more nit-picky criticisms". You haven't done one thing: You haven't told him to STOP. The next time he comes, tell him to STOP and to go away. This person is making you dislike your job, there is no reason to be polite. He doesn't understand you when you are polite. There is no need to discuss his suggestions and criticisms.

Don't be afraid to hurt his feelings. He is making you want to quit your job, so he is trampling all over your feelings. Don't be afraid of being impolite. He is making you want to quit your job, that is about the most impolite thing imaginable, so he doesn't deserve any politeness from you.

A comment kind of claimed that this would be acting unprofessionally. It's not. Your colleague has been treating you in a way that makes you want to leave your job. That is utterly, utterly, unprofessional. Anything that stops this behaviour without affecting unrelated persons or breaks the law is professional. Starting a confrontation is not professional. Stopping it is. Starting the confrontation has happened a long time ago, and it was not you who started it.

Answer 4

Let's take this a piece at a time. I think you have a valuable opportunity here.

I'm a self-taught software developer here.

The tl;dr is that I'm thinking this is his issue. This could be totally off-base in your individual circumstances, but it definitely fits the profile. It comes across as if he (at least subconsciously) resents the fact that you ended up at the same place he did without following the same path as he. His actions -especially the insistence on openly criticizing you around your teammates-- could be a form of self-aggrandizing othering in an attempt to validate his efforts to taking a different path. If so, this is not something you can actually fix by any method other than being better at your job than he is. But that will require a ground war that will reave cities and cost countless lives.

No; the approach that I suggest is to use your good standing with your management and his apparent over-eagerness to find fault in others to position yourself as someone who is interested in the long-term perspective of their company rather than "winning" the day-to-day squabblings with a know-it-all neophyte.

In the process, you will need to give in to some of the things that he is demanding, but as an admittedly self-taught developer, you already know that you will need to continue the path towards gaining a solid understanding of your craft to know which things are worth compromising, which things are uncompromisable, and how to know which course of action gets you what you want.

---

So...what is it that you want?

• Do you want things to be "the way they were" before he joined the company?
• Do you want to illustrate to management that you are management material?
• Do you want him to respect you as a peer?

• Do you want him to respect you as a superior?

  1. That ship has probably sailed.
  2. Possible.
  3. Possible.
  4. Possible.

I am wondering if anyone has advice about how to handle a coworker (with about 1 month of experience at my workplace compared to my 18 months) who takes every possible opportunity to insistently criticize my work at every step of the process, from choices of software packages down to whether to put spaces between an equals sign and a variable assignment (I kid you not).

These are potentially valid constructive criticisms of code quality and maintainability. There are software components that can be leveraged to increase productivity. But I doubt a developer with as little experience as he does has a deep enough experiential perspective to take a hardline stance for or against use of someone else's code, so any value in his message seems to fall by the wayside by his own doing. I'll let xkcd speak for me on how I feel about handling the introduction of things to other people...

...If he isn't taking that sort of tact with his discussion of "things of which you do not know" then you really need to discuss his manners with your management team.

This happens somewhere between several times a week to several times a day. It happens on an increasingly regular basis, and increasingly in front of colleagues who are beginning to treat me differently because of it.

That's the part that makes his approach so unreasonable, but also the thing that presents the most intriguing possibility of value to you. He is being visible about his 'attacks.' I would not confront him at all about these and would instead consult with management to explain the situation and lean on them for advice on how you can respond in a way to his unwitting approach that demonstrates

1. your commitment to find a way to productivelyco-exist in the company
2. your leadership qualities. (risky if you feel you aren't up to the task yet)

There is objective evidence that I am, in fact, good at my job. This week I received an 18% pay raise. Every performance review I have ever received has been stellar, and I am frequently suggested for leadership roles by management.

Congratulations. That means that you are keeping the right people happy with your work.

However, like most coders, if anyone looks closely enough at my work there are of course constructive criticisms to be made. I normally enjoy code exchange/review and see it as a productive learning opportunity.

Good. Keep this perspective, even though he's being tactless with his presentation. Try to cut through his brazen approach and see if there is actual value to be had behind his statements. I would always respond to his challenges with thoughtful "why?"s rather than a summary dismissal due to his tone. But take care to demand solid answers; asking a bare "why" to something mundane and simple could be perceived as you not knowing basic requirements of your job. That's why I wouldn't even engage him until a conversation about this with management.

1. This would easily demonstrate that you are willing to listen
2. This would easily demonstrate that you are looking for a good reason to do what he suggests.
3. This would be an easy way to extract that paid-for education from his brain.
4. When taken to your management team, you have substance to talk about: "He was unconvincing"; "well...he might have had a good answer why I should listen to him, but I couldn't hear it through his rudeness."

Any way you slice it, asking him "why" he feels the way he feels can be turned advantageous to you. Summarily dismissing him does nothing but create an environment working to his favor.

What has happened over the last month since my new coworker started is something entirely different. I have tried multiple strategies to deal with this: ignoring it and going about my business, politely but firmly explaining why this person is wrong, asking this person to lighten up, and using humor to point out the ridiculous nature of some of the more nit-picky criticisms. NOTHING WORKS.

So...here is where the "he said/she said" can actually be partially considered. The outcome you appear to be looking for is "leave me alone" and the outcome he appears to be looking for is "for you to change." You have not stated whether you have justification for demanding to be left alone and we don't have enough detail to know whether he is right for expecting you to change.

You both seem to be very early in your careers, so the only noncontroversial statement I feel I can make is that you need to get much better at your craft and he needs to get much better at his craft.

At the end of the day, that 18% raise you mentioned and consideration for managerial positions should be looked upon as validation that you are following the path your client wants for you;however, you definitely shouldn't let it go to your head that this polarizes your positions into "You are right and he is being petty." That would be egregiously overplaying your hand...just saying that as a word of warning. It's easy to think such things provide rank to be pulled, when really they aren't. They are signs of evidence that you have a track record of doing a good job. Don't change that track record.

If I were in your shoes, I would definitely discuss this with management and position myself such that this is an opportunity to rise to a challenge from a difficult individual; however,be careful to frame it with non-binary conditions. You will want to take some of his nonsensical criticisms to heart, but only do so after grooming the list of things you will do with your management team. Otherwise, your willingness to modify your behaviors for the good of your team will not have visibility and he will simply be in position of "correcting incorrect behavior."

Your rejection of his criticisms seem to be more from his approach than the substance of his statements (which are subjectively valid reasons to ignore him) but unless management sees it this way, you run the risk of coming off as obstinate.

Just a spitball on something that may be the lowest hanging fruit for you that I see is to ask yourself whether his recommendations violate your team's coding standards. If you find that you don't have defined coding standards you could approach your management with the idea to define them then proctor the team meetings where he will likely hve tons of things to say on how the team should do things and you can moderate between the other team members. This approach has the benefits of allowing him to have his say, you demonstrate thoughtful leadership, and your team can decide as a group what the standards shall be. This redirects his energy away from directly confronting you for things that he disagrees with and makes it about the team. ...Make sure management knows it's your idea to broach the subject in this way.

You will almost always have to find ways to work with difficult people unless you progress into a position where you are in control of your workforce.

You will almost certainly not be able to change him; you should manipulate his over-eagerness in finding fault with others to better yourself in your own and your management team's eyes.

Answer 5

The circumstances of where and when he does this can dictate your response.

If it is an actual code review, you will need to be more polite. Have a set of answers ready for the more common criticisms that reflect the standards of your own organization. If the coding standard is to use a tab to indent and he wants to use spaces, then smack him down for violating the standards in his suggestions. Some new people want to apply standards they learned elsewhere and forget that each place has its own way of doing business. If there is no standard (and the way you do things is consistent with how other devs do things), then tell him that his comment is irrelevant and to concentrate on real issues.

If he calls you out on things that he does not criticize other devs for and they also do they same thing, then ask him what his problem is that he objects to things in your code that he doesn't object to in others code. Be strong enough in your objection in this case that he treats you like a cobra that might bite him at any minute. He has picked you out as the easy prey if he is not making the same criticisms of others. Show him that he is mistaken about that.

And for code reviews, this is a key point. When he makes a valid point, accept that gracefully and implement it. If you object to everything he says, you just look bad. But if you accept the valid things well, then he looks stupid for pushing the invalid things.

If he starts this up out of the blue or only when other people come into hearing range, then shut him down with something like:

• That is irrelevant to the discussion at hand
• That is none of your business
• That is not the current standard
• I don't work for you
• I didn't know you were the coding god who gets to dictate things. Can you show me the email where you were assigned that responsbility? (Sarcasm works wonders sometimes)
• Can we get back to the relevant issue like...(Helps if you bring up something he needs improvement on at this point)
• It was already decided to go this direction and we are not going to revisit it at this point (good for when he criticizes the software/method you use for an issue rather than the nit picky stuff.)
• That's incorrect.

If you have coworkers that you can trust as allies, then get them in on the act to shut him down as well. If you say that this is not a valid criticism and then one or more other people jump into the discussion agreeing with you, that makes your case stronger.

Answer 6

I feel like having to add my 5pens aswell.

Since from your description I feel like I absolutely could be that guy, I'll first tell you what I'm assuming is wrong with your approach, and additional I'm going to give you an advice which might even help you to understand his real intentions, in case his intends are indeed of same source as mine would be.

So, first of all, I can't review his professional knowledge versus yours. But I'm assuming your presentation of your self here is also biased.

So what if you might be just a little bit too overconfident with your own skills? All I read so far what you tryed was:

I have tried multiple strategies to deal with this: ignoring it and going about my business, politely but firmly explaining why this person is wrong, asking this person to lighten up, and using humor to point out the ridiculous nature of some of the more nit-picky criticisms.

All this implys him beeing wrong or even is devaluing his thoughts. But what if actually you were wrong? Or maybe even no one of you both is wrong and both of you are just expecting each other to have diferent expectations of the discussion as you actually have?

Now let me tell what might actually be the case, as this is what I'm facing not that unfrequent:

I'm developing in C and at some point I even figured that I feel it enjoyable to read standard documents for specifications like programming languages, so it got a hobby of mine to learn the language by its definitions. Some of them are usefull. Some of them are just for specific cases. Some of them are just stupid, but still parts that strictly speaking define the language. Especially the rules designed for special cases are usually simply worked around by compilers so no one has to worry about it. But just because your compiler works around the users potentional lack of knowledge that doesn't mean that it becomes correct, just because it works.

I really like to enlighten others with my efforts I put in learning C as ISO/IEC conform as possible and it is fun for me doing so. Sometimes when reviewing others code, I notify them about something not beeing strictly conform with C. And here 2 situations usually came up, one of them I really enjoy, while the other situation was¹ kinda unpleasent for me

So the first option that usually happens:

• the other person started asking about the impact and the reasons why this should be wrong, and a discussion came up where we both finished the arguments with a point where I sattisfied had been able to say, the code is this way nothing diferent from what I had done, but is one of the nasty bordercase tweaks which might on other occassions invalidate the code and the other person thanks for the talk and my effort to improve their knowledge.

and the second is:

• The person feels offended, just starts defending by asking me for a proof of them beeing wrong, since what they do is actually working and doing the job. While here I easily could proof it I just back out since it is not my intention to expose them for being wrong and what I had to learn as previously noted, in that situation there is no chance anymore to explain "Hey I'm just trying to help", as it would just be taken as excuse for exposing them anyway.

Maybe he just isn't at the point that he had learned yet, that some people just don't like to improve their knowledge on spontaneous occuring occassions. And beeing left aside you are or aren't one of those persons, remember if it was me you were talking with, it would have been a friendly gesture and no offense at all.

Also especially your example about the omited space between the equals operator and the operands, makes me feel kinda offended, but I'm sure you had no bad intentions here.

I for example never had anyone seen who defended against my advice to him placing a space there, and even if they kept omiting it, I would tweak on it whenever I had to review their code (and thats no joke either!).

Here I want to add another example:

I'm working in a little startup company which is actually growing in size. Obvisiously there were no coding policys in the beginning. Our CEO some months ago tasked me for creating such policys, as I especially am verry aware of reserved expressions, signs and keywords of C-language. So I did it, presented it and it got aproved. But yet no one cares about it, and our CEO doesn't bother with enforcing it, while he still had his reasons to task me with it and approving my design, there isn't much I can do about it except reminding others about it. So ofcourse I could just stand up and say " Listen guys! You know the policys I designed? I expect you to strictly respect them from now on and I'll correct your code to be conform with it if you still don't care! ". Our CEO probably would even support that move, but.... Com'on how much of a jerk I would be looking like for my future in that company? So I just keep remembering them if I see them breaking the policy at some point and let it to them, while knowing they had to do it. But it is not my job to enforce it so while it kinda hurts to see own work beeing disrespected in that way, there is not much I can do against it except being the nitpicky dude that ocassionaly rebukes "for not respecting his so called policys".

So that little story from my allday attitude to hopefully help you getting a better understanding of his point and why he might be acting as he acts.

TL & DR:

So what is the conclusion?

I would advise you to try to understand his motivations, while keeping in mind my view of situations that occured to me in my working life.

The way you wrote the OP is in a way that lets you appear, as you're assuming that he is doing so with bad/selfish intentions.

But to solve your problem you should try to figure out first if thats really the case. If he tells you the next time you're wrong, ask him how he would solve this in a better way, try to understand his concerns and you'll probably see, if he really just wants to demonstrate his superiority or he wants to do professional exchange.

If the latter is the case, I guess it will change your view about him anyway.

And if the former should be the case.... Well, than I have nothing to add what not one of the other answers allready advised.

---

¹and I really had hard times in learning to handle that situation, and while I feel I'm doing so meanwhile pretty well, I still feel unconfident when ever this happens.

Answer 7

Sometimes, new employees have very good ideas. And sometimes they just want everyone to suddenly start working the way that works best for them.

No matter how good or how bad their ideas are, this can be very disruptive. And, as you see, it can be extremely demoralizing to others.

Either you or your manager need to talk to this person and explain to them that they are the new guy and everyone has work to do. While you appreciate their enthusiasm and are interested in suggestions to improve your processes, coding style, and so on, it's just too much and it's too disruptive.

If you have a written coding style and you're not following it, you're wrong. But if you don't have a written coding style or you are following the current written style, then you're right. Nobody should be nitpicking about style. If they want to write a style document for the team to consider, that's fine. If they want to write an email suggesting that one style option is better than another, that's fine. But if you don't have style rules, then you don't have them. They can't enforce a non-existent rule.

It's possible that you'll get a string of great suggestions out of this new employee. But it can't be all at once and it can't be done in a negative way.

Hopefully the company values you enough that your manager will get them to tone it down if you can't. Unfortunately, my experiences with people who want to change everything and criticize everyone have not been good. This is especially true for people with limited experience. They may have to lose a job or two to learn that the company they work for won't run the way they personally prefer.

Answer 8

It appears that this co-worker's nitpicks are of the "spaces-or-tabs" variety, where, for the most part, their preferences are mainly cosmetic, rather than a matter of maintainability over the long term.

My rule of thumb is often: is this style decision necessary to ensure find-and-replace refactoring will work in a click of a button, and is this block of code - and the style in which it is written - heavily depended on by multiple segments of the codebase? If you answered "yes" to both of those questions, then your co-workers concerns may be quite valid. Otherwise, and especially if nitpicks are getting in the way of providing real value, you should unambiguously inform the co-worker that their preferences are holding back progress, and that they should keep their preferences to themselves if they do not pass a basic metric. Hopefully a standard in place can keep situations like these from arising again, or at least with the annoying frequency in which you have described.

However, as Paparazzi stated neatly, any persistent problem with a co-worker that you cannot solve yourself should be brought to your manager. That is their job.

Answer 9

Have you considered the possibility that your coworker may have valid points?

I'm going to focus on: "...down to whether to put spaces between an equals sign and a variable assignment (I kid you not)."

In my years as a developer, I have criticized others for:

• Inconsistent use of spacing.
• Using spaces to indent instead of tabs.
• CAPITALIZATION of variable names.
• Mispelling function names.

All of these are entirely cosmetic issues. Here is why I think they are important:

• When a file is edited by one person, then a second, back to the first, etc., the source-control system collects "diffs" between the files. If the two developers disagree on how to use whitespace, these diffs will be full of meaningless whitespace changes, making it difficult to find the actual changes. Each team needs to decide on rules for how to use whitespace and stick to them.
• In Java, the convention is to use ALL_CAPS for class-level constant (static final) variables, and camelCase for other variables and funcitons. Most other languages have similar conventions. If you go with nonstandard capitalization, people can get confused about your variable usage, and assume a variable is static final, when it's neither. This can lead to subtle bugs.
• I once wrote a function that was supposed to Override a function in a superclass, but the other programmer used inexplicable spelling, so my new function was just a new function, not an override (this was before @Override was common). Very subtle bug whose correction wasted a lot of time and involved lots of swearing.

You're still a new programmer, and your coworker is newer. But it's possible he/she learned good habits from a professor with lots of experience, someone who's been through problems caused by "cosmetic" issues and who understands how important they can be.

On the other hand, there remains the possibility that your coworker is simply not right. What you are describing sounds like a type of "mansplaining": a man will criticize a woman over trivial things not because he genuinely thinks she's wrong, but out of a need to dominate her. This sort of thing is unfortunately common in the tech industry. If this is your situation, the ways to deal with it could be a bit more complicated. Seeking help from coworkers or management can be fruitless, as other men often tend to turn a blind eye to such behavior.

What I recommend: Do not ignore the criticism. In either case, that won't help the matter. Engage. If the criticism is about spacing or some other aspect of coding style, seek out or generate a coding-style guide. Every team of developers should have one. (Sonarqube offers automated coding-style checks which are very good, even if I disagree on where they put open-braces).

If your code conforms to the style-guide, then any nit-picking on those points can be rebuffed by pointing to the guide. (Without a written guide, the criticism can vacillate such that you can't win.) Learning to stick to capitalization conventions can take time, but it's worth it. If you have difficulty spelling (some very smart people have trouble spelling), then practice will help.

If you feel like the issue is more of the "mansplaining" sort, then I would recommend looking up (at home, on your personal computer) articles about how to deal with mansplaining. There are a lot of women in the software industry who've been around for a long time who have very helpful advice. I'm not one of them, so I probably can't be of much help.

Answer 10

There are different coding practices , and its not true that someone with a month XP would not be able to correct someone with 18 months XP, but thing is here he could bring these things up in the session when you or other coders are talking about coding styles , we do have such session where we are told about Best Practices by some senior member and juniors also take part in that sometimes with valid good points, you must suggest him to bring these things in such session so almost everyone can give there input on this,instead of picking this every now and then as it get irritating answering and explaining every silly thing during development.

Have a talk with him and tell to bring up his best practices ideas during such session instead of nit picking,at least he will not feel completely ignored (if he was correct at something).

Answer 11

An efficient counter-measure is to improve the own work enough so he would not be able to find enough real problems to continue.

This will not stop him, I understand. But, still attempting to pour the criticism in buckets, he will start making mistakes and become vulnerable.

Then you should be able to show (in public, with all listening) that this or another criticism is groundless and actually shows incompetence of the critic himself. One or two such loses in public should make him much more quiet.

Also, check if the work of the co-worker is really flawless. Very often such people set different and much more relaxed requirements for themselves. Finding and openly discussing some glitch on thy side may work much better than attempt to defend again they criticism.

P.S. Do not attempt to reply with sarcasm, this can be relatively easily turned against you.

Answer 12

Your question

I am wondering if anyone has advice about how to handle a coworker (with about 1 month of experience at my workplace compared to my 18 months) who takes every possible opportunity to insistently criticize my work at every step of the process,

You then go on to say

This is my dream job. For the past 17 months before he started, I woke up every day excited to go to work. Now it's bad enough that I'm seriously considering quitting.

Maybe what you are looking for isn't so much a way to deal with your coworker as much as it is enjoying your dream job again? Maybe not. Either way, there are two options:

1. they can change something
2. you can change something
3. none of the above

---

1. Can they change anything?

Objectively speaking, people have a hard time changing regardless of how well informed they are. Think of how many people quit smoking because their doctor warns them of lung cancer, and that's a situation where they might potentially die. Think about it. Someone is telling them that they could die if they don't change, and still they don't.

So what are the chances that your coworker will change just for your benefit?

Even if they were going to change for your sake, there is no clear way for you to force that change on them.

2. Can you change anything?

The way I see it, you've already tried what I'd call the realist option (telling him why he is objectively wrong). There are two more options (that I can see) and they are both equally valid.

You: The pessimist

Assuming that your coworker does not change, and will not change ever, and you don't change jobs: Is it possible for you to keep this job, have this become your dream job again, regardless of your colleague? If the answer is yes and you see a clear path towards that, pursue that road relentlessly. If you can't see the path, have a look at the paragraph below and see if that helps. If the answer is absolutely no, think about quitting. I promise you, there is more than one dream job. Sometimes we have to let the good things in our life go, and hope that we find something even better.

You: The optimist

Have you tried agreeing with him? Regardless of whether you agree or not. For a moment, step into his world where you assume that you are indeed in the wrong. Stay there, and point out things that you think he missed out. Example:

He: "You forgot to put a space here"

You: "You know what? You're right. And I forgot to do it here too. Thank you. Can you do a code review of this patch to see if there are any more stylistic choices that I could improve?"

What this does, is absolve you of any responsibility of dealing with him. Dealing with him isn't your job. Your job is to write code and be the best you can at it.

After all, to quote you:

However, like most coders, if anyone looks closely enough at my work there are of course constructive criticisms to be made. I normally enjoy code exchange/review and see it as a productive learning opportunity.

You enjoy code exchange review. You see it as a learning opportunity. Take this opportunity to learn from him, even if it might be objectively wrong. Don't take it blindly, ask questions like

Oh ok. I see you've pointed this out several times in my code. Where can I read more about this?

This passes the ball back to him. Can he back up his criticisms with actual facts/best practices? Can he be a helpful coworker? Being helpful means going past criticism, and helping your coworker improve.

3. Nothing changes

Let's assume he doesn't change and you don't change, in terms of your interactions. Let's rewind a bit in your question:

There is objective evidence that I am, in fact, good at my job. This week I received an 18% pay raise. Every performance review I have ever received has been stellar, and I am frequently suggested for leadership roles by management.

So you are good at your job, and you acknowledge that there is room for improvement. Your seniors even suggest you for leadership roles. If you indeed see him as nitpicking, and you believe that his suggestions are not important, why does it affect you to the point that you don't enjoy your dream job? After all, you are objectively good at your work. There is a disconnect here. Either what he is saying is invalid, and you should not care about it, even if he does pester you about it. Or what he is saying is true in addition to you being good at your work, in which case you absolutely should care about it.

Good luck, hope you find the joy of going to work again. Everyone deserves to have that :)

Edit: Unrelated but important: Nitpicks of the type "spaces vs tabs" should be taken care of by a sanity bot /pre-commit hooks that goes through your commits before they are even made public. Look into git pre-commit hooks here. Suggest that your team makes one for style checks, because automation over developers expressing opinions on style.

Answer 13

I know this has a lot of answers already and while Zaibais' answer touches on this, I wanted to add a brief suggestion that has worked for me (and ON me) in the past.

Some people have a hard time keeping their "good ideas" to themselves. I know that many people don't understand why I object when people separate their variables from their assignments with tabs so they can make a pretty list all aligned at the same tab stop. If you want to stop my nit-picking, just listen to and understand me. I don't care that much if you keep doing what you do (I've worked on this), but I can't help but try to help you if I see a way you can do things better. I will not let you walk around with spinach in your teeth after lunch; I will say something.

Have you tried pretending that it isn't criticism, and that it's just a helpful suggestion? Sometimes if you say "Oh, why do you think that's important/should be done that way?" you can turn criticism into a discussion where you can demonstrate that you know your stuff and have reasons for doing things the way you do them. When you start discussing and listening, you connect. People who aren't sociopaths have a harder time tearing down people who they have a connection with. Who knows, they might be the yin to your yang and the team will be better with you balancing each other out.

This may be too difficult for you depending on how tense things are, but I have turned a situation similar to this around by sending an e-mail simply appreciating a good quality of the person. "Sharon, I really appreciate that you speak up when you see something you think could be done better. I may not always agree with you, but I respect that you are constantly looking out for the team." Or something like that - it needs to be sincere, which makes it difficult to do if you have a lot of bad feelings toward someone.

Answer 14

Been in the industry for a while. That is just how some developers roll.

Next time tell him you are really busy and he must write a letter and you will read when you find time. He'll eventually get the message

Answer 15

I am going to come at this from a bit of a different approach.

The fault lies in the fact that you (two) are being bad team developers. There is no I in team, and while this guy may be going about it in the wrong way he is 100% correct in the fact that these decisions are "team level" and he should have some input in them.

choices of software packages down to whether to put spaces between an equals sign and a variable assignment (I kid you not).

Linting your code is important. to space or not to space is a serious code style question that will fail some metrics. The best answer here is to have a style guide you can point to that says don't or do put spaces. If your doing it one way some times and other ways other times. Then your being a "bad developer" and he has every right to criticize you. What is more likely is that you like spaces and he does not (or inverse). Having a style guide fixes this in about 30 seconds. Of course you have to stick to it, and that can suck while you adjust. Almost every programming language I have seen has a style guide that you can just "use". Most, if not all come with tools to help you enforce that guide.

Same with packages (rather code packages or tool chain) there should be a nice predefined set of what is ok. When you need something not on the "approved list" then its time for a team meeting. THE TEAM needs to choose what tools are used team wide. Not you randomly go off in one direction while your teammate goes in another.

The short version is that, your both wrong. He should not be as pushy and you should be including him in these decisions. You should be talking about this stuff before he even has a chance to nit-pick about them. Your now on a team, and need to act like it. Maybe because of your experience your the QB. But your not gonna get any where if your line does one play while you do another. Talk, communicate, work together, and STOP making team level decisions on your own.