One of my teammates is a jack of all trades in our IT shop and I respect his insight.
However, sometimes he reviews my code (he's second in command to our team leader, so that's expected) without a heads up. So sometimes he reviews my changes before they complete the end goal and makes changes right away… and has even broken my work once.
Other times, he has made unnecessary improvements to some of my code that is 3+ months old.
This annoys me for a few reasons:
- I am not always given a chance to fix my mistakes
- He has not taken the time to ask me what I was trying to accomplish when he is confused, which could affect his testing or changes
- I don't always think his code is readable
- Deadlines are not an issue and his current workload doesn't require any work in my projects other than reviewing my code changes.
Anyways, I have told him in the past to please keep me posted if he sees something in my work that he wants to change so that I could take ownership of my code (maybe I should have said "shortcomings") and he's not been responsive.
I fear that I may come off as aggressive when I ask him to explain his changes to me.
He's just a quiet person who keeps to himself, but his actions continue. I don't want to banish him from making code changes (not like I could), because we are a team–but I want to do my part to help our team.
Added clarifications:
- We share 1 development branch. I do not wait until all my changes complete a single task because I risk losing some significant work–so I make sure my changes build and do not break anything.
- My concern is that my teammate doesn't explain the reason or purpose behind his changes. I don't think he should need my blessing, but if we disagree on an approach I thought it would be best to discuss the pros and cons and make a decision once we both understand what is going on.
- I have not discussed this with our team lead yet as I would prefer to resolve personal disagreements without getting management involved unless it is necessary. Since my concern seemed more of personal issue than a threat to our work, I chose to not bother the team lead. I am working on code review process ideas–to help promote the benefits of more organized code reviews without making it all about my pet peeves.
Best Answer
I think most developers find themselves in this position at some point, and I hope that every developer who's felt victimized realizes how frustrating it will be when he or she becomes the senior and feels compelled to clean up code written by juniors.
For me, avoiding conflict in this situation comes down to two things:
Courtesy. Talking to someone about his/her code allows a dev to know that you're interested and you can discuss it as grown up professionals.
Forget about "code ownership" - the team owns the code. Other people wanting to make the changes is a good thing. If a senior dev makes changes that are "unreadable" or worse, then back them out. You don't need to be aggressive, just let an editor know that his/her changes didn't work, and you're more than happy to discuss your reversion.
Remember, team ownership of code is great and it cuts both ways. If you see something that doesn't make sense in someone else's code, then fix it. Being overly possessive and inadequately communicative is a surefire way to a create a poisonous development environment.