Mixing
How do I politely tell a coworker to only focus on his portion of the work?
Clash Royale CLAN TAG#URR8PPP
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;
up vote
3
down vote
favorite
I've been working on a software project for a few months now with a very small team (and by small, I mean there was an extended period of time where I was the only developer). Our working dynamic is excellent for the most part, as each developer has a different sector that they work in (frontend, backend, database, etc.) and there's very little overlap, so conflicts are minimal.
Recently we brought another developer in to do work in another area on the project, and thus far their work has been great. However, they are starting to reach out and alter code in other people's spaces, including my own. While the code they're writing isn't broken, it introduces some clashes, such as when they started rewriting some of the frontend/backend architecture without consulting anyone.
The biggest benefits of having each person "own" a certain portion of the code is that 1) everything in that portion of the code has a similar logic and style to it, making it more easy to understand, and 2) the person working in that area can be sure they have absolute understanding of all the moving pieces in that section. That's something that is starting to change with this new development.
While I am not the manager or owner of the project, I am the team lead, so I think this falls into my area of responsibility. So my questions are:
- Am I overreacting to something that is not really a major issue?
- If I am not overreacting, what is the best way to correct this person without discouraging them? Again, they do fine work and I don't want to create any hostility.
EDIT: the wording of my question has led several people to believe that we are intentionally obscuring how parts of the code work so that only one person understands it. This is not at all the case. We have learned the hard way the importance of spreading knowledge around. We have daily stand ups and source control. What I mean is that we have one person working on particular sections of the code, because 1) it is easier to create consistent code that all operates in a similar manner, and 2) again, we are a very small team with a not-small task on our hands, and a harsh deadline. Specialization, combined with regular communication, breeds efficiency.
FURTHER EDIT: I suppose a better phrasing would be "how do I politely tell a coworker to only focus on his assigned tasks?"
software-industry coworker
asked May 4 '16 at 20:39
TheSoundDefense
2,26731420
 |Â
show 1 more comment
up vote
3
down vote
favorite
I've been working on a software project for a few months now with a very small team (and by small, I mean there was an extended period of time where I was the only developer). Our working dynamic is excellent for the most part, as each developer has a different sector that they work in (frontend, backend, database, etc.) and there's very little overlap, so conflicts are minimal.
Recently we brought another developer in to do work in another area on the project, and thus far their work has been great. However, they are starting to reach out and alter code in other people's spaces, including my own. While the code they're writing isn't broken, it introduces some clashes, such as when they started rewriting some of the frontend/backend architecture without consulting anyone.
The biggest benefits of having each person "own" a certain portion of the code is that 1) everything in that portion of the code has a similar logic and style to it, making it more easy to understand, and 2) the person working in that area can be sure they have absolute understanding of all the moving pieces in that section. That's something that is starting to change with this new development.
While I am not the manager or owner of the project, I am the team lead, so I think this falls into my area of responsibility. So my questions are:
- Am I overreacting to something that is not really a major issue?
- If I am not overreacting, what is the best way to correct this person without discouraging them? Again, they do fine work and I don't want to create any hostility.
EDIT: the wording of my question has led several people to believe that we are intentionally obscuring how parts of the code work so that only one person understands it. This is not at all the case. We have learned the hard way the importance of spreading knowledge around. We have daily stand ups and source control. What I mean is that we have one person working on particular sections of the code, because 1) it is easier to create consistent code that all operates in a similar manner, and 2) again, we are a very small team with a not-small task on our hands, and a harsh deadline. Specialization, combined with regular communication, breeds efficiency.
FURTHER EDIT: I suppose a better phrasing would be "how do I politely tell a coworker to only focus on his assigned tasks?"
software-industry coworker
asked May 4 '16 at 20:39
TheSoundDefense
2,26731420
4
Sounds like you just need a code review process. This gives you the place to make comments such as "this looks good, but I think it's large enough that we should discuss it on a design doc" or "this won't actually work when X, Y, Z because <domain-specific knowledge>, consider doing this instead".
– GManNickG
May 4 '16 at 20:52
1
While technical ownership can be a major pitfall, people changing items outside their area of proficiency is a huge risk.
– Myles
May 4 '16 at 20:57
@JoeStrazzere it's more like they assumed the scope of their assigned work extended farther than it actually does.
– TheSoundDefense
May 4 '16 at 22:04
2
I think the title doesn't properly reflect the question. The problem seems not to be that he's looking at other parts of the code (which, as others have said, is probably a good thing); it's that he's making changes without telling people or considering the effects of the changes.
– jamesqf
May 5 '16 at 18:39
1
FURTHER EDIT: I think the answer is clear. That this is a bad idea you should encourage work across silos. What you should be doing is building a standard way of communicating when this happens.
– Martin York
May 5 '16 at 21:03
 |Â
