8

I am a fairly green manager of a small team of 6 software developers. In addition to managing, my responsibilities include providing technical direction, making overall architectural and implementation decisions, and some regular writing day-to-day code.

As part of our development process, we have another developer on the team review code before sending it off for QA and subsequent release. This serves as a quick sanity check, but also enables developers to share knowledge, both general and about areas of our code base they may have more experience with. Everyone on the team has said that this process is valuable, myself included.

One of our less experienced developers tends to get angry when his code is critiqued, particularly when I am reviewing it. This developer has asked for additional feedback, specifically during these code reviews. Yet when that feedback is provided, the response from the developer is anywhere from being calmly disappointed to outright anger. Usually I am calmly thanked for the feedback, only to find out a week later that this developer has been angry about that feedback without raising the issue. The most recent occurrence, the developer accused me of pointing out flaws in code as some sort of a game that I get a kick out of, claiming that the issues I called attention to were trivial. (On this latest feedback, the issues pointed out were minor in comparison to prior code reviews, where most things pointed out were critical problems. This is a good thing as the developer has been learning and improving over time. Even still, the things pointed out were unacceptable as-is and needed to be fixed prior to release.)

During code reviews, I see myself as a peer to the other developers. (In fact, we have always called them peer code reviews. Anyone on the team can review anyone else's code. While I review an awful lot of code, it's because I am often available to do so in between meetings and what not.) This developer has told me that he seems my approval of his code as mandatory, even though that is not policy and it has been said numerous times that he can have anyone on the team review his code.

This particularly developer is a bit volatile and has been known to outburst at folks from time to time. His productivity depends largely on his mood for the particular week. He takes any feedback personally, even if it is minor feedback with clear solutions provided. He has perceived complicated social situations and conspiracies between individuals in the office that to my knowledge do not exist.

I see my management role as a supporting role of the team, doing whatever I can to enable them to be successful in what they do. The situation is the same company-wide. We encourage employees to talk to whomever they want (no need to go through the "chain of command"), we provide all the training you can eat, and almost everyone is receptive to feedback, positive or negative. I look at things objectively and strive to provide clear solutions to clear problems. This developer seemingly looks at things from an interpersonal perspective and is focused on determining everyone's underlying motivations rather than focusing on the work at hand.

I hope that provides enough information to set the scene. If not, please ask for clarification. My questions:

  • How can I provide feedback to this developer in a way that allows it to be perceived by this person for what it truly is... feedback, not a personal attack?
  • I can certainly lower my expectations but I believe this is a disservice to the developer an the company. Am I correct on this? (No other developers on the team, past or present, have had a similar problem.)
  • My manager has also worked to deal with this developer directly and hasn't been able to offer much advice. He has told me to spend the majority of my time on my best employees. While I think this advice applies, I truly want to help this one developer as I believe he is capable of good work if he had a different perspective. I understand that it's hard to get the whole picture from this post, but is the situation hopeless? Should I lower expectations for this one developer, do the bare minimum for him, and spend more time mentoring other developers?
3
  • Would you say that the developer feels that the code is his baby and is out to protect it? Could be a maturity issue or taking things in a different light but would need a few more details first.
    – JB King
    Mar 4, 2015 at 21:07
  • @JBKing In this case, no. The projects this developer is working on are owned by a sub-team of 3. He has always been cooperative with the other developers. We pass around work on the team as-needed, as well as to ensure we all have experience in various areas. This developer has genuinely welcomed the team approach. I also don't believe this is a matter of maturity. This developer is generally professional, and while new to web development, has had a lengthy previous career in another industry. Mar 5, 2015 at 3:41
  • 1
    Do you mark the non-critical suggestions as nits? Mar 7 at 15:33

5 Answers 5

8

As always, interaction with individuals will vary based on the individual and you. I'm providing suggestions based on my experience on both ends of the communication.

How can I provide feedback to this developer in a way that allows it to be perceived by this person for what it truly is... feedback, not a personal attack?

It sounds as though you're not communicating in your review. You say these three things need to be fixed, but I don't hear any indication that you ask the developer if they agree. Peer reviews go both ways - you point out things that should be fixed, but there's often reasons that developers do things the way they do them. Often these are good reasons that entrenched developers just haven't been exposed to. I also hear a lot of things that are "wrong".

So, make sure you're explaining why something is wrong. Certain individuals (programmers especially) abhor blindly following direction, even for their own good. Make sure you're giving them opportunity to offer their opinion - ask for it explicitly. Without this sort of back and forth, telling someone how to write their code can be perceived as micromanagement. It usually is micromanagement. Finally, point out good things too. You mention that the developer has gotten better, but unless you communicate that, they may perceive you poorly.

