"I'm the boss here" attitude from a peer [closed]

Question

I've got a message from a peer programmer (over a conflict happened due to his changes in the code I'm responsible for, done over my head). He wrote that they (he and PM) already decided to do it this way, aren't going to change anything and my opinion means nothing. That guy is in the same position, and I wasn't told about any promotions. The PM is elusive and I couldn't get any certain statements from him.

Any ideas how to resolve this situation? Because I see only 2 solutions - bow or resign, and I don't like either.

UPD I wasn't told about any problems on my side before this happened. These changes don't address any specific problems, it's just a "slight refactoring". The problem is that this refactoring is not small at all, and it breaks things.

UPD2 this question is not about a senior colleague. It's about a peer.

UPD3 so, I talked to the manager and explained him that the situation when another guy rewrites my code without asking me anything is not how the things should be done. However, if he really wants to keep his changes - he has to take full responsibility for the project from now on. Some time later, I was kicked out of the company "in a process of working teams optimization".

Answer 1

I get you are getting beat up over this but I would consider quitting also.

In summary

• Code you are responsible for

• You had not been informed of any problems

• Peer meets with PM over refactoring code you are responsible for
  You are not included nor informed

• According to peer an executive decision is made to refactor the code you are responsible for
  You are not included in this decision

• You are informed of the executive decision by peer not PM
  At a minimum this executive decision should have come from the PM

• The change is characterized as "slight refactoring"
  In the opinion of the OP responsible for the code it is not slight and breaks a lot of stuff

This not proper. If you are responsible for the code then you deserve to be part of design decision. Even if you are shot down on every detail you should have a say. If they characterize as "slight refactoring" and you say it is not slight and breaks stuff then clearly there is a major disconnect. At a minimum they should explain to you how this "slight". Maybe you are missing something and maybe they are wrong. This is not how to manage a software team. This not how to manage software design.

You have couple problems:

1. Change is not minor
2. Process going forward

On the first I would outline in writing that the change is not minor. Outline how it effects the code overall and the stuff it would break. Ask for a meeting to discuss the matter.

On the second you need to have a heart to heart with the PM. Tell him straight up you think you deserve to be involved in design decisions regarding your code. If he tells you no I will make executive decision and may or may not include you then just tell him don't agree that is effective but you will follow orders. From there make a decision to suck it up look for another job. If the PM refuses to even have a process meeting with you then need to make a decision to suck it up or look for another job. Don't threaten to quit - nothing good would come from that. I personally would look for another job. I don't mind losing an architecture decision about code I am responsible for but I feel like I deserve to be part of the discussion.

Answer 2

Is your pride more important than your job?

Also, it's not "Your code," it's "The company's code."

The way you avoid this problem is constructively disagreeing. It seems like you disagreed to the point the other programmer went to the PM to get their input and then a decision was made without you. This suggests a fair bit of dysfunctionality on your team. My speculation is you are not someone who handles confrontation well (perhaps not, something to consider at least).

If you disagree, you should do the following:

• Discuss with the team (as you and your coworker did not seem to do)
• If you can't agree, escalate to a decision maker who can make the decision

Any ideas how to resolve this situation?

Go with what the PM said. Work to improve your relationships with both the PM and your coworker.

Much of work is doing things we don't want to do. Sometimes that means setting aside personal pride.

If you want bonus points here, try to address the problem proactively for the future. Talk with the PM and this coworker along the lines of, "how can we improve communication over subjects like this in the future? I felt like you went over my head and forced changes on me. Can we make a process to avoid this?" or something like this.

UPD I wasn't told about any problems on my side before this happened. These changes don't address any specific problems, it's just a "slight refactoring". The problem is that this refactoring is not small at all, and it breaks things.

If someone breaks things, then the normal response is to discuss with them:

• "Hey, this refactor broke a bunch of things, we need to revert it until it addresses them"
  • did you not have any tests?
  • Do you have API versioning if this was another internal API
• Make changes
  • Review them (you do have code review?)
• Address the concerns

Instead you could also approach this with the coworker and the PM, "hey this refactor you did caused X, Y, and Z to occur too. What is the plan to fix those and how can we prevent this from happening with future refactors?"

Another option is to talk with your manager and ask how they think you should proceed. If your manager is remotely competent they will ask what your efforts to resolve this situation have been.

