Skip to main content
The Workplace

Return to Answer

shortening
Source Link
Touchdown
Touchdown
  • 3.1k
  • 3
  • 11
  • 27

It sounds like there's a lack of trust present in this team. To be honest, to me it sounds like the colleagues who 'don't resist' might be doing so out of convenience since, as you say, they don't seem to care about quality and will just take the easiest path. In that regard, the colleague who 'resists' might just be disagreeing with you, and the two of you may have something in common in that you do care about quality and are willing to disagree with each other.

'Constructive criticism' is a two-way process; the one doing the criticising needs to be able to listen to the one they're criticising to find out why they did things that way. I suggest reading Stephen Covey's 7 Habits, particularly habit 5: Seek first to understand, then to be understood.

Fixing a lack of trust can't be done overnight, but here are some tips from what I've found has worked for teams I've been in. I hope that they can help you build a better atmosphere that allows people to be more open and receptive to criticism.

If some feedback is based on your opinion, make it clear that this is the case. You might not like that he wrote his code a certain way, but is there anything objectively wrong with it? At best, you can suggest that you wouldn't have done it that way and provide some reasoning, but it doesn't necessarily mean that one of you is right and the other is wrong.

If something looks odd to you, ask why it was done. There may be a valid reason, and it may just need a renamed variable or code comment to explain it better.

Ask what they think. If you see something that you'd change, instead of dictating how you think it should be done, say what you would have done and why, and ask whether they agree.

Include positive feedback as well as negative. If all that happens when your colleague pushes code is that it gets criticised, then it's not going to be something he enjoys doing, and he'll go into it with thea defensive mindset of needing to defend himself. Can you point out instances where he's done something well? Simply acknowledging a good solution can go a long way towards building that atmosphere of trust, letting him know that you're not just out to tear his work apart, but to encourage and support him.

Don't (inadvertently or otherwise) make review comments into personal attacks. Things like the tone and choice of words can determine how a piece of text comes across. For example, compare:

"This doesn't make sense."

