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.

  • 177
    Coding standards that specify details like whether to use spaces in variable assignment, or usage of spaces vs tabs are a real thing in the industry , intended to improve consistency and therefore readability and maintainability. Are you familiar with the company's standards, or is he referencing them in his feedback? Is your code compliant with the company standards?
    – atk
    Jul 12, 2016 at 10:53
  • 26
    Also, what is your coworker's job function and under what circumstances are these conversations happening? If it's during design/code review, it's perfectly normal to have comments/questions with the intention of making the product better. If this person is on another team that has nothing to do with yours, this may be abnormal.
    – atk
    Jul 12, 2016 at 11:08
  • 49
    Nitpicky and opinionated about code details tends to be very common among software developers. Especially the really good developers. Being a stickler for details is one of the things that makes them good. Get used to it or you will end up being miserable time and time again throughout your career. Rather than get upset, express your reasoning for doing what you did in a confident manner. You may find that you end up enjoying the banter and you'll likely learn quite a bit in the process, especially when you realize from your own arguments how wrong your idea really is. Been there, done that.
    – Dunk
    Jul 12, 2016 at 22:22
  • 29
    colleagues who are beginning to treat me differently because of it - I'd be tempted to start asking your colleagues if they agree with new guy right when it happens. Him: "Why aren't you putting a space there?" You to colleagues: "Should I be putting a space there? Is that the standard or one you want to add?" If they say, "Yes" you can say that you'll make the change. If they say, "No" then you say, "OK, then let's move on". Because either it matters or it doesn't and if it doesn't then he's wasting everyone's time.
    – BSMP
    Jul 13, 2016 at 2:14
  • 7
    @JonathanHartley I personally have a strong preference for (and would recommend the adoption of) the process where following coding standards largely consists of pushing the auto-format hotkey in your IDE of choice. Jul 13, 2016 at 15:52