Oh, and especially for beginners, it is important to explain the benefit of the code review process. It's not just a dump-on-the-n00b-fest. It's there to cut down on bugs that are annoying and expensive to fix later in the process.

I can certainly lower my expectations but I believe this is a disservice to the developer an the company.

It depends. If their role is a lower responsibility role, then your expectations should match that role.

But you should definitely adjust your interactions with this individual. People are different. What works for one might not work for another.

I understand that it's hard to get the whole picture from this post, but is the situation hopeless?

It could be. If the employee is off lowering morale of the team by being angry about reasonable processes all the time, that's no good. If the employee has a mental issue where they blow up perceived slights into conspiracies, that's no good.

But it could just as easily be that your employee has an unusual personality and you've been slow to recognize or adapt to that. It certainly seems premature to give up hope without knowing where the problem actually lies.

5
  • Also, are you only pointing out problems in the review or do you also highlight things that are done well and that other developers might want to incorporate in what they're doing? You shouldn't say something is good that isn't, but constructive criticism is easier to swallow with a spoonful of appreciation. I know that as an Engineer, I have to make a conscious effort to express my appreciation for something well done while pointing out problems is as natural as breathing.
    – ColleenV
    Mar 4, 2015 at 21:53
  • @ColleenV - I mentioned that at the end of my second non-disclaimer paragraph? Was it not clear?
    – Telastyn
    Mar 4, 2015 at 21:55
  • Sorry, I must have missed it trying to scroll through on my mobile. I completely agree with your answer, and the particularly when I am reviewing it in the question leads me to believe that more appreciation of what the developer is doing right would be a big step toward making the reviews go better, so I wanted to call it out. My gut feeling about this is that the less experienced developer has a lot of respect for the manager and wants to impress him, but has some maturity issues and gets frustrated when he doesn't get more exuberant positive reinforcement than "you're getting better".
    – ColleenV
    Mar 4, 2015 at 23:20
  • Excellent advice, thank you for your feedback. In code reviews, I do point out things that developers are doing well, but admittedly this is only in exceptional circumstances. In my regular 1-to-1 meetings with this developer, there is regular praise of his work as well as suggestions for opportunities to improve. The same for formal meetings. I do agree though that the code reviews could be much more of a conversation. With other developers they are, but I need to make a better effort to solicit input from this developer. Thanks again for your excellent input! Mar 5, 2015 at 3:33
  • @candied_orange - I’m not sure rag has that connotation here, but point taken - editing.
    – Telastyn
    Mar 7 at 15:13
4

Criticism

There are many reasons people can get very defensive about criticism of any kind. It can be due to insecurity, past trauma, etc. Ultimately it can be helpful to understand what the touchy subject if you know this you can adjust your approach accordingly.

Nothing is Wrong, bad, terrible, worse, etc.

The key to giving criticism is to never put the person on the defensive. That means you should avoid negative words like wrong, bad, terrible, worse, etc. Which on that note avoiding better is also a good idea as it implies bad.

Bad example:

Hey Bob, I was reviewing this controller method you wrote. It's really not a good idea to have this directly call the database.

Why? You were good about pointing out the what, but you risk putting bob on the defensive and you didn't give him why. You basically said "You write terrible code" from Bob's point of view.

Okay example:

Hey Bob, I was reviewing this controller method you wrote. I think it would be better if we accessed the database through a separate repository to help prevent SQL Injection.

Why? Well now you did an excellent job of the what and why and you didn't directly accuse Bob of bad code. He still might get defensive, but at least you've mitigated it some.

Good example:

Hey Bob, I was reviewing this controller method. I'm worried it could be SQL Injected; do you think accessing the database through a separate repository would make sense to prevent that?

Why? For one thing you didn't even point out this is his code, he knows it is, but not pointing fingers (even when you are) really helps. In addition to this you didn't skip right into what is wrong with the code, you provided a concern then where that concern is. This means his mind is already considering the real issue and not immediately going on the defensive.

Honesty is the best policy

Being honest with someone is always a plus, often though you need to manage how the message is conveyed though. Some people love the straight to the point no nonsense approach where you just say "Your attitude this past week has been terrible, I know you've had a rough week, but let's get our heads back in the game okay?" I prefer this, no dancing around the issue at hand, I also know you say this to the wrong person and they're going to be really upset by it.

In this case this person goes on the defensive pretty easily, the direct approach isn't going to go well. Instead try to address the symptom and let him sort out the problem. (unless he asks directly) Say he's got a piece of code and it's running unreasonably slow because of a simple honest mistake.

