Mixing
How can I help a team member who feels threatened by collective code ownership? [closed]
Clash Royale CLAN TAG#URR8PPP
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;
up vote
2
down vote
favorite
I run a team of software engineers where I try to instill the practice of collective code ownership. One team member is continuously threatened by an individual he feels is meddling in 'his code'. Both people contribute greatly to the team, but the threatened individual seems to be taking things more and more personally.
How might I defuse the situation and help the threatened person move past his feelings?
software-industry team
edited Mar 23 '13 at 21:30
yoozer8
4,10442955
asked Mar 23 '13 at 8:15
ntsh
221
closed as not constructive by Elysian Fields♦, jcmeloni, Rhys, GreenMatt, yoozer8 Mar 24 '13 at 14:30
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. If this question can be reworded to fit the rules in the help center, please edit the question.
 |Â
show 1 more comment
up vote
2
down vote
favorite
I run a team of software engineers where I try to instill the practice of collective code ownership. One team member is continuously threatened by an individual he feels is meddling in 'his code'. Both people contribute greatly to the team, but the threatened individual seems to be taking things more and more personally.
How might I defuse the situation and help the threatened person move past his feelings?
software-industry team
edited Mar 23 '13 at 21:30
yoozer8
4,10442955
asked Mar 23 '13 at 8:15
ntsh
221
closed as not constructive by Elysian Fields♦, jcmeloni, Rhys, GreenMatt, yoozer8 Mar 24 '13 at 14:30
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. If this question can be reworded to fit the rules in the help center, please edit the question.
2
Not everyone feels happy with CCO: programmers.stackexchange.com/a/88376/67140 You have two contradicting questions rolled into one here. First, you are asking about ways to defuse the situation. Second, you want to know how to make the threatened developer change his mind. I.e. you will not accept any compromise (which does make sense to you at least - CCO is your pet idea, after all). Would suggest amending the question clarifying what exactly you need.
– Deer Hunter
Mar 23 '13 at 9:25
3
Please don't downvote questions that are not obviously poor without explaining why.
– Tom W
Mar 23 '13 at 12:51
1
I guess a question saying,I would like suggestionswhen the FAQ says under close reasons,...this question will likely solicit debate, arguments, **polling**, or extended discussion.seems like a question which doesn't match the format of this site.
– Elysian Fields♦
Mar 23 '13 at 13:15
What have you done to verify that what the "meddler" is doing is actually necessary?
– Blrfl
Mar 23 '13 at 14:12
The changes were necessary to resolve a bug.
– ntsh
Mar 23 '13 at 15:20
 |Â
show 1 more comment
up vote
2
down vote
favorite
up vote
2
down vote
favorite
I run a team of software engineers where I try to instill the practice of collective code ownership. One team member is continuously threatened by an individual he feels is meddling in 'his code'. Both people contribute greatly to the team, but the threatened individual seems to be taking things more and more personally.
How might I defuse the situation and help the threatened person move past his feelings?
software-industry team
edited Mar 23 '13 at 21:30
yoozer8
4,10442955
asked Mar 23 '13 at 8:15
ntsh
221
I run a team of software engineers where I try to instill the practice of collective code ownership. One team member is continuously threatened by an individual he feels is meddling in 'his code'. Both people contribute greatly to the team, but the threatened individual seems to be taking things more and more personally.
How might I defuse the situation and help the threatened person move past his feelings?
software-industry team
edited Mar 23 '13 at 21:30
yoozer8
4,10442955
asked Mar 23 '13 at 8:15
ntsh
221
edited Mar 23 '13 at 21:30
yoozer8
4,10442955
edited Mar 23 '13 at 21:30
yoozer8
4,10442955
edited Mar 23 '13 at 21:30
yoozer8
4,10442955
4,10442955
asked Mar 23 '13 at 8:15
ntsh
221
asked Mar 23 '13 at 8:15
ntsh
221
asked Mar 23 '13 at 8:15
ntsh
221
221
closed as not constructive by Elysian Fields♦, jcmeloni, Rhys, GreenMatt, yoozer8 Mar 24 '13 at 14:30
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. If this question can be reworded to fit the rules in the help center, please edit the question.
closed as not constructive by Elysian Fields♦, jcmeloni, Rhys, GreenMatt, yoozer8 Mar 24 '13 at 14:30
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. If this question can be reworded to fit the rules in the help center, please edit the question.
2
Not everyone feels happy with CCO: programmers.stackexchange.com/a/88376/67140 You have two contradicting questions rolled into one here. First, you are asking about ways to defuse the situation. Second, you want to know how to make the threatened developer change his mind. I.e. you will not accept any compromise (which does make sense to you at least - CCO is your pet idea, after all). Would suggest amending the question clarifying what exactly you need.
– Deer Hunter
Mar 23 '13 at 9:25
3
Please don't downvote questions that are not obviously poor without explaining why.
– Tom W
Mar 23 '13 at 12:51
1
I guess a question saying,I would like suggestionswhen the FAQ says under close reasons,...this question will likely solicit debate, arguments, **polling**, or extended discussion.seems like a question which doesn't match the format of this site.
– Elysian Fields♦
Mar 23 '13 at 13:15
What have you done to verify that what the "meddler" is doing is actually necessary?
– Blrfl
Mar 23 '13 at 14:12
The changes were necessary to resolve a bug.
– ntsh
Mar 23 '13 at 15:20
 |Â