show 1 more comment
up vote
3
down vote
favorite
up vote
3
down vote
favorite
I've been working on a software project for a few months now with a very small team (and by small, I mean there was an extended period of time where I was the only developer). Our working dynamic is excellent for the most part, as each developer has a different sector that they work in (frontend, backend, database, etc.) and there's very little overlap, so conflicts are minimal.
Recently we brought another developer in to do work in another area on the project, and thus far their work has been great. However, they are starting to reach out and alter code in other people's spaces, including my own. While the code they're writing isn't broken, it introduces some clashes, such as when they started rewriting some of the frontend/backend architecture without consulting anyone.
The biggest benefits of having each person "own" a certain portion of the code is that 1) everything in that portion of the code has a similar logic and style to it, making it more easy to understand, and 2) the person working in that area can be sure they have absolute understanding of all the moving pieces in that section. That's something that is starting to change with this new development.
While I am not the manager or owner of the project, I am the team lead, so I think this falls into my area of responsibility. So my questions are:
- Am I overreacting to something that is not really a major issue?
- If I am not overreacting, what is the best way to correct this person without discouraging them? Again, they do fine work and I don't want to create any hostility.
EDIT: the wording of my question has led several people to believe that we are intentionally obscuring how parts of the code work so that only one person understands it. This is not at all the case. We have learned the hard way the importance of spreading knowledge around. We have daily stand ups and source control. What I mean is that we have one person working on particular sections of the code, because 1) it is easier to create consistent code that all operates in a similar manner, and 2) again, we are a very small team with a not-small task on our hands, and a harsh deadline. Specialization, combined with regular communication, breeds efficiency.
FURTHER EDIT: I suppose a better phrasing would be "how do I politely tell a coworker to only focus on his assigned tasks?"
software-industry coworker
asked May 4 '16 at 20:39
TheSoundDefense
2,26731420
I've been working on a software project for a few months now with a very small team (and by small, I mean there was an extended period of time where I was the only developer). Our working dynamic is excellent for the most part, as each developer has a different sector that they work in (frontend, backend, database, etc.) and there's very little overlap, so conflicts are minimal.
Recently we brought another developer in to do work in another area on the project, and thus far their work has been great. However, they are starting to reach out and alter code in other people's spaces, including my own. While the code they're writing isn't broken, it introduces some clashes, such as when they started rewriting some of the frontend/backend architecture without consulting anyone.
The biggest benefits of having each person "own" a certain portion of the code is that 1) everything in that portion of the code has a similar logic and style to it, making it more easy to understand, and 2) the person working in that area can be sure they have absolute understanding of all the moving pieces in that section. That's something that is starting to change with this new development.
While I am not the manager or owner of the project, I am the team lead, so I think this falls into my area of responsibility. So my questions are:
- Am I overreacting to something that is not really a major issue?
- If I am not overreacting, what is the best way to correct this person without discouraging them? Again, they do fine work and I don't want to create any hostility.
EDIT: the wording of my question has led several people to believe that we are intentionally obscuring how parts of the code work so that only one person understands it. This is not at all the case. We have learned the hard way the importance of spreading knowledge around. We have daily stand ups and source control. What I mean is that we have one person working on particular sections of the code, because 1) it is easier to create consistent code that all operates in a similar manner, and 2) again, we are a very small team with a not-small task on our hands, and a harsh deadline. Specialization, combined with regular communication, breeds efficiency.
FURTHER EDIT: I suppose a better phrasing would be "how do I politely tell a coworker to only focus on his assigned tasks?"
software-industry coworker
asked May 4 '16 at 20:39
TheSoundDefense
2,26731420
edited May 5 '16 at 19:20
asked May 4 '16 at 20:39
TheSoundDefense
2,26731420
asked May 4 '16 at 20:39
TheSoundDefense
2,26731420
asked May 4 '16 at 20:39
TheSoundDefense
2,26731420
2,26731420
4
Sounds like you just need a code review process. This gives you the place to make comments such as "this looks good, but I think it's large enough that we should discuss it on a design doc" or "this won't actually work when X, Y, Z because <domain-specific knowledge>, consider doing this instead".
– GManNickG
May 4 '16 at 20:52
1
While technical ownership can be a major pitfall, people changing items outside their area of proficiency is a huge risk.
– Myles
May 4 '16 at 20:57
@JoeStrazzere it's more like they assumed the scope of their assigned work extended farther than it actually does.
– TheSoundDefense
May 4 '16 at 22:04
2
I think the title doesn't properly reflect the question. The problem seems not to be that he's looking at other parts of the code (which, as others have said, is probably a good thing); it's that he's making changes without telling people or considering the effects of the changes.
– jamesqf
May 5 '16 at 18:39
1
FURTHER EDIT: I think the answer is clear. That this is a bad idea you should encourage work across silos. What you should be doing is building a standard way of communicating when this happens.
– Martin York
May 5 '16 at 21:03
 |Â
show 1 more comment
4
Sounds like you just need a code review process. This gives you the place to make comments such as "this looks good, but I think it's large enough that we should discuss it on a design doc" or "this won't actually work when X, Y, Z because <domain-specific knowledge>, consider doing this instead".
– GManNickG
May 4 '16 at 20:52
1
While technical ownership can be a major pitfall, people changing items outside their area of proficiency is a huge risk.
– Myles
May 4 '16 at 20:57
@JoeStrazzere it's more like they assumed the scope of their assigned work extended farther than it actually does.
– TheSoundDefense
May 4 '16 at 22:04
2
I think the title doesn't properly reflect the question. The problem seems not to be that he's looking at other parts of the code (which, as others have said, is probably a good thing); it's that he's making changes without telling people or considering the effects of the changes.
– jamesqf
May 5 '16 at 18:39
1
FURTHER EDIT: I think the answer is clear. That this is a bad idea you should encourage work across silos. What you should be doing is building a standard way of communicating when this happens.
– Martin York
May 5 '16 at 21:03
4
4
Sounds like you just need a code review process. This gives you the place to make comments such as "this looks good, but I think it's large enough that we should discuss it on a design doc" or "this won't actually work when X, Y, Z because <domain-specific knowledge>, consider doing this instead".
– GManNickG
May 4 '16 at 20:52
Sounds like you just need a code review process. This gives you the place to make comments such as "this looks good, but I think it's large enough that we should discuss it on a design doc" or "this won't actually work when X, Y, Z because <domain-specific knowledge>, consider doing this instead".
– GManNickG
May 4 '16 at 20:52
1
1
While technical ownership can be a major pitfall, people changing items outside their area of proficiency is a huge risk.
– Myles
May 4 '16 at 20:57
While technical ownership can be a major pitfall, people changing items outside their area of proficiency is a huge risk.
– Myles
May 4 '16 at 20:57
@JoeStrazzere it's more like they assumed the scope of their assigned work extended farther than it actually does.
– TheSoundDefense
May 4 '16 at 22:04
@JoeStrazzere it's more like they assumed the scope of their assigned work extended farther than it actually does.
– TheSoundDefense
May 4 '16 at 22:04
2
2
I think the title doesn't properly reflect the question. The problem seems not to be that he's looking at other parts of the code (which, as others have said, is probably a good thing); it's that he's making changes without telling people or considering the effects of the changes.
– jamesqf
May 5 '16 at 18:39
I think the title doesn't properly reflect the question. The problem seems not to be that he's looking at other parts of the code (which, as others have said, is probably a good thing); it's that he's making changes without telling people or considering the effects of the changes.
– jamesqf
May 5 '16 at 18:39
1
1
FURTHER EDIT: I think the answer is clear. That this is a bad idea you should encourage work across silos. What you should be doing is building a standard way of communicating when this happens.– Martin York
May 5 '16 at 21:03
FURTHER EDIT: I think the answer is clear. That this is a bad idea you should encourage work across silos. What you should be doing is building a standard way of communicating when this happens.– Martin York
May 5 '16 at 21:03
 |Â