15 Answers 15


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.

  • 1
    Yes. While the direct talk-to-him approach will help, this is definitely also an issue to raise at your one-on-ones with your manager (if you don't get regular one-on-ones, that too is an issue that needs a fix). Jul 12, 2016 at 14:59
  • 53
    The first question his manager will ask is "Have you asked him to stop?" to which this OP can't answer affirmatively: he's addressed instances of the behaviour not the behaviour itself. Only if that fails should this be escalated because I'd expect functional adults to be able to handle minor interpersonal issues.
    – Lilienthal
    Jul 12, 2016 at 17:38
  • 7
    What @Lilienthal said. -- Only take this approach if you have first given direct, polite, feedback to the offender. -- Taking this approach could cause things to escalate; which is fine if you're in the right. And by "in the right" I mean two things. 1) Your work objectively meets company specs/expectations and 2) you have already directly handled this using a lighter touch first.
    – user23715
    Jul 12, 2016 at 18:15
  • 30
    Be prepared for the escalation to not go in your favor. If you are self-taught, it's very possible you learned some very bad habits or processes, and are actually causing more work/headaches for your fellow co-workers. It's very possible the new hire has a lot more development experience, and this is exposing your shortcomings.
    – SnakeDoc
    Jul 12, 2016 at 21:35
  • 3
    @Paparazzi, my point is that this type of thing, if passed to management (not a team lead) will usually force management to choose "who is right" and while they probably will tell the new guy to "play nice" it's also likely that it snowballs into his team members going "yeah and he leaves of semi-colons. And oh-yeah he commits white space, and oh yeah, he does random thing 4 that no one cares about until there is a spot light on the issue." If I was managing that team, 1. New guy play nice, 2. whole team, are new guys points valid? 3. Some new rules to follow so this doesn't happen again.
    – coteyr
    Jul 14, 2016 at 14:41

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.

  • 14
    +1 and just to add my old mantra: document, document, document. So that if this has to go to management, he has a paper trail. Jul 12, 2016 at 12:35

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.

  • 1
    I agree that the OP needs to tell him to stop, but there's never any reason for the OP to act unprofessionally. The OP's goal should be to tell the offender firmly but professionally and politely that this behaviour needs to stop. I do agree that the OP should not be overly concerned with hurting the person's feelings.
    – Cronax
    Jul 13, 2016 at 5:25
  • No, I agree with the commenter, this answer's advice may just escalate the situation, not deescalate it, which is dangerous.
    – user42272
    Aug 10, 2016 at 0:51

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...

Ten Thousand

...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.

  • -1: the post tries hard to take different approach, but fails, given the wrong basis of the thesis. So far OP's code has been successful, and we have no way of knowing whether or not her style is good or bad. This could be also personal preference, but you missed the main point of OP's question: she feels harassed. Talking about "rejection of criticisms" and "constructive criticism" when she considers quitting her job is missing the point - especially when "criticism" comes from freshly employed coworker. Jul 13, 2016 at 8:51
  • 7
    @MatthewRock: why does it matter that the person it comes from is freshly employed? Being freshly employed doesn't mean wrong. Take the criticism apart, not the messenger.
    – kolsyra
    Jul 13, 2016 at 9:06
  • @kolsyra But the messenger comes up with criticism. The person who is working for just one month, and already harrassing coworkers on little things (like spaces around equal sign) does not bode well for the future. Jul 13, 2016 at 9:12
  • @MatthewRock Who else is going to criticise our work if not our coworkers? Certainly not our competitors, they are happy to see us fail. And as for little things, ignoring small things basically means you are compromising on quality, which is a huge no-no. Forget that this person has been working there for a month. What if the same thing came from a person who founded the company? Why would you treat that differently despite the fact that the content of the critique was equally valid/invalid?
    – kolsyra
    Jul 13, 2016 at 10:13
  • @kolsyra For one, founder can fire OP, the coworker can't. Secondly, since OP tried to brush it off multiple times he must have started earlier - I'd guess that as early as 2 weeks into the company, but I could be wrong. Depending on the size of the company 2 weeks might be not enough to get all the rules(like code style guide); the other fact is that code reviews went positive for OP. Besides, calling this "criticism" when OP is harassed and considers quitting is huge Euphemism. The person doesn't seem to constructively criticize, but rather nag OP about tiny details and lowering her morale. Jul 13, 2016 at 10:52

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.

  • 9
    •That is not the current standard This is one that has been used on me and works. It redirects well intentioned suggestions/requests away from coworkers and towards management.
    – Myles
    Jul 12, 2016 at 16:08
  • 13
    Some of the choice of phrasing here comes off as blatantly aggressive. I think that's more likely to harm the OP than to help solve the problem.
    – jpmc26
    Jul 12, 2016 at 16:35
  • 3
    It was intended to be aggressive. He is ruining her reputation at work (she said people are treating her differently) and he needs to be pushed back hard so that he stops. She already tried being polite.
    – HLGEM
    Jul 12, 2016 at 17:17
  • Some of these hints are not so bad but be careful not to over-try with sarcasm. He may collect your most sarcastic notices and present to the management saying you are mobbing him.
    – eee
    Jul 12, 2016 at 17:49
  • 1
    @HLGEM I'm not sure being agressive is a good way to avoid "ruining his reputation".
    – ereOn
    Jul 13, 2016 at 19:23

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 was1 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.

1and 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.


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.


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.

  • I think this is the best answer for this specific case - even though other answers are better in a general case. I'd suggest adding that tools exist to standardize formatting of code such as Resharper of C#. If one of those can be implemented as a policy on all developer machines then you can stop wasting time thinking about what the best way to style something is and focus on actual code problems in code reviews - like immutability and side-effects.
    – Brett
    Jul 14, 2016 at 1:49
  • 3
    "Spaces or tabs" is not a cosmetic issue, if you have a version-controlled project of non-trivial size. It can turn merging a patch/branch into a real migraine. Jul 14, 2016 at 10:17

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.


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).


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.


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.


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.

  • Not sure why this answer was downvoted. Afterall we are only hearing one side of OP's story - doesn't hurt to offer another approach. Personally if I were OP's manager I would ask him to constructively solve the problem first. And if malicious behavior continues, then I would intervene.
    – Joe
    Jul 14, 2016 at 17:15
  • @Joe I think it's just human nature to take sides and assume that one person is more right than another, especially if there is something about that person's story you empathize with. Regardless, I see DVs as opportunities to practice letting the unimportant stuff go. Something I wrote pushed someone's buttons and they took the easiest action that was available to them to express themselves. It would be nice to know what it was so I can get better, but eh, at least the DV drew your attention :)
    – ColleenV
    Jul 14, 2016 at 20:02

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


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.

You must log in to answer this question.