Also, consider that you seem to not know why this change was made. Maybe it was to fix a bug somewhere else that was affecting customers. Maybe it's because they hate you. Who knows? Going to war over this without knowing that has some serious potential to make you look bad.

If you want to go quit because someone else made changes to your code, by all means do.

Answer 3

There are two things which need to be addressed in this situation:

1. Speak to the Project Manager

Do as many of these people have told you and go speak to the PM in person (and alone). Explain - in no uncertain terms - that the proposed changes have big implications. Make sure you get your say and express what the problems are.

Also ask the PM whether your colleague has received a promotion you were not aware of. I'm expecting the answer to be "No", which is when you get to ask why it is that it's this person and not the PM announcing you about decisions made without your input.

In other words I would call the PM out for going around your back and passing the buck on who told you about it.

2. Establish Boundaries

Go have a chat with your coworker. Tell him straight up that you won't be spoken to in that manner, or be bypassed in the decision making process when it's your project on the line.

If you don't establish boundaries and slap him down when he acts like a jerk then he's going to simply keep coming after you in the future.

I too have had to deal with a couple of workplace bullies in my (relatively short) career - one of them was a senior dev, the other a fellow programmer that had been there much longer than I. In both cases they felt that their seniority allowed them to ride over me and my opinions rough-shod (going as far as to tell me to "fuck off").

With people like these it is vitally important that you establish right away whether you're going to be the type to just take it and "let them win" (in their eyes you backing down is a win), or stand up to them.

In my own case both devs started to simply ignore or avoid me, which was fine by me. They never tried to meddle with my projects again either. When we had to interact we kept it short and professional, but neither of them dared to try and push me around again.

In my opinion you need to confront this fellow developer sooner rather than later.

Answer 4

Send an email to him and the PM, including your co-workers original message and ask for a meeting. If you company's culture allows it, go ahead and schedule the meeting for a time convenient to all.

In your email, include that you were not aware that the design has been changed and that you have concerns that the new design could break A,B, and C.

Your PM will not be likely to ignore the issue if your concerns are presented in writing. Further, including the original rude email will probably make him sympathetic to your cause - nobody likes rude people.

At the meeting, present your arguments. Make sure your are civil and polite but make your case clearly.

In most cases a compromised will be reached and your coworker will probably be told to be more respectful.

Answer 5

I want to stress something: You need to cover your *ss in writing. Compose an email (yes, email, not an IM that can go away) officially stating that 1) The code change was done by your colleague, 2) That it breaks the product, 3) That in your professional opinion the change should be reverted. You need to get all of this on the record now, because it sounds like poop will hit the fan and you will get blamed. Do not revert the code without permission. Just go on the record with the above info. Then you have performed due diligence.

EDIT: Also seriously consider 2A) The code was apparently not tested. In this day & age, you do not test in Production, you test in UAT/Dev. If your colleague had tested in Production where I work, he'd be in big trouble.

Answer 6

There are two possibilities: Either this programmer has bamboozled the PM into believing that he is the hottest programmer on earth, or he has done no such think and is just full of it. Either way, what he is doing is unacceptable: "Slight refactoring" and then messing it up (which means he committed changes without any code review, which is generally considered a deadly sin) is unacceptable.

No matter how elusive your PM is, you need to get hold of him and sort this out. Since your opponent isn't exactly a shrinking violet, your conversation should start with "xxx made some completely unnecessary changes and messed it up. He tells me that you agreed with this, without consulting anyone who actually knows the code base, which I find hard to believe. Is that true? "

Answer 7

All great opinions but I didn't hear anyone mention about this happening to them. I wanted to share I had this happen to me as well before. I would write code and submit, then a peer - who is not a manager - decided to meet with his manager to discuss changing my code. I discovered this and went to my boss who then agreed with the other and basically told me to deal with it. The peer's changes would break something or remove very key logic. My boss would accept it but then when it breaks would get upset at us even though we anticipated/voiced those concerns on the refactoring. Ultimately the key product was lost and the code was basically converted to legacy.

I eventually got into the idea that it's not my code, but theirs. I left it like that and ultimately decided to leave the company with this being one of many problems. I understand your frustration but ultimately it isn't your code but theirs. You can attempt to ask them if they can notify you when your code is changed, but ultimately it is about the culture of the place and deciding if that is something you want to accept. You shouldn't take it personally either.