show 1 more comment
3 Answers
3
active
oldest
votes
up vote
6
down vote
accepted
I think this could become a major issue if you let it. It also could be a major opportunity if you handle it correctly. If your team continues to grow, you're not going to be able to maintain the clean separation you have had up till now, so you should probably try to figure out how to deal with this issue now, while it's small.
I think the issue is mainly one of communication. It's fantastic that your new team member has a lot of initiative to solve her own problems. But as you pointed out, the changes she is making are disrupting other peoples' work. So you need to develop a way to communicate about changes, before, during, and after.
I'm assuming you have regular standups or similar. This can be a great way to discuss proposed changes to make sure they're needed and in-line with the team's method of doing business.
After changes are made, they should be reviewed before being incorporated into the main codebase. At this point, they should be reviewed by the person who has "ownership," though that line will get fuzzier as more people touch the code. This will allow for needed edits to be made and for the "owner" to still stay in touch with all the parts of the code.
One thing that you'll need to realize is if your team needs to grow, it needs to grow. And that's going to introduce some inefficiencies due to having some parts of the code that some people are less familiar with than if they wrote it, and it will also mean that some of the lines between different pieces of functionality won't be drawn exactly where you would. In cases of adverse impact, that may mean going back and redrawing those lines. But that's just what happens once a team gets larger than a certain point.
answered May 4 '16 at 20:56
Amy Blankenship
7,13711836
suggest improvements |Â
up vote
14
down vote
Only having 1 person understand/develop be responsible for a system is a major failing in a team. This will lead to large disruptions if people leave are sick etc. So you actually want everybody working in all parts of the system all the time.
Yes having somebody changes code in systems without review is not acceptable (even if all your test pass). At least one other person should review any change and preferably more with the owner having the final say if the change is acceptable.
answered May 4 '16 at 20:55
Martin York
953616
It definitely is a failing, as we've experienced in the past when a key member went on paternity leave and nobody had the knowledge to do his work. This is something we want to fix in the future, but for right now our team is just too small, and the scope of the project is just too large. But it is absolutely on our to-do list, and we talk about this often.
– TheSoundDefense
May 4 '16 at 21:17
Agreed. Working in silos (I own this piece, you own that piece) makes your team susceptible to major disruptions. If someone leaves or changes roles, then you lose your only subject matter expert. However, collaboration is tricky. You may benefit from having daily stand ups where everyone on your team (preferably 5-7 people) quickly reviews what they did yesterday, what they're doing today, and what their blocks are. Then people are aware of who is touching what code. Also, source control may help. If you're really ambitious, Agile / Scrum may help.
– MealyPotatoes
May 4 '16 at 21:17
We are using source control, agile, and daily stand ups. This has just never been a problem before.
– TheSoundDefense
May 4 '16 at 21:21
Are you doing "Pull Requests" (git hub terminology for code review).
– Martin York
May 4 '16 at 22:53
2
Totally agree. The problem the OP posted pails in comparison to his team working in silos as they are now. Instead of complaining that the new person is "branching out", the OP should be pushing for EVERYBODY to be branching out. Of course a coordinated "branching out" is preferable to everybody just do what they please at any time like the new guy.
– Dunk
May 5 '16 at 15:23
 |Â
show 1 more comment
up vote
2
down vote
You do not own any part of the code. It is acceptable for anyone on the team to make any changes they feel necessary. Let's start with that. You NEVER OWN any part of the code. It is not your private domain. It is counterproductive for only one person to understand a part of the code. This is an attitude that you personally must adjust. What he is doing is not wrong. What you expect is.
Now that you have more devs you need more formal processes in place to make sure that changes are appropriate. You want to make sure that changes in any part of the code don't break the build. You want to make sure that QA is done before changes are pushed to prod and you want to make sure that devs no longer can push anything to production without going through the appropriate processes( usually by removing dev rights to prod and giving them only to a build team or a manager). You should also have code review of 100% of code written by any team member. You should be requiring unit test of all code so that you can test when changes are made. All code should be in source control so it can be reverted if necessary. This is where it is appropriate to bring up any concerns about the changes affecting other things.
What your team and managers need to do is sit down and determine the processes you need as the team grows and how you are going to enforce those processes. You also need to sit down and do knowledge transfer training so that more than one person can safely touch any part of the code.
answered May 5 '16 at 17:39
HLGEM
133k25226489
We do not enforce that only one person understands any part of the code and I never intended to give that impression. I have edited my question accordingly. However I still have to challenge your assertion of "coworkers can always modify whatever code they see fit". We're now looking at a fractured half-and-half architecture (which we were not told about, I discovered it during a merge conflict) and these changes mean teammates now understand the architecture less. Is that acceptable?
– TheSoundDefense
May 5 '16 at 18:26
Yes. The merge caught the conflict. That is ordinary and normal when you multiple people have a need to be in the same part of the code while working on different issues. When there is conflict then both devs and their boss if need be get together to figure out a solution that works for both of them. If you have a dev who can't seem to program without continually causing problems, then the manager must address the performance problem. But he should not be forbidden any part of the code base necessary to fix his problems or he will create an even worse mess working around the restriction.
– HLGEM
May 5 '16 at 19:17
Well I guess the bigger problem was that they did not actually need to be messing with the code they were messing with. They were trying to make improvements that ultimately were out of the scope of their assigned tasks.
– TheSoundDefense
May 5 '16 at 19:19
Then their manager should address that. Not you.
– HLGEM
May 5 '16 at 19:22
1
It's kind of a fine line what the team lead should do when a member of the team "disobeys" their instructions. Since it's a new team member, I'd assume good intent and discuss your point of view and try to get theirs. Sometimes a change that seems to be unrelated is actually very related if you take a different view of the system. And it can be pretty frustrating to be under a team lead who is stymying your efforts to improve code quality because you can't get him to understand your view of the system.
– Amy Blankenship
May 5 '16 at 20:27
 |Â
show 1 more comment
StackExchange.ready(function ()
$("#show-editor-button input, #show-editor-button button").click(function ()
var showEditor = function()
$("#show-editor-button").hide();
$("#post-form").removeClass("dno");
StackExchange.editor.finallyInit();
;
var useFancy = $(this).data('confirm-use-fancy');
if(useFancy == 'True')
var popupTitle = $(this).data('confirm-fancy-title');
var popupBody = $(this).data('confirm-fancy-body');
var popupAccept = $(this).data('confirm-fancy-accept-button');
$(this).loadPopup(
url: '/post/self-answer-popup',
loaded: function(popup)
var pTitle = $(popup).find('h2');
var pBody = $(popup).find('.popup-body');
var pSubmit = $(popup).find('.popup-submit');
pTitle.text(popupTitle);
pBody.html(popupBody);
pSubmit.val(popupAccept).click(showEditor);
)
else
var confirmText = $(this).data('confirm-text');
if (confirmText ? confirm(confirmText) : true)
showEditor();
);
);
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
6
down vote
accepted
I think this could become a major issue if you let it. It also could be a major opportunity if you handle it correctly. If your team continues to grow, you're not going to be able to maintain the clean separation you have had up till now, so you should probably try to figure out how to deal with this issue now, while it's small.
I think the issue is mainly one of communication. It's fantastic that your new team member has a lot of initiative to solve her own problems. But as you pointed out, the changes she is making are disrupting other peoples' work. So you need to develop a way to communicate about changes, before, during, and after.
I'm assuming you have regular standups or similar. This can be a great way to discuss proposed changes to make sure they're needed and in-line with the team's method of doing business.
After changes are made, they should be reviewed before being incorporated into the main codebase. At this point, they should be reviewed by the person who has "ownership," though that line will get fuzzier as more people touch the code. This will allow for needed edits to be made and for the "owner" to still stay in touch with all the parts of the code.
One thing that you'll need to realize is if your team needs to grow, it needs to grow. And that's going to introduce some inefficiencies due to having some parts of the code that some people are less familiar with than if they wrote it, and it will also mean that some of the lines between different pieces of functionality won't be drawn exactly where you would. In cases of adverse impact, that may mean going back and redrawing those lines. But that's just what happens once a team gets larger than a certain point.
answered May 4 '16 at 20:56
Amy Blankenship
7,13711836
suggest improvements |Â
up vote
6
down vote
accepted
I think this could become a major issue if you let it. It also could be a major opportunity if you handle it correctly. If your team continues to grow, you're not going to be able to maintain the clean separation you have had up till now, so you should probably try to figure out how to deal with this issue now, while it's small.
I think the issue is mainly one of communication. It's fantastic that your new team member has a lot of initiative to solve her own problems. But as you pointed out, the changes she is making are disrupting other peoples' work. So you need to develop a way to communicate about changes, before, during, and after.
I'm assuming you have regular standups or similar. This can be a great way to discuss proposed changes to make sure they're needed and in-line with the team's method of doing business.
After changes are made, they should be reviewed before being incorporated into the main codebase. At this point, they should be reviewed by the person who has "ownership," though that line will get fuzzier as more people touch the code. This will allow for needed edits to be made and for the "owner" to still stay in touch with all the parts of the code.
One thing that you'll need to realize is if your team needs to grow, it needs to grow. And that's going to introduce some inefficiencies due to having some parts of the code that some people are less familiar with than if they wrote it, and it will also mean that some of the lines between different pieces of functionality won't be drawn exactly where you would. In cases of adverse impact, that may mean going back and redrawing those lines. But that's just what happens once a team gets larger than a certain point.
answered May 4 '16 at 20:56
Amy Blankenship
7,13711836
suggest improvements |Â
up vote
6
down vote
accepted
up vote
6
down vote
accepted
I think this could become a major issue if you let it. It also could be a major opportunity if you handle it correctly. If your team continues to grow, you're not going to be able to maintain the clean separation you have had up till now, so you should probably try to figure out how to deal with this issue now, while it's small.
I think the issue is mainly one of communication. It's fantastic that your new team member has a lot of initiative to solve her own problems. But as you pointed out, the changes she is making are disrupting other peoples' work. So you need to develop a way to communicate about changes, before, during, and after.
I'm assuming you have regular standups or similar. This can be a great way to discuss proposed changes to make sure they're needed and in-line with the team's method of doing business.
After changes are made, they should be reviewed before being incorporated into the main codebase. At this point, they should be reviewed by the person who has "ownership," though that line will get fuzzier as more people touch the code. This will allow for needed edits to be made and for the "owner" to still stay in touch with all the parts of the code.
One thing that you'll need to realize is if your team needs to grow, it needs to grow. And that's going to introduce some inefficiencies due to having some parts of the code that some people are less familiar with than if they wrote it, and it will also mean that some of the lines between different pieces of functionality won't be drawn exactly where you would. In cases of adverse impact, that may mean going back and redrawing those lines. But that's just what happens once a team gets larger than a certain point.
answered May 4 '16 at 20:56
Amy Blankenship
7,13711836
I think this could become a major issue if you let it. It also could be a major opportunity if you handle it correctly. If your team continues to grow, you're not going to be able to maintain the clean separation you have had up till now, so you should probably try to figure out how to deal with this issue now, while it's small.
I think the issue is mainly one of communication. It's fantastic that your new team member has a lot of initiative to solve her own problems. But as you pointed out, the changes she is making are disrupting other peoples' work. So you need to develop a way to communicate about changes, before, during, and after.
I'm assuming you have regular standups or similar. This can be a great way to discuss proposed changes to make sure they're needed and in-line with the team's method of doing business.
After changes are made, they should be reviewed before being incorporated into the main codebase. At this point, they should be reviewed by the person who has "ownership," though that line will get fuzzier as more people touch the code. This will allow for needed edits to be made and for the "owner" to still stay in touch with all the parts of the code.
One thing that you'll need to realize is if your team needs to grow, it needs to grow. And that's going to introduce some inefficiencies due to having some parts of the code that some people are less familiar with than if they wrote it, and it will also mean that some of the lines between different pieces of functionality won't be drawn exactly where you would. In cases of adverse impact, that may mean going back and redrawing those lines. But that's just what happens once a team gets larger than a certain point.
answered May 4 '16 at 20:56
Amy Blankenship
7,13711836
answered May 4 '16 at 20:56
Amy Blankenship
7,13711836
answered May 4 '16 at 20:56
Amy Blankenship
7,13711836
answered May 4 '16 at 20:56
Amy Blankenship
7,13711836
7,13711836
suggest improvements |Â
suggest improvements |Â
up vote
14
down vote
Only having 1 person understand/develop be responsible for a system is a major failing in a team. This will lead to large disruptions if people leave are sick etc. So you actually want everybody working in all parts of the system all the time.
Yes having somebody changes code in systems without review is not acceptable (even if all your test pass). At least one other person should review any change and preferably more with the owner having the final say if the change is acceptable.
answered May 4 '16 at 20:55
Martin York
953616
It definitely is a failing, as we've experienced in the past when a key member went on paternity leave and nobody had the knowledge to do his work. This is something we want to fix in the future, but for right now our team is just too small, and the scope of the project is just too large. But it is absolutely on our to-do list, and we talk about this often.
– TheSoundDefense
May 4 '16 at 21:17
Agreed. Working in silos (I own this piece, you own that piece) makes your team susceptible to major disruptions. If someone leaves or changes roles, then you lose your only subject matter expert. However, collaboration is tricky. You may benefit from having daily stand ups where everyone on your team (preferably 5-7 people) quickly reviews what they did yesterday, what they're doing today, and what their blocks are. Then people are aware of who is touching what code. Also, source control may help. If you're really ambitious, Agile / Scrum may help.
– MealyPotatoes
May 4 '16 at 21:17
We are using source control, agile, and daily stand ups. This has just never been a problem before.
– TheSoundDefense
May 4 '16 at 21:21
Are you doing "Pull Requests" (git hub terminology for code review).
– Martin York
May 4 '16 at 22:53
2
Totally agree. The problem the OP posted pails in comparison to his team working in silos as they are now. Instead of complaining that the new person is "branching out", the OP should be pushing for EVERYBODY to be branching out. Of course a coordinated "branching out" is preferable to everybody just do what they please at any time like the new guy.
– Dunk
May 5 '16 at 15:23
 |Â
show 1 more comment
up vote
14
down vote
Only having 1 person understand/develop be responsible for a system is a major failing in a team. This will lead to large disruptions if people leave are sick etc. So you actually want everybody working in all parts of the system all the time.
Yes having somebody changes code in systems without review is not acceptable (even if all your test pass). At least one other person should review any change and preferably more with the owner having the final say if the change is acceptable.
answered May 4 '16 at 20:55
Martin York
953616
It definitely is a failing, as we've experienced in the past when a key member went on paternity leave and nobody had the knowledge to do his work. This is something we want to fix in the future, but for right now our team is just too small, and the scope of the project is just too large. But it is absolutely on our to-do list, and we talk about this often.
– TheSoundDefense
May 4 '16 at 21:17
Agreed. Working in silos (I own this piece, you own that piece) makes your team susceptible to major disruptions. If someone leaves or changes roles, then you lose your only subject matter expert. However, collaboration is tricky. You may benefit from having daily stand ups where everyone on your team (preferably 5-7 people) quickly reviews what they did yesterday, what they're doing today, and what their blocks are. Then people are aware of who is touching what code. Also, source control may help. If you're really ambitious, Agile / Scrum may help.
– MealyPotatoes
May 4 '16 at 21:17
We are using source control, agile, and daily stand ups. This has just never been a problem before.
– TheSoundDefense
May 4 '16 at 21:21
Are you doing "Pull Requests" (git hub terminology for code review).
– Martin York
May 4 '16 at 22:53
2
Totally agree. The problem the OP posted pails in comparison to his team working in silos as they are now. Instead of complaining that the new person is "branching out", the OP should be pushing for EVERYBODY to be branching out. Of course a coordinated "branching out" is preferable to everybody just do what they please at any time like the new guy.
– Dunk
May 5 '16 at 15:23
 |Â
show 1 more comment
up vote
14
down vote
up vote
14
down vote
Only having 1 person understand/develop be responsible for a system is a major failing in a team. This will lead to large disruptions if people leave are sick etc. So you actually want everybody working in all parts of the system all the time.
Yes having somebody changes code in systems without review is not acceptable (even if all your test pass). At least one other person should review any change and preferably more with the owner having the final say if the change is acceptable.
answered May 4 '16 at 20:55
Martin York
953616
Only having 1 person understand/develop be responsible for a system is a major failing in a team. This will lead to large disruptions if people leave are sick etc. So you actually want everybody working in all parts of the system all the time.
Yes having somebody changes code in systems without review is not acceptable (even if all your test pass). At least one other person should review any change and preferably more with the owner having the final say if the change is acceptable.
answered May 4 '16 at 20:55
Martin York
953616
answered May 4 '16 at 20:55
Martin York
953616
answered May 4 '16 at 20:55
Martin York
953616
answered May 4 '16 at 20:55
Martin York
953616
953616
It definitely is a failing, as we've experienced in the past when a key member went on paternity leave and nobody had the knowledge to do his work. This is something we want to fix in the future, but for right now our team is just too small, and the scope of the project is just too large. But it is absolutely on our to-do list, and we talk about this often.
– TheSoundDefense
May 4 '16 at 21:17
Agreed. Working in silos (I own this piece, you own that piece) makes your team susceptible to major disruptions. If someone leaves or changes roles, then you lose your only subject matter expert. However, collaboration is tricky. You may benefit from having daily stand ups where everyone on your team (preferably 5-7 people) quickly reviews what they did yesterday, what they're doing today, and what their blocks are. Then people are aware of who is touching what code. Also, source control may help. If you're really ambitious, Agile / Scrum may help.
– MealyPotatoes
May 4 '16 at 21:17
We are using source control, agile, and daily stand ups. This has just never been a problem before.
– TheSoundDefense
May 4 '16 at 21:21
Are you doing "Pull Requests" (git hub terminology for code review).
– Martin York
May 4 '16 at 22:53
2
Totally agree. The problem the OP posted pails in comparison to his team working in silos as they are now. Instead of complaining that the new person is "branching out", the OP should be pushing for EVERYBODY to be branching out. Of course a coordinated "branching out" is preferable to everybody just do what they please at any time like the new guy.
– Dunk
May 5 '16 at 15:23
 |Â