When he asks for your approval take the time to look over everything per norm. Go through the code, explaining the things you like about it. "This extension you added here, that's going to come in handy later", "This query is really good work, should be easy to adapt if we ever need to pull additional data", etc.

When you hit that spot that has some code smell go "Hmmm... this works, did you consider making this a Switch case statement? I'm worried if we decide to add more values this could become cluttered."

In this case you didn't say "Hey Bob, these four else-ifs are a mess" you expressed it as a concern you're both working through and asking for his feedback. This can really help as you're not pointing fingers your collaborating. (even though you're effectively steering him to what you want, you're also providing him the why and helping him think through it as well)

2
  • Thank you for this great advice, and reminder that explanations are important. Your comments have made me realized that I do not explain things as thoroughly as I once did. Part of this is that I have ran into some of the same problems in past code reviews, but I realize now that my original comments were weeks ago, may not have been remembered, and clearly didn't sink in or it wouldn't have been an issue. Thanks again! Mar 5, 2015 at 3:36
  • Anytime, I give tons of code reviews myself. Expect them to be a bit repetitive at times. (old habits die hard) Mar 5, 2015 at 15:53
3

Your text contained two telling phrases: "I see myself as a peer to the other developers" and "I see my management role as a supporting role of the team".

In other words, "I'm not a manager, I'm a team support worker"

This can be a nice relaxing job, but it isn't what you are being paid to do, and it means that your staff feel able to have a hissy-fit if they don't like what you are saying to them.

An important role of the manager is to set boundaries, and these emotional outbursts are not acceptable. Of course you should make code-reviews as non-confrontational as possible, but sooner or later you have to lay down the law, basically saying (in the nicest way possible) that you won't accept infantile behaviour - this is a serious workplace, and you're paid to do a serious job, so do it.

If this means you have to have a more distant relationship with your staff, then welcome to the real world - it is a really bad mistake to try and be friends with your staff, since sooner or later you will have to raise a disciplinary matter with them, and any semblance of friendship will crumble.

So you aren't their peer; you are their manager, and sometimes you need to remind them (and yourself) of that fact.

2

I would do some introspection. First of all code reviews can turn into nit-picky personal opinions on how things should be done. Before you comment or critique his code think of the severity of the issue. Is this a personal opinion, would the code be better but ultimately execute just the same, the code is wrong or this is critical.

With code reviews you have a limited amount of social currency before you're labeled in this developers mind of always nit picking and not adding value. The important thing is that code reviews add value. If you have a nitpick then label the comment as a nit pick.

More broadly then just code reviews. Not many people are going to be OK if you always give negative feedback, so give some positive feedback occasionally, especially in code reviews. "That's an interesting approach, I like that.", etc..

One more thing is maybe just start giving him a call with code review feedback, this developer could be stressed about how it looks to the team that you're picking apart his code so call him up talk through it. That way you can have more of a conversation and it's less high stakes than doing it in front of the whole team.

1

It usually is interpreted as personal criticism, because that's what it is. According to many programmers, code reviews are one of the most stressful and toxic features of programming jobs. Many software engineering decisions and choices are, in fact, opinions. A problem of "who reviews the reviewers" is also a thing; the reviewers tend not to realize if they are going too far while reviewing. "Code review" could indeed make a cool sounding buzzword on paper, but in practice it often struggles to fulfill its intended purpose without spoiling the atmosphere.

A few principles to have all reviewers adopt at instant:

  • no more opinions being presented as facts;
  • no more reprimands nor scolding being passed as "advice";
  • no more passive-aggressive language, which includes suggestive and judgmental questions;
  • no more snark, sarcasm, nor playing a smart@ss while reviewing;
  • no more suggestions being presented as requirements;
  • no more overwhelming focus on irrelevant details.

And also, the so called "feedback culture" is overrated. According to my experience, sadly, a lot of people interpret it as "licence for being a condescending smart@ss". As a manager, take a closer look at the culture of performing code reviews in your team and cut such behaviors short while clearly communicating that they are unacceptable.

Over time, there should hopefully be an improvement.

3
  • And just noticed this thread is 7 years old, and was just bumped a few hours ago. Approve my sincere apologies for necroposting for that reason, will be more vigilant not to do that again.
    – user132962
    Mar 8 at 2:21
  • "no more" implies there currently is this behaviour. There is no evidence of it in the question though.
    – nvoigt
    Mar 8 at 7:04
  • @nvoigt No explicit evidence of that in question, correct. But the fact how the reactions of developers being reviewed sometimes reach outright anger, suggests me that at least some of those behaviors are the case, and gives me reasonable basis to assume this is a problem that needs fixing in OP's team.
    – user132962
    Mar 8 at 20:41

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .