How do I take responsibility for my code when colleague makes unnecessary improvements without notice?
- by Jesslyn
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.