show 1 more comment
It definitely is a failing, as we've experienced in the past when a key member went on paternity leave and nobody had the knowledge to do his work. This is something we want to fix in the future, but for right now our team is just too small, and the scope of the project is just too large. But it is absolutely on our to-do list, and we talk about this often.
– TheSoundDefense
May 4 '16 at 21:17
Agreed. Working in silos (I own this piece, you own that piece) makes your team susceptible to major disruptions. If someone leaves or changes roles, then you lose your only subject matter expert. However, collaboration is tricky. You may benefit from having daily stand ups where everyone on your team (preferably 5-7 people) quickly reviews what they did yesterday, what they're doing today, and what their blocks are. Then people are aware of who is touching what code. Also, source control may help. If you're really ambitious, Agile / Scrum may help.
– MealyPotatoes
May 4 '16 at 21:17
We are using source control, agile, and daily stand ups. This has just never been a problem before.
– TheSoundDefense
May 4 '16 at 21:21
Are you doing "Pull Requests" (git hub terminology for code review).
– Martin York
May 4 '16 at 22:53
2
Totally agree. The problem the OP posted pails in comparison to his team working in silos as they are now. Instead of complaining that the new person is "branching out", the OP should be pushing for EVERYBODY to be branching out. Of course a coordinated "branching out" is preferable to everybody just do what they please at any time like the new guy.
– Dunk
May 5 '16 at 15:23
It definitely is a failing, as we've experienced in the past when a key member went on paternity leave and nobody had the knowledge to do his work. This is something we want to fix in the future, but for right now our team is just too small, and the scope of the project is just too large. But it is absolutely on our to-do list, and we talk about this often.
– TheSoundDefense
May 4 '16 at 21:17
It definitely is a failing, as we've experienced in the past when a key member went on paternity leave and nobody had the knowledge to do his work. This is something we want to fix in the future, but for right now our team is just too small, and the scope of the project is just too large. But it is absolutely on our to-do list, and we talk about this often.
– TheSoundDefense
May 4 '16 at 21:17
Agreed. Working in silos (I own this piece, you own that piece) makes your team susceptible to major disruptions. If someone leaves or changes roles, then you lose your only subject matter expert. However, collaboration is tricky. You may benefit from having daily stand ups where everyone on your team (preferably 5-7 people) quickly reviews what they did yesterday, what they're doing today, and what their blocks are. Then people are aware of who is touching what code. Also, source control may help. If you're really ambitious, Agile / Scrum may help.
– MealyPotatoes
May 4 '16 at 21:17
Agreed. Working in silos (I own this piece, you own that piece) makes your team susceptible to major disruptions. If someone leaves or changes roles, then you lose your only subject matter expert. However, collaboration is tricky. You may benefit from having daily stand ups where everyone on your team (preferably 5-7 people) quickly reviews what they did yesterday, what they're doing today, and what their blocks are. Then people are aware of who is touching what code. Also, source control may help. If you're really ambitious, Agile / Scrum may help.
– MealyPotatoes
May 4 '16 at 21:17
We are using source control, agile, and daily stand ups. This has just never been a problem before.
– TheSoundDefense
May 4 '16 at 21:21
We are using source control, agile, and daily stand ups. This has just never been a problem before.
– TheSoundDefense
May 4 '16 at 21:21
Are you doing "Pull Requests" (git hub terminology for code review).
– Martin York
May 4 '16 at 22:53
Are you doing "Pull Requests" (git hub terminology for code review).
– Martin York
May 4 '16 at 22:53
2
2
Totally agree. The problem the OP posted pails in comparison to his team working in silos as they are now. Instead of complaining that the new person is "branching out", the OP should be pushing for EVERYBODY to be branching out. Of course a coordinated "branching out" is preferable to everybody just do what they please at any time like the new guy.
– Dunk
May 5 '16 at 15:23
Totally agree. The problem the OP posted pails in comparison to his team working in silos as they are now. Instead of complaining that the new person is "branching out", the OP should be pushing for EVERYBODY to be branching out. Of course a coordinated "branching out" is preferable to everybody just do what they please at any time like the new guy.
– Dunk
May 5 '16 at 15:23
 |Â
show 1 more comment
up vote
2
down vote
You do not own any part of the code. It is acceptable for anyone on the team to make any changes they feel necessary. Let's start with that. You NEVER OWN any part of the code. It is not your private domain. It is counterproductive for only one person to understand a part of the code. This is an attitude that you personally must adjust. What he is doing is not wrong. What you expect is.
Now that you have more devs you need more formal processes in place to make sure that changes are appropriate. You want to make sure that changes in any part of the code don't break the build. You want to make sure that QA is done before changes are pushed to prod and you want to make sure that devs no longer can push anything to production without going through the appropriate processes( usually by removing dev rights to prod and giving them only to a build team or a manager). You should also have code review of 100% of code written by any team member. You should be requiring unit test of all code so that you can test when changes are made. All code should be in source control so it can be reverted if necessary. This is where it is appropriate to bring up any concerns about the changes affecting other things.
What your team and managers need to do is sit down and determine the processes you need as the team grows and how you are going to enforce those processes. You also need to sit down and do knowledge transfer training so that more than one person can safely touch any part of the code.
answered May 5 '16 at 17:39
HLGEM
133k25226489
We do not enforce that only one person understands any part of the code and I never intended to give that impression. I have edited my question accordingly. However I still have to challenge your assertion of "coworkers can always modify whatever code they see fit". We're now looking at a fractured half-and-half architecture (which we were not told about, I discovered it during a merge conflict) and these changes mean teammates now understand the architecture less. Is that acceptable?
– TheSoundDefense
May 5 '16 at 18:26
Yes. The merge caught the conflict. That is ordinary and normal when you multiple people have a need to be in the same part of the code while working on different issues. When there is conflict then both devs and their boss if need be get together to figure out a solution that works for both of them. If you have a dev who can't seem to program without continually causing problems, then the manager must address the performance problem. But he should not be forbidden any part of the code base necessary to fix his problems or he will create an even worse mess working around the restriction.
– HLGEM
May 5 '16 at 19:17
Well I guess the bigger problem was that they did not actually need to be messing with the code they were messing with. They were trying to make improvements that ultimately were out of the scope of their assigned tasks.
– TheSoundDefense
May 5 '16 at 19:19
Then their manager should address that. Not you.
– HLGEM
May 5 '16 at 19:22
1
It's kind of a fine line what the team lead should do when a member of the team "disobeys" their instructions. Since it's a new team member, I'd assume good intent and discuss your point of view and try to get theirs. Sometimes a change that seems to be unrelated is actually very related if you take a different view of the system. And it can be pretty frustrating to be under a team lead who is stymying your efforts to improve code quality because you can't get him to understand your view of the system.
– Amy Blankenship
May 5 '16 at 20:27
 |Â
show 1 more comment
up vote
2
down vote
You do not own any part of the code. It is acceptable for anyone on the team to make any changes they feel necessary. Let's start with that. You NEVER OWN any part of the code. It is not your private domain. It is counterproductive for only one person to understand a part of the code. This is an attitude that you personally must adjust. What he is doing is not wrong. What you expect is.
Now that you have more devs you need more formal processes in place to make sure that changes are appropriate. You want to make sure that changes in any part of the code don't break the build. You want to make sure that QA is done before changes are pushed to prod and you want to make sure that devs no longer can push anything to production without going through the appropriate processes( usually by removing dev rights to prod and giving them only to a build team or a manager). You should also have code review of 100% of code written by any team member. You should be requiring unit test of all code so that you can test when changes are made. All code should be in source control so it can be reverted if necessary. This is where it is appropriate to bring up any concerns about the changes affecting other things.
What your team and managers need to do is sit down and determine the processes you need as the team grows and how you are going to enforce those processes. You also need to sit down and do knowledge transfer training so that more than one person can safely touch any part of the code.
answered May 5 '16 at 17:39
HLGEM
133k25226489
We do not enforce that only one person understands any part of the code and I never intended to give that impression. I have edited my question accordingly. However I still have to challenge your assertion of "coworkers can always modify whatever code they see fit". We're now looking at a fractured half-and-half architecture (which we were not told about, I discovered it during a merge conflict) and these changes mean teammates now understand the architecture less. Is that acceptable?
– TheSoundDefense
May 5 '16 at 18:26
Yes. The merge caught the conflict. That is ordinary and normal when you multiple people have a need to be in the same part of the code while working on different issues. When there is conflict then both devs and their boss if need be get together to figure out a solution that works for both of them. If you have a dev who can't seem to program without continually causing problems, then the manager must address the performance problem. But he should not be forbidden any part of the code base necessary to fix his problems or he will create an even worse mess working around the restriction.
– HLGEM
May 5 '16 at 19:17
Well I guess the bigger problem was that they did not actually need to be messing with the code they were messing with. They were trying to make improvements that ultimately were out of the scope of their assigned tasks.
– TheSoundDefense
May 5 '16 at 19:19
Then their manager should address that. Not you.
– HLGEM
May 5 '16 at 19:22
1
It's kind of a fine line what the team lead should do when a member of the team "disobeys" their instructions. Since it's a new team member, I'd assume good intent and discuss your point of view and try to get theirs. Sometimes a change that seems to be unrelated is actually very related if you take a different view of the system. And it can be pretty frustrating to be under a team lead who is stymying your efforts to improve code quality because you can't get him to understand your view of the system.
– Amy Blankenship
May 5 '16 at 20:27
 |Â
show 1 more comment
up vote
2
down vote
up vote
2
down vote
You do not own any part of the code. It is acceptable for anyone on the team to make any changes they feel necessary. Let's start with that. You NEVER OWN any part of the code. It is not your private domain. It is counterproductive for only one person to understand a part of the code. This is an attitude that you personally must adjust. What he is doing is not wrong. What you expect is.
Now that you have more devs you need more formal processes in place to make sure that changes are appropriate. You want to make sure that changes in any part of the code don't break the build. You want to make sure that QA is done before changes are pushed to prod and you want to make sure that devs no longer can push anything to production without going through the appropriate processes( usually by removing dev rights to prod and giving them only to a build team or a manager). You should also have code review of 100% of code written by any team member. You should be requiring unit test of all code so that you can test when changes are made. All code should be in source control so it can be reverted if necessary. This is where it is appropriate to bring up any concerns about the changes affecting other things.
What your team and managers need to do is sit down and determine the processes you need as the team grows and how you are going to enforce those processes. You also need to sit down and do knowledge transfer training so that more than one person can safely touch any part of the code.
answered May 5 '16 at 17:39
HLGEM
133k25226489
You do not own any part of the code. It is acceptable for anyone on the team to make any changes they feel necessary. Let's start with that. You NEVER OWN any part of the code. It is not your private domain. It is counterproductive for only one person to understand a part of the code. This is an attitude that you personally must adjust. What he is doing is not wrong. What you expect is.
Now that you have more devs you need more formal processes in place to make sure that changes are appropriate. You want to make sure that changes in any part of the code don't break the build. You want to make sure that QA is done before changes are pushed to prod and you want to make sure that devs no longer can push anything to production without going through the appropriate processes( usually by removing dev rights to prod and giving them only to a build team or a manager). You should also have code review of 100% of code written by any team member. You should be requiring unit test of all code so that you can test when changes are made. All code should be in source control so it can be reverted if necessary. This is where it is appropriate to bring up any concerns about the changes affecting other things.
What your team and managers need to do is sit down and determine the processes you need as the team grows and how you are going to enforce those processes. You also need to sit down and do knowledge transfer training so that more than one person can safely touch any part of the code.
answered May 5 '16 at 17:39
HLGEM
133k25226489
answered May 5 '16 at 17:39
HLGEM
133k25226489
answered May 5 '16 at 17:39
HLGEM
133k25226489
answered May 5 '16 at 17:39
HLGEM
133k25226489
133k25226489
We do not enforce that only one person understands any part of the code and I never intended to give that impression. I have edited my question accordingly. However I still have to challenge your assertion of "coworkers can always modify whatever code they see fit". We're now looking at a fractured half-and-half architecture (which we were not told about, I discovered it during a merge conflict) and these changes mean teammates now understand the architecture less. Is that acceptable?
– TheSoundDefense
May 5 '16 at 18:26
Yes. The merge caught the conflict. That is ordinary and normal when you multiple people have a need to be in the same part of the code while working on different issues. When there is conflict then both devs and their boss if need be get together to figure out a solution that works for both of them. If you have a dev who can't seem to program without continually causing problems, then the manager must address the performance problem. But he should not be forbidden any part of the code base necessary to fix his problems or he will create an even worse mess working around the restriction.
– HLGEM
May 5 '16 at 19:17
Well I guess the bigger problem was that they did not actually need to be messing with the code they were messing with. They were trying to make improvements that ultimately were out of the scope of their assigned tasks.
– TheSoundDefense
May 5 '16 at 19:19
Then their manager should address that. Not you.
– HLGEM
May 5 '16 at 19:22
1
It's kind of a fine line what the team lead should do when a member of the team "disobeys" their instructions. Since it's a new team member, I'd assume good intent and discuss your point of view and try to get theirs. Sometimes a change that seems to be unrelated is actually very related if you take a different view of the system. And it can be pretty frustrating to be under a team lead who is stymying your efforts to improve code quality because you can't get him to understand your view of the system.
– Amy Blankenship
May 5 '16 at 20:27
 |Â
show 1 more comment
We do not enforce that only one person understands any part of the code and I never intended to give that impression. I have edited my question accordingly. However I still have to challenge your assertion of "coworkers can always modify whatever code they see fit". We're now looking at a fractured half-and-half architecture (which we were not told about, I discovered it during a merge conflict) and these changes mean teammates now understand the architecture less. Is that acceptable?
– TheSoundDefense
May 5 '16 at 18:26
Yes. The merge caught the conflict. That is ordinary and normal when you multiple people have a need to be in the same part of the code while working on different issues. When there is conflict then both devs and their boss if need be get together to figure out a solution that works for both of them. If you have a dev who can't seem to program without continually causing problems, then the manager must address the performance problem. But he should not be forbidden any part of the code base necessary to fix his problems or he will create an even worse mess working around the restriction.
– HLGEM
May 5 '16 at 19:17
Well I guess the bigger problem was that they did not actually need to be messing with the code they were messing with. They were trying to make improvements that ultimately were out of the scope of their assigned tasks.
– TheSoundDefense
May 5 '16 at 19:19
Then their manager should address that. Not you.
– HLGEM
May 5 '16 at 19:22
1
It's kind of a fine line what the team lead should do when a member of the team "disobeys" their instructions. Since it's a new team member, I'd assume good intent and discuss your point of view and try to get theirs. Sometimes a change that seems to be unrelated is actually very related if you take a different view of the system. And it can be pretty frustrating to be under a team lead who is stymying your efforts to improve code quality because you can't get him to understand your view of the system.
– Amy Blankenship
May 5 '16 at 20:27
We do not enforce that only one person understands any part of the code and I never intended to give that impression. I have edited my question accordingly. However I still have to challenge your assertion of "coworkers can always modify whatever code they see fit". We're now looking at a fractured half-and-half architecture (which we were not told about, I discovered it during a merge conflict) and these changes mean teammates now understand the architecture less. Is that acceptable?
– TheSoundDefense
May 5 '16 at 18:26
We do not enforce that only one person understands any part of the code and I never intended to give that impression. I have edited my question accordingly. However I still have to challenge your assertion of "coworkers can always modify whatever code they see fit". We're now looking at a fractured half-and-half architecture (which we were not told about, I discovered it during a merge conflict) and these changes mean teammates now understand the architecture less. Is that acceptable?
– TheSoundDefense
May 5 '16 at 18:26
Yes. The merge caught the conflict. That is ordinary and normal when you multiple people have a need to be in the same part of the code while working on different issues. When there is conflict then both devs and their boss if need be get together to figure out a solution that works for both of them. If you have a dev who can't seem to program without continually causing problems, then the manager must address the performance problem. But he should not be forbidden any part of the code base necessary to fix his problems or he will create an even worse mess working around the restriction.
– HLGEM
May 5 '16 at 19:17
Yes. The merge caught the conflict. That is ordinary and normal when you multiple people have a need to be in the same part of the code while working on different issues. When there is conflict then both devs and their boss if need be get together to figure out a solution that works for both of them. If you have a dev who can't seem to program without continually causing problems, then the manager must address the performance problem. But he should not be forbidden any part of the code base necessary to fix his problems or he will create an even worse mess working around the restriction.
– HLGEM
May 5 '16 at 19:17
Well I guess the bigger problem was that they did not actually need to be messing with the code they were messing with. They were trying to make improvements that ultimately were out of the scope of their assigned tasks.
– TheSoundDefense
May 5 '16 at 19:19
Well I guess the bigger problem was that they did not actually need to be messing with the code they were messing with. They were trying to make improvements that ultimately were out of the scope of their assigned tasks.
– TheSoundDefense
May 5 '16 at 19:19
Then their manager should address that. Not you.
– HLGEM
May 5 '16 at 19:22
Then their manager should address that. Not you.
– HLGEM
May 5 '16 at 19:22
1
1
It's kind of a fine line what the team lead should do when a member of the team "disobeys" their instructions. Since it's a new team member, I'd assume good intent and discuss your point of view and try to get theirs. Sometimes a change that seems to be unrelated is actually very related if you take a different view of the system. And it can be pretty frustrating to be under a team lead who is stymying your efforts to improve code quality because you can't get him to understand your view of the system.
– Amy Blankenship
May 5 '16 at 20:27
It's kind of a fine line what the team lead should do when a member of the team "disobeys" their instructions. Since it's a new team member, I'd assume good intent and discuss your point of view and try to get theirs. Sometimes a change that seems to be unrelated is actually very related if you take a different view of the system. And it can be pretty frustrating to be under a team lead who is stymying your efforts to improve code quality because you can't get him to understand your view of the system.
– Amy Blankenship
May 5 '16 at 20:27
 |Â
show 1 more comment
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%2f66498%2fhow-do-i-politely-tell-a-coworker-to-only-focus-on-his-portion-of-the-work%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
4
Sounds like you just need a code review process. This gives you the place to make comments such as "this looks good, but I think it's large enough that we should discuss it on a design doc" or "this won't actually work when X, Y, Z because <domain-specific knowledge>, consider doing this instead".
– GManNickG
May 4 '16 at 20:52
1
While technical ownership can be a major pitfall, people changing items outside their area of proficiency is a huge risk.
– Myles
May 4 '16 at 20:57
@JoeStrazzere it's more like they assumed the scope of their assigned work extended farther than it actually does.
– TheSoundDefense
May 4 '16 at 22:04
2
I think the title doesn't properly reflect the question. The problem seems not to be that he's looking at other parts of the code (which, as others have said, is probably a good thing); it's that he's making changes without telling people or considering the effects of the changes.
– jamesqf
May 5 '16 at 18:39
1
FURTHER EDIT: I think the answer is clear. That this is a bad idea you should encourage work across silos. What you should be doing is building a standard way of communicating when this happens.– Martin York
May 5 '16 at 21:03