Mixing
Providing constructive feedback for someone who interprets it as personal criticism
Clash Royale CLAN TAG#URR8PPP
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;
up vote
2
down vote
favorite
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?
management performance-reviews performance
asked Mar 4 '15 at 20:42
user0123456789abcdef
285
suggest improvements |Â
up vote
2
down vote
favorite
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?
management performance-reviews performance
asked Mar 4 '15 at 20:42
user0123456789abcdef
285
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 '15 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.
– user0123456789abcdef
Mar 5 '15 at 3:41
suggest improvements |Â
up vote
2
down vote
favorite
up vote
2
down vote
favorite
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?
management performance-reviews performance
asked Mar 4 '15 at 20:42
user0123456789abcdef
285
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?
management performance-reviews performance
asked Mar 4 '15 at 20:42
user0123456789abcdef
285
asked Mar 4 '15 at 20:42
user0123456789abcdef
285
asked Mar 4 '15 at 20:42
user0123456789abcdef
285
asked Mar 4 '15 at 20:42
user0123456789abcdef
285
285
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 '15 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.
– user0123456789abcdef
Mar 5 '15 at 3:41
suggest improvements |Â
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 '15 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.
– user0123456789abcdef
Mar 5 '15 at 3:41
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 '15 at 21:07
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 '15 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.
– user0123456789abcdef
Mar 5 '15 at 3:41
@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.
– user0123456789abcdef
Mar 5 '15 at 3:41
suggest improvements |Â
2 Answers
2
active
oldest
votes
up vote
4
down vote
accepted
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 rag-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 bitchy 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.
answered Mar 4 '15 at 21:14
Telastyn
33.9k977120
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 '15 at 21:53
@ColleenV - I mentioned that at the end of my second non-disclaimer paragraph? Was it not clear?
– Telastyn
Mar 4 '15 at 21:55
Sorry, I must have missed it trying to scroll through on my mobile. I completely agree with your answer, and theparticularly when I am reviewing itin 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 '15 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!
– user0123456789abcdef
Mar 5 '15 at 3:33
suggest improvements |Â
up vote
0
down vote
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, ect
The key to giving criticism is 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)
answered Mar 4 '15 at 22:08
RualStorge
9,5372231
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!
– user0123456789abcdef
Mar 5 '15 at 3:36
Anytime, I give tons of code reviews myself. Expect them to be a bit repetitive at times. (old habits die hard)
– RualStorge
Mar 5 '15 at 15:53
suggest improvements |Â
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
4
down vote
accepted
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 rag-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 bitchy 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.
answered Mar 4 '15 at 21:14
Telastyn
33.9k977120
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 '15 at 21:53
@ColleenV - I mentioned that at the end of my second non-disclaimer paragraph? Was it not clear?
– Telastyn
Mar 4 '15 at 21:55
Sorry, I must have missed it trying to scroll through on my mobile. I completely agree with your answer, and theparticularly when I am reviewing itin 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 '15 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!
– user0123456789abcdef
Mar 5 '15 at 3:33
suggest improvements |Â
up vote
4
down vote
accepted
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 rag-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 bitchy 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.
answered Mar 4 '15 at 21:14
Telastyn
33.9k977120
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 '15 at 21:53
@ColleenV - I mentioned that at the end of my second non-disclaimer paragraph? Was it not clear?
– Telastyn
Mar 4 '15 at 21:55
Sorry, I must have missed it trying to scroll through on my mobile. I completely agree with your answer, and theparticularly when I am reviewing itin 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 '15 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!
– user0123456789abcdef
Mar 5 '15 at 3:33
suggest improvements |Â
up vote
4
down vote
accepted
up vote
4
down vote
accepted
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 rag-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 bitchy 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.
answered Mar 4 '15 at 21:14
Telastyn
33.9k977120
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 rag-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 bitchy 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.
answered Mar 4 '15 at 21:14
Telastyn
33.9k977120
answered Mar 4 '15 at 21:14
Telastyn
33.9k977120
answered Mar 4 '15 at 21:14
Telastyn
33.9k977120
answered Mar 4 '15 at 21:14
Telastyn
33.9k977120
33.9k977120
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 '15 at 21:53
@ColleenV - I mentioned that at the end of my second non-disclaimer paragraph? Was it not clear?
– Telastyn
Mar 4 '15 at 21:55
Sorry, I must have missed it trying to scroll through on my mobile. I completely agree with your answer, and theparticularly when I am reviewing itin 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 '15 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!
– user0123456789abcdef
Mar 5 '15 at 3:33
suggest improvements |Â
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 '15 at 21:53
@ColleenV - I mentioned that at the end of my second non-disclaimer paragraph? Was it not clear?
– Telastyn
Mar 4 '15 at 21:55
Sorry, I must have missed it trying to scroll through on my mobile. I completely agree with your answer, and theparticularly when I am reviewing itin 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 '15 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!
– user0123456789abcdef
Mar 5 '15 at 3:33
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 '15 at 21:53
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 '15 at 21:53
@ColleenV - I mentioned that at the end of my second non-disclaimer paragraph? Was it not clear?
– Telastyn
Mar 4 '15 at 21:55
@ColleenV - I mentioned that at the end of my second non-disclaimer paragraph? Was it not clear?
– Telastyn
Mar 4 '15 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 '15 at 23:20
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 '15 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!
– user0123456789abcdef
Mar 5 '15 at 3:33
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!
– user0123456789abcdef
Mar 5 '15 at 3:33
suggest improvements |Â
up vote
0
down vote
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, ect
The key to giving criticism is 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)
answered Mar 4 '15 at 22:08
RualStorge
9,5372231
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!
– user0123456789abcdef
Mar 5 '15 at 3:36
Anytime, I give tons of code reviews myself. Expect them to be a bit repetitive at times. (old habits die hard)
– RualStorge
Mar 5 '15 at 15:53
suggest improvements |Â
up vote
0
down vote
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, ect
The key to giving criticism is 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)
answered Mar 4 '15 at 22:08
RualStorge
9,5372231
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!
– user0123456789abcdef
Mar 5 '15 at 3:36
Anytime, I give tons of code reviews myself. Expect them to be a bit repetitive at times. (old habits die hard)
– RualStorge
Mar 5 '15 at 15:53
suggest improvements |Â
up vote
0
down vote
up vote
0
down vote
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, ect
The key to giving criticism is 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)
answered Mar 4 '15 at 22:08
RualStorge
9,5372231
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, ect
The key to giving criticism is 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)
answered Mar 4 '15 at 22:08
RualStorge
9,5372231
answered Mar 4 '15 at 22:08
RualStorge
9,5372231
answered Mar 4 '15 at 22:08
RualStorge
9,5372231
answered Mar 4 '15 at 22:08
RualStorge
9,5372231
9,5372231
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!
– user0123456789abcdef
Mar 5 '15 at 3:36
Anytime, I give tons of code reviews myself. Expect them to be a bit repetitive at times. (old habits die hard)
– RualStorge
Mar 5 '15 at 15:53
suggest improvements |Â
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!
– user0123456789abcdef
Mar 5 '15 at 3:36
Anytime, I give tons of code reviews myself. Expect them to be a bit repetitive at times. (old habits die hard)
– RualStorge
Mar 5 '15 at 15:53
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!
– user0123456789abcdef
Mar 5 '15 at 3:36
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!
– user0123456789abcdef
Mar 5 '15 at 3:36
Anytime, I give tons of code reviews myself. Expect them to be a bit repetitive at times. (old habits die hard)
– RualStorge
Mar 5 '15 at 15:53
Anytime, I give tons of code reviews myself. Expect them to be a bit repetitive at times. (old habits die hard)
– RualStorge
Mar 5 '15 at 15:53
suggest improvements |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fworkplace.stackexchange.com%2fquestions%2f42264%2fproviding-constructive-feedback-for-someone-who-interprets-it-as-personal-critic%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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 '15 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.
– user0123456789abcdef
Mar 5 '15 at 3:41