show 1 more comment
2
Not everyone feels happy with CCO: programmers.stackexchange.com/a/88376/67140 You have two contradicting questions rolled into one here. First, you are asking about ways to defuse the situation. Second, you want to know how to make the threatened developer change his mind. I.e. you will not accept any compromise (which does make sense to you at least - CCO is your pet idea, after all). Would suggest amending the question clarifying what exactly you need.
– Deer Hunter
Mar 23 '13 at 9:25
3
Please don't downvote questions that are not obviously poor without explaining why.
– Tom W
Mar 23 '13 at 12:51
1
I guess a question saying,I would like suggestionswhen the FAQ says under close reasons,...this question will likely solicit debate, arguments, **polling**, or extended discussion.seems like a question which doesn't match the format of this site.
– Elysian Fields♦
Mar 23 '13 at 13:15
What have you done to verify that what the "meddler" is doing is actually necessary?
– Blrfl
Mar 23 '13 at 14:12
The changes were necessary to resolve a bug.
– ntsh
Mar 23 '13 at 15:20
2
2
Not everyone feels happy with CCO: programmers.stackexchange.com/a/88376/67140 You have two contradicting questions rolled into one here. First, you are asking about ways to defuse the situation. Second, you want to know how to make the threatened developer change his mind. I.e. you will not accept any compromise (which does make sense to you at least - CCO is your pet idea, after all). Would suggest amending the question clarifying what exactly you need.
– Deer Hunter
Mar 23 '13 at 9:25
Not everyone feels happy with CCO: programmers.stackexchange.com/a/88376/67140 You have two contradicting questions rolled into one here. First, you are asking about ways to defuse the situation. Second, you want to know how to make the threatened developer change his mind. I.e. you will not accept any compromise (which does make sense to you at least - CCO is your pet idea, after all). Would suggest amending the question clarifying what exactly you need.
– Deer Hunter
Mar 23 '13 at 9:25
3
3
Please don't downvote questions that are not obviously poor without explaining why.
– Tom W
Mar 23 '13 at 12:51
Please don't downvote questions that are not obviously poor without explaining why.
– Tom W
Mar 23 '13 at 12:51
1
1
I guess a question saying,
I would like suggestions when the FAQ says under close reasons, ...this question will likely solicit debate, arguments, **polling**, or extended discussion. seems like a question which doesn't match the format of this site.– Elysian Fields♦
Mar 23 '13 at 13:15
I guess a question saying,
I would like suggestions when the FAQ says under close reasons, ...this question will likely solicit debate, arguments, **polling**, or extended discussion. seems like a question which doesn't match the format of this site.– Elysian Fields♦
Mar 23 '13 at 13:15
What have you done to verify that what the "meddler" is doing is actually necessary?
– Blrfl
Mar 23 '13 at 14:12
What have you done to verify that what the "meddler" is doing is actually necessary?
– Blrfl
Mar 23 '13 at 14:12
The changes were necessary to resolve a bug.
– ntsh
Mar 23 '13 at 15:20
The changes were necessary to resolve a bug.
– ntsh
Mar 23 '13 at 15:20
 |Â
show 1 more comment
3 Answers
3
active
oldest
votes
up vote
1
down vote
In what circumstances are these code changes being made? For example, do you practice internal code review? Making code changes based on the recommendations of a formal code review process is quite different to a colleague committing uninvited changes off their own bat without any change control process.
If you do control these changes, ask the team member to explain why they think the changes are unreasonable in the context of proper code review. This gives them an avenue to voice legitimate concerns (if they have any) and simultaneously gives you justification for silencing unreasonable ones.
If however these changes are coming about unplanned and uninvited, well, Don't do that. He'd be quite justified in resenting interference in these circumstances - and it probably isn't about 'his' code, more to do with the uncontrolled propagation of changes.
answered Mar 23 '13 at 9:20
Tom W
954410
There is no formal code review process but the changes were to resolve a specific bug that was documented and scheduled.
– ntsh
Mar 23 '13 at 15:54
add a comment |Â
up vote
0
down vote
Be neutral: First both are great value contributors to the team. When ever such conflict occurs the first thing in the process of diffuse the situation is be neutral and don't be on either side of the one.
Have an Individual One on One meeting: Set up an individual one one meeting and listens to their concerns and their problems about this responsibility. Make clear that the objective of this activity. Educate both of them. Educate or counsel the individual who feels is meddling in his code so that he should not feel like meddling . Similarly educate the threatened team member, how he should act when other persons threatens. Educate both of them is don't take things personally.
Review the process and improve: Review the process or activities what they are following currently to achieve the objective of CCO. May be one person feels that a piece of code is great and other feels it is just crap. May be one person just write sample code and check in and another person immediately review and put his review comments. The person feels that meddling as it is not final piece. If you don't have clear guide lines, clear process these conflicts occurs. Hence define clear guidelines and process for this activity which should not give any scope for conflicts
answered Mar 23 '13 at 12:33
Babu
3,28332059
3
I absolutely hate having people in a leadership position who refuse to show any leadership (be neutral). Either the person who fixed the bug did it in a way that didn't corrupt the intended architecture, or they did. In the first case, the "threatened" developer needs to be told to get over it, and in the second, something needs to be put in place to make sure devs understand each others' constructions and build with, not against, them. The only reason to be neutral is if you're not qualified to determine which is true.
– Amy Blankenship
Mar 24 '13 at 12:55
add a comment |Â
up vote
0
down vote
Maybe the developer who feels threatened doesn't understand the situation. You write that you appreciate both of them, but does (s)he know that?
Also, maybe they have different strengths that come into play here. On many teams, I've seen people who excel at writing stuff from scratch with a crystal clear architecture in mind, but when it comes to the nitty gritty stuff where bugs start to turn up, they kind of fade out. If that is the case, explain to the two team members that what you see is that they complement each other.
answered Mar 23 '13 at 21:06
Michael Zedeler
42723
3
There's also such a thing as someone who wrote something from scratch with a crystal clear architecture in mind, only to see that architecture destroyed/circumvented by another teammember who either didn't understand the architecture or didn't care. It's possible that this is what's happening here, and if that is the case then the person is quite right to object. With no code review in place, s/he has no way to prevent this from happening.
– Amy Blankenship
Mar 23 '13 at 23:11
The problem with reviews is that in a hostile environment, this can feel much like being in front of a firing squad. So a review in this context can quickly turn into placing blame - they aren't necessarily ready for it yet. So I think it is better to make sure that the defensive developer isn't doing this out of insecurity first and making sure that they both understand that they are needed on the team. Once thats done, you can start reviewing code.
– Michael Zedeler
Mar 24 '13 at 0:15
1
@MichaelZedeler: If the environment is hostile enough for code review to fail, it is surely toxic for CCO.
– Deer Hunter
Mar 24 '13 at 5:39
Plus, it IS possible to set ground rules for code reviews and hold people to it.
– Amy Blankenship
Mar 24 '13 at 12:50
@AmyBlankenship: maybe I am just not good enough at code reviews or haven't seen others do it right yet :)
– Michael Zedeler
Mar 24 '13 at 19:33
add a comment |Â
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
1
down vote
In what circumstances are these code changes being made? For example, do you practice internal code review? Making code changes based on the recommendations of a formal code review process is quite different to a colleague committing uninvited changes off their own bat without any change control process.
If you do control these changes, ask the team member to explain why they think the changes are unreasonable in the context of proper code review. This gives them an avenue to voice legitimate concerns (if they have any) and simultaneously gives you justification for silencing unreasonable ones.
If however these changes are coming about unplanned and uninvited, well, Don't do that. He'd be quite justified in resenting interference in these circumstances - and it probably isn't about 'his' code, more to do with the uncontrolled propagation of changes.
answered Mar 23 '13 at 9:20
Tom W
954410
There is no formal code review process but the changes were to resolve a specific bug that was documented and scheduled.
– ntsh
Mar 23 '13 at 15:54
add a comment |Â
up vote
1
down vote
In what circumstances are these code changes being made? For example, do you practice internal code review? Making code changes based on the recommendations of a formal code review process is quite different to a colleague committing uninvited changes off their own bat without any change control process.
If you do control these changes, ask the team member to explain why they think the changes are unreasonable in the context of proper code review. This gives them an avenue to voice legitimate concerns (if they have any) and simultaneously gives you justification for silencing unreasonable ones.
If however these changes are coming about unplanned and uninvited, well, Don't do that. He'd be quite justified in resenting interference in these circumstances - and it probably isn't about 'his' code, more to do with the uncontrolled propagation of changes.
answered Mar 23 '13 at 9:20
Tom W
954410
There is no formal code review process but the changes were to resolve a specific bug that was documented and scheduled.
– ntsh
Mar 23 '13 at 15:54
add a comment |Â
up vote
1
down vote
up vote
1
down vote
In what circumstances are these code changes being made? For example, do you practice internal code review? Making code changes based on the recommendations of a formal code review process is quite different to a colleague committing uninvited changes off their own bat without any change control process.
If you do control these changes, ask the team member to explain why they think the changes are unreasonable in the context of proper code review. This gives them an avenue to voice legitimate concerns (if they have any) and simultaneously gives you justification for silencing unreasonable ones.
If however these changes are coming about unplanned and uninvited, well, Don't do that. He'd be quite justified in resenting interference in these circumstances - and it probably isn't about 'his' code, more to do with the uncontrolled propagation of changes.
answered Mar 23 '13 at 9:20
Tom W
954410
In what circumstances are these code changes being made? For example, do you practice internal code review? Making code changes based on the recommendations of a formal code review process is quite different to a colleague committing uninvited changes off their own bat without any change control process.
If you do control these changes, ask the team member to explain why they think the changes are unreasonable in the context of proper code review. This gives them an avenue to voice legitimate concerns (if they have any) and simultaneously gives you justification for silencing unreasonable ones.
If however these changes are coming about unplanned and uninvited, well, Don't do that. He'd be quite justified in resenting interference in these circumstances - and it probably isn't about 'his' code, more to do with the uncontrolled propagation of changes.
answered Mar 23 '13 at 9:20
Tom W
954410
answered Mar 23 '13 at 9:20
Tom W
954410
answered Mar 23 '13 at 9:20
Tom W
954410
answered Mar 23 '13 at 9:20
Tom W
954410
954410
There is no formal code review process but the changes were to resolve a specific bug that was documented and scheduled.
– ntsh
Mar 23 '13 at 15:54
add a comment |Â
There is no formal code review process but the changes were to resolve a specific bug that was documented and scheduled.
– ntsh
Mar 23 '13 at 15:54
There is no formal code review process but the changes were to resolve a specific bug that was documented and scheduled.
– ntsh
Mar 23 '13 at 15:54
There is no formal code review process but the changes were to resolve a specific bug that was documented and scheduled.
– ntsh
Mar 23 '13 at 15:54
add a comment |Â
up vote
0
down vote
Be neutral: First both are great value contributors to the team. When ever such conflict occurs the first thing in the process of diffuse the situation is be neutral and don't be on either side of the one.
Have an Individual One on One meeting: Set up an individual one one meeting and listens to their concerns and their problems about this responsibility. Make clear that the objective of this activity. Educate both of them. Educate or counsel the individual who feels is meddling in his code so that he should not feel like meddling . Similarly educate the threatened team member, how he should act when other persons threatens. Educate both of them is don't take things personally.
Review the process and improve: Review the process or activities what they are following currently to achieve the objective of CCO. May be one person feels that a piece of code is great and other feels it is just crap. May be one person just write sample code and check in and another person immediately review and put his review comments. The person feels that meddling as it is not final piece. If you don't have clear guide lines, clear process these conflicts occurs. Hence define clear guidelines and process for this activity which should not give any scope for conflicts
answered Mar 23 '13 at 12:33
Babu
3,28332059
3
I absolutely hate having people in a leadership position who refuse to show any leadership (be neutral). Either the person who fixed the bug did it in a way that didn't corrupt the intended architecture, or they did. In the first case, the "threatened" developer needs to be told to get over it, and in the second, something needs to be put in place to make sure devs understand each others' constructions and build with, not against, them. The only reason to be neutral is if you're not qualified to determine which is true.
– Amy Blankenship
Mar 24 '13 at 12:55
add a comment |Â
up vote
0
down vote
Be neutral: First both are great value contributors to the team. When ever such conflict occurs the first thing in the process of diffuse the situation is be neutral and don't be on either side of the one.
Have an Individual One on One meeting: Set up an individual one one meeting and listens to their concerns and their problems about this responsibility. Make clear that the objective of this activity. Educate both of them. Educate or counsel the individual who feels is meddling in his code so that he should not feel like meddling . Similarly educate the threatened team member, how he should act when other persons threatens. Educate both of them is don't take things personally.
Review the process and improve: Review the process or activities what they are following currently to achieve the objective of CCO. May be one person feels that a piece of code is great and other feels it is just crap. May be one person just write sample code and check in and another person immediately review and put his review comments. The person feels that meddling as it is not final piece. If you don't have clear guide lines, clear process these conflicts occurs. Hence define clear guidelines and process for this activity which should not give any scope for conflicts
answered Mar 23 '13 at 12:33
Babu
3,28332059
3
I absolutely hate having people in a leadership position who refuse to show any leadership (be neutral). Either the person who fixed the bug did it in a way that didn't corrupt the intended architecture, or they did. In the first case, the "threatened" developer needs to be told to get over it, and in the second, something needs to be put in place to make sure devs understand each others' constructions and build with, not against, them. The only reason to be neutral is if you're not qualified to determine which is true.
– Amy Blankenship
Mar 24 '13 at 12:55
add a comment |Â
up vote
0
down vote
up vote
0
down vote
Be neutral: First both are great value contributors to the team. When ever such conflict occurs the first thing in the process of diffuse the situation is be neutral and don't be on either side of the one.
Have an Individual One on One meeting: Set up an individual one one meeting and listens to their concerns and their problems about this responsibility. Make clear that the objective of this activity. Educate both of them. Educate or counsel the individual who feels is meddling in his code so that he should not feel like meddling . Similarly educate the threatened team member, how he should act when other persons threatens. Educate both of them is don't take things personally.
Review the process and improve: Review the process or activities what they are following currently to achieve the objective of CCO. May be one person feels that a piece of code is great and other feels it is just crap. May be one person just write sample code and check in and another person immediately review and put his review comments. The person feels that meddling as it is not final piece. If you don't have clear guide lines, clear process these conflicts occurs. Hence define clear guidelines and process for this activity which should not give any scope for conflicts
answered Mar 23 '13 at 12:33
Babu
3,28332059
Be neutral: First both are great value contributors to the team. When ever such conflict occurs the first thing in the process of diffuse the situation is be neutral and don't be on either side of the one.
Have an Individual One on One meeting: Set up an individual one one meeting and listens to their concerns and their problems about this responsibility. Make clear that the objective of this activity. Educate both of them. Educate or counsel the individual who feels is meddling in his code so that he should not feel like meddling . Similarly educate the threatened team member, how he should act when other persons threatens. Educate both of them is don't take things personally.
Review the process and improve: Review the process or activities what they are following currently to achieve the objective of CCO. May be one person feels that a piece of code is great and other feels it is just crap. May be one person just write sample code and check in and another person immediately review and put his review comments. The person feels that meddling as it is not final piece. If you don't have clear guide lines, clear process these conflicts occurs. Hence define clear guidelines and process for this activity which should not give any scope for conflicts
answered Mar 23 '13 at 12:33
Babu
3,28332059
answered Mar 23 '13 at 12:33
Babu
3,28332059
answered Mar 23 '13 at 12:33
Babu
3,28332059
answered Mar 23 '13 at 12:33
Babu
3,28332059
3,28332059
3
I absolutely hate having people in a leadership position who refuse to show any leadership (be neutral). Either the person who fixed the bug did it in a way that didn't corrupt the intended architecture, or they did. In the first case, the "threatened" developer needs to be told to get over it, and in the second, something needs to be put in place to make sure devs understand each others' constructions and build with, not against, them. The only reason to be neutral is if you're not qualified to determine which is true.
– Amy Blankenship
Mar 24 '13 at 12:55
add a comment |Â
3
I absolutely hate having people in a leadership position who refuse to show any leadership (be neutral). Either the person who fixed the bug did it in a way that didn't corrupt the intended architecture, or they did. In the first case, the "threatened" developer needs to be told to get over it, and in the second, something needs to be put in place to make sure devs understand each others' constructions and build with, not against, them. The only reason to be neutral is if you're not qualified to determine which is true.
– Amy Blankenship
Mar 24 '13 at 12:55
3
3
I absolutely hate having people in a leadership position who refuse to show any leadership (be neutral). Either the person who fixed the bug did it in a way that didn't corrupt the intended architecture, or they did. In the first case, the "threatened" developer needs to be told to get over it, and in the second, something needs to be put in place to make sure devs understand each others' constructions and build with, not against, them. The only reason to be neutral is if you're not qualified to determine which is true.
– Amy Blankenship
Mar 24 '13 at 12:55
I absolutely hate having people in a leadership position who refuse to show any leadership (be neutral). Either the person who fixed the bug did it in a way that didn't corrupt the intended architecture, or they did. In the first case, the "threatened" developer needs to be told to get over it, and in the second, something needs to be put in place to make sure devs understand each others' constructions and build with, not against, them. The only reason to be neutral is if you're not qualified to determine which is true.
– Amy Blankenship
Mar 24 '13 at 12:55
add a comment |Â
up vote
0
down vote
Maybe the developer who feels threatened doesn't understand the situation. You write that you appreciate both of them, but does (s)he know that?
Also, maybe they have different strengths that come into play here. On many teams, I've seen people who excel at writing stuff from scratch with a crystal clear architecture in mind, but when it comes to the nitty gritty stuff where bugs start to turn up, they kind of fade out. If that is the case, explain to the two team members that what you see is that they complement each other.
answered Mar 23 '13 at 21:06
Michael Zedeler
42723
3
There's also such a thing as someone who wrote something from scratch with a crystal clear architecture in mind, only to see that architecture destroyed/circumvented by another teammember who either didn't understand the architecture or didn't care. It's possible that this is what's happening here, and if that is the case then the person is quite right to object. With no code review in place, s/he has no way to prevent this from happening.
– Amy Blankenship
Mar 23 '13 at 23:11
The problem with reviews is that in a hostile environment, this can feel much like being in front of a firing squad. So a review in this context can quickly turn into placing blame - they aren't necessarily ready for it yet. So I think it is better to make sure that the defensive developer isn't doing this out of insecurity first and making sure that they both understand that they are needed on the team. Once thats done, you can start reviewing code.
– Michael Zedeler
Mar 24 '13 at 0:15
1
@MichaelZedeler: If the environment is hostile enough for code review to fail, it is surely toxic for CCO.
– Deer Hunter
Mar 24 '13 at 5:39
Plus, it IS possible to set ground rules for code reviews and hold people to it.
– Amy Blankenship
Mar 24 '13 at 12:50
@AmyBlankenship: maybe I am just not good enough at code reviews or haven't seen others do it right yet :)
– Michael Zedeler
Mar 24 '13 at 19:33
add a comment |Â
up vote
0
down vote
Maybe the developer who feels threatened doesn't understand the situation. You write that you appreciate both of them, but does (s)he know that?
Also, maybe they have different strengths that come into play here. On many teams, I've seen people who excel at writing stuff from scratch with a crystal clear architecture in mind, but when it comes to the nitty gritty stuff where bugs start to turn up, they kind of fade out. If that is the case, explain to the two team members that what you see is that they complement each other.
answered Mar 23 '13 at 21:06
Michael Zedeler
42723
3
There's also such a thing as someone who wrote something from scratch with a crystal clear architecture in mind, only to see that architecture destroyed/circumvented by another teammember who either didn't understand the architecture or didn't care. It's possible that this is what's happening here, and if that is the case then the person is quite right to object. With no code review in place, s/he has no way to prevent this from happening.
– Amy Blankenship
Mar 23 '13 at 23:11
The problem with reviews is that in a hostile environment, this can feel much like being in front of a firing squad. So a review in this context can quickly turn into placing blame - they aren't necessarily ready for it yet. So I think it is better to make sure that the defensive developer isn't doing this out of insecurity first and making sure that they both understand that they are needed on the team. Once thats done, you can start reviewing code.
– Michael Zedeler
Mar 24 '13 at 0:15
1
@MichaelZedeler: If the environment is hostile enough for code review to fail, it is surely toxic for CCO.
– Deer Hunter
Mar 24 '13 at 5:39
Plus, it IS possible to set ground rules for code reviews and hold people to it.
– Amy Blankenship
Mar 24 '13 at 12:50
@AmyBlankenship: maybe I am just not good enough at code reviews or haven't seen others do it right yet :)
– Michael Zedeler
Mar 24 '13 at 19:33
add a comment |Â
up vote
0
down vote
up vote
0
down vote
Maybe the developer who feels threatened doesn't understand the situation. You write that you appreciate both of them, but does (s)he know that?
Also, maybe they have different strengths that come into play here. On many teams, I've seen people who excel at writing stuff from scratch with a crystal clear architecture in mind, but when it comes to the nitty gritty stuff where bugs start to turn up, they kind of fade out. If that is the case, explain to the two team members that what you see is that they complement each other.
answered Mar 23 '13 at 21:06
Michael Zedeler
42723
Maybe the developer who feels threatened doesn't understand the situation. You write that you appreciate both of them, but does (s)he know that?
Also, maybe they have different strengths that come into play here. On many teams, I've seen people who excel at writing stuff from scratch with a crystal clear architecture in mind, but when it comes to the nitty gritty stuff where bugs start to turn up, they kind of fade out. If that is the case, explain to the two team members that what you see is that they complement each other.
answered Mar 23 '13 at 21:06
Michael Zedeler
42723
answered Mar 23 '13 at 21:06
Michael Zedeler
42723
answered Mar 23 '13 at 21:06
Michael Zedeler
42723
answered Mar 23 '13 at 21:06
Michael Zedeler
42723
42723
3
There's also such a thing as someone who wrote something from scratch with a crystal clear architecture in mind, only to see that architecture destroyed/circumvented by another teammember who either didn't understand the architecture or didn't care. It's possible that this is what's happening here, and if that is the case then the person is quite right to object. With no code review in place, s/he has no way to prevent this from happening.
– Amy Blankenship
Mar 23 '13 at 23:11
The problem with reviews is that in a hostile environment, this can feel much like being in front of a firing squad. So a review in this context can quickly turn into placing blame - they aren't necessarily ready for it yet. So I think it is better to make sure that the defensive developer isn't doing this out of insecurity first and making sure that they both understand that they are needed on the team. Once thats done, you can start reviewing code.
– Michael Zedeler
Mar 24 '13 at 0:15
1
@MichaelZedeler: If the environment is hostile enough for code review to fail, it is surely toxic for CCO.
– Deer Hunter
Mar 24 '13 at 5:39
Plus, it IS possible to set ground rules for code reviews and hold people to it.
– Amy Blankenship
Mar 24 '13 at 12:50
@AmyBlankenship: maybe I am just not good enough at code reviews or haven't seen others do it right yet :)
– Michael Zedeler
Mar 24 '13 at 19:33
add a comment |Â
3
There's also such a thing as someone who wrote something from scratch with a crystal clear architecture in mind, only to see that architecture destroyed/circumvented by another teammember who either didn't understand the architecture or didn't care. It's possible that this is what's happening here, and if that is the case then the person is quite right to object. With no code review in place, s/he has no way to prevent this from happening.
– Amy Blankenship
Mar 23 '13 at 23:11
The problem with reviews is that in a hostile environment, this can feel much like being in front of a firing squad. So a review in this context can quickly turn into placing blame - they aren't necessarily ready for it yet. So I think it is better to make sure that the defensive developer isn't doing this out of insecurity first and making sure that they both understand that they are needed on the team. Once thats done, you can start reviewing code.
– Michael Zedeler
Mar 24 '13 at 0:15
1
@MichaelZedeler: If the environment is hostile enough for code review to fail, it is surely toxic for CCO.
– Deer Hunter
Mar 24 '13 at 5:39
Plus, it IS possible to set ground rules for code reviews and hold people to it.
– Amy Blankenship
Mar 24 '13 at 12:50
@AmyBlankenship: maybe I am just not good enough at code reviews or haven't seen others do it right yet :)
– Michael Zedeler
Mar 24 '13 at 19:33
3
3
There's also such a thing as someone who wrote something from scratch with a crystal clear architecture in mind, only to see that architecture destroyed/circumvented by another teammember who either didn't understand the architecture or didn't care. It's possible that this is what's happening here, and if that is the case then the person is quite right to object. With no code review in place, s/he has no way to prevent this from happening.
– Amy Blankenship
Mar 23 '13 at 23:11
There's also such a thing as someone who wrote something from scratch with a crystal clear architecture in mind, only to see that architecture destroyed/circumvented by another teammember who either didn't understand the architecture or didn't care. It's possible that this is what's happening here, and if that is the case then the person is quite right to object. With no code review in place, s/he has no way to prevent this from happening.
– Amy Blankenship
Mar 23 '13 at 23:11
The problem with reviews is that in a hostile environment, this can feel much like being in front of a firing squad. So a review in this context can quickly turn into placing blame - they aren't necessarily ready for it yet. So I think it is better to make sure that the defensive developer isn't doing this out of insecurity first and making sure that they both understand that they are needed on the team. Once thats done, you can start reviewing code.
– Michael Zedeler
Mar 24 '13 at 0:15
The problem with reviews is that in a hostile environment, this can feel much like being in front of a firing squad. So a review in this context can quickly turn into placing blame - they aren't necessarily ready for it yet. So I think it is better to make sure that the defensive developer isn't doing this out of insecurity first and making sure that they both understand that they are needed on the team. Once thats done, you can start reviewing code.
– Michael Zedeler
Mar 24 '13 at 0:15
1
1
@MichaelZedeler: If the environment is hostile enough for code review to fail, it is surely toxic for CCO.
– Deer Hunter
Mar 24 '13 at 5:39
@MichaelZedeler: If the environment is hostile enough for code review to fail, it is surely toxic for CCO.
– Deer Hunter
Mar 24 '13 at 5:39
Plus, it IS possible to set ground rules for code reviews and hold people to it.
– Amy Blankenship
Mar 24 '13 at 12:50
Plus, it IS possible to set ground rules for code reviews and hold people to it.
– Amy Blankenship
Mar 24 '13 at 12:50
@AmyBlankenship: maybe I am just not good enough at code reviews or haven't seen others do it right yet :)
– Michael Zedeler
Mar 24 '13 at 19:33
@AmyBlankenship: maybe I am just not good enough at code reviews or haven't seen others do it right yet :)
– Michael Zedeler
Mar 24 '13 at 19:33
add a comment |Â
2
Not everyone feels happy with CCO: programmers.stackexchange.com/a/88376/67140 You have two contradicting questions rolled into one here. First, you are asking about ways to defuse the situation. Second, you want to know how to make the threatened developer change his mind. I.e. you will not accept any compromise (which does make sense to you at least - CCO is your pet idea, after all). Would suggest amending the question clarifying what exactly you need.
– Deer Hunter
Mar 23 '13 at 9:25
3
Please don't downvote questions that are not obviously poor without explaining why.
– Tom W
Mar 23 '13 at 12:51
1
I guess a question saying,
I would like suggestionswhen the FAQ says under close reasons,...this question will likely solicit debate, arguments, **polling**, or extended discussion.seems like a question which doesn't match the format of this site.– Elysian Fields♦
Mar 23 '13 at 13:15
What have you done to verify that what the "meddler" is doing is actually necessary?
– Blrfl
Mar 23 '13 at 14:12
The changes were necessary to resolve a bug.
– ntsh
Mar 23 '13 at 15:20