(i.e. this is objectively wrong and you're stupid)

With:

"This isn't how I expected this to work. Can you please give some brief reasoning?"

(i.e. I don't necessarily understand or agree with your solution, but I'm not saying you're wrong, and I'm willing to listen to your explanation)

I can tell you that after working like this for a while, teams really open up and code reviews don't become dreaded; if anything they become a good way to get feedback, and for others to catch mistakes you may not have seen, which is the purpose of code reviews. When someone points out to me that there's a better way of doing something, I actually feel excited to implement it because I know it'll be an improvement to the overall code quality, and because I know that the person giving the feedback isn't out to personally attack me. I hope you can change the perspective within the team from being 'right' and 'wrong' to having valid (and valuable) differences in opinion and style.

It sounds like there's a lack of trust present in this team. To be honest, to me it sounds like the colleagues who 'don't resist' might be doing so out of convenience since, as you say, they don't seem to care about quality and will just take the easiest path. In that regard, the colleague who 'resists' might just be disagreeing with you, and the two of you may have something in common in that you do care about quality and are willing to disagree with each other.

'Constructive criticism' is a two-way process; the one doing the criticising needs to be able to listen to the one they're criticising to find out why they did things that way. I suggest reading Stephen Covey's 7 Habits, particularly habit 5: Seek first to understand, then to be understood.

Fixing a lack of trust can't be done overnight, but here are some tips from what I've found has worked for teams I've been in. I hope that they can help you build a better atmosphere that allows people to be more open and receptive to criticism.

If some feedback is based on your opinion, make it clear that this is the case. You might not like that he wrote his code a certain way, but is there anything objectively wrong with it? At best, you can suggest that you wouldn't have done it that way and provide some reasoning, but it doesn't necessarily mean that one of you is right and the other is wrong.

If something looks odd to you, ask why it was done. There may be a valid reason, and it may just need a renamed variable or code comment to explain it better.

Ask what they think. If you see something that you'd change, instead of dictating how it should be done, say what you would have done and why, and ask whether they agree.

Include positive feedback as well as negative. If all that happens when your colleague pushes code is that it gets criticised, then it's not going to be something he enjoys doing, and he'll go into it with the mindset of needing to defend himself. Can you point out instances where he's done something well? Simply acknowledging a good solution can go a long way towards building that atmosphere of trust, letting him know that you're not just out to tear his work apart, but to encourage and support him.

Don't (inadvertently or otherwise) make review comments into personal attacks. Things like the tone and choice of words can determine how a piece of text comes across. For example, compare:

"This doesn't make sense."

(i.e. this is objectively wrong and you're stupid)

With:

"This isn't how I expected this to work. Can you please give some brief reasoning?"

(i.e. I don't necessarily understand or agree with your solution, but I'm not saying you're wrong, and I'm willing to listen to your explanation)

I can tell you that after working like this for a while, teams really open up and code reviews don't become dreaded; if anything they become a good way to get feedback and for others to catch mistakes you may not have seen, which is the purpose of code reviews. When someone points out to me that there's a better way of doing something, I actually feel excited to implement it because I know it'll be an improvement to the overall code quality, and because I know that the person giving the feedback isn't out to personally attack me. I hope you can change the perspective within the team from being 'right' and 'wrong' to having valid (and valuable) differences in opinion and style.

It sounds like there's a lack of trust present in this team. To be honest, to me it sounds like the colleagues who 'don't resist' might be doing so out of convenience since, as you say, they don't seem to care about quality and will just take the easiest path. In that regard, the colleague who 'resists' might just be disagreeing with you, and the two of you may have something in common in that you do care about quality and are willing to disagree with each other.

'Constructive criticism' is a two-way process; the one doing the criticising needs to be able to listen to the one they're criticising to find out why they did things that way. I suggest reading Stephen Covey's 7 Habits, particularly habit 5: Seek first to understand, then to be understood.

Fixing a lack of trust can't be done overnight, but here are some tips from what I've found has worked for teams I've been in.

If some feedback is based on your opinion, make it clear that this is the case. You might not like that he wrote his code a certain way, but is there anything objectively wrong with it? At best, you can suggest that you wouldn't have done it that way and provide some reasoning, but it doesn't necessarily mean that one of you is right and the other is wrong.

If something looks odd to you, ask why it was done. There may be a valid reason, and it may just need a renamed variable or code comment to explain it better.

Ask what they think. If you see something that you'd change, instead of dictating how you think it should be done, say what you would have done and why, and ask whether they agree.

Include positive feedback as well as negative. If all that happens when your colleague pushes code is that it gets criticised, then it's not going to be something he enjoys doing, and he'll go into it with a defensive mindset. Can you point out instances where he's done something well? Simply acknowledging a good solution can go a long way towards building that atmosphere of trust, letting him know that you're not just out to tear his work apart, but to encourage and support him.

Don't (inadvertently or otherwise) make review comments into personal attacks. Things like the tone and choice of words can determine how a piece of text comes across. For example, compare:

"This doesn't make sense."

(i.e. this is objectively wrong and you're stupid)

With:

"This isn't how I expected this to work. Can you please give some brief reasoning?"

(i.e. I don't necessarily understand or agree with your solution, but I'm not saying you're wrong, and I'm willing to listen to your explanation)

I can tell you that after working like this for a while, teams really open up and code reviews don't become dreaded; they become a good way to get feedback, and for others to catch mistakes you may not have seen. When someone points out to me that there's a better way of doing something, I actually feel excited to implement it because I know it'll be an improvement to the overall code quality, and because I know that the person giving the feedback isn't out to personally attack me. I hope you can change the perspective within the team from being 'right' and 'wrong' to having valid (and valuable) differences in opinion and style.

Source Link
Touchdown
Touchdown
  • 3.1k
  • 3
  • 11
  • 27

It sounds like there's a lack of trust present in this team. To be honest, to me it sounds like the colleagues who 'don't resist' might be doing so out of convenience since, as you say, they don't seem to care about quality and will just take the easiest path. In that regard, the colleague who 'resists' might just be disagreeing with you, and the two of you may have something in common in that you do care about quality and are willing to disagree with each other.

'Constructive criticism' is a two-way process; the one doing the criticising needs to be able to listen to the one they're criticising to find out why they did things that way. I suggest reading Stephen Covey's 7 Habits, particularly habit 5: Seek first to understand, then to be understood.

Fixing a lack of trust can't be done overnight, but here are some tips from what I've found has worked for teams I've been in. I hope that they can help you build a better atmosphere that allows people to be more open and receptive to criticism.

If some feedback is based on your opinion, make it clear that this is the case. You might not like that he wrote his code a certain way, but is there anything objectively wrong with it? At best, you can suggest that you wouldn't have done it that way and provide some reasoning, but it doesn't necessarily mean that one of you is right and the other is wrong.

If something looks odd to you, ask why it was done. There may be a valid reason, and it may just need a renamed variable or code comment to explain it better.

Ask what they think. If you see something that you'd change, instead of dictating how it should be done, say what you would have done and why, and ask whether they agree.

Include positive feedback as well as negative. If all that happens when your colleague pushes code is that it gets criticised, then it's not going to be something he enjoys doing, and he'll go into it with the mindset of needing to defend himself. Can you point out instances where he's done something well? Simply acknowledging a good solution can go a long way towards building that atmosphere of trust, letting him know that you're not just out to tear his work apart, but to encourage and support him.

Don't (inadvertently or otherwise) make review comments into personal attacks. Things like the tone and choice of words can determine how a piece of text comes across. For example, compare:

"This doesn't make sense."

(i.e. this is objectively wrong and you're stupid)

With:

"This isn't how I expected this to work. Can you please give some brief reasoning?"

(i.e. I don't necessarily understand or agree with your solution, but I'm not saying you're wrong, and I'm willing to listen to your explanation)

I can tell you that after working like this for a while, teams really open up and code reviews don't become dreaded; if anything they become a good way to get feedback and for others to catch mistakes you may not have seen, which is the purpose of code reviews. When someone points out to me that there's a better way of doing something, I actually feel excited to implement it because I know it'll be an improvement to the overall code quality, and because I know that the person giving the feedback isn't out to personally attack me. I hope you can change the perspective within the team from being 'right' and 'wrong' to having valid (and valuable) differences in opinion and style.