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

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP





.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;







up vote
1
down vote

favorite












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".







share|improve this question













closed as off-topic by gnat, Chris E, NotMe, Jim G., Masked Man♦ Apr 22 '16 at 14:28


This question appears to be off-topic. The users who voted to close gave this specific reason:


  • "Real questions have answers. Rather than explaining why your situation is terrible, or why your boss/coworker makes you unhappy, explain what you want to do to make it better. For more information, click here." – gnat, Chris E, NotMe, Masked Man
If this question can be reworded to fit the rules in the help center, please edit the question.












  • Possible duplicate of How to handle a senior colleague who is overstepping their authority?
    – Jim G.
    Apr 21 '16 at 22:40






  • 1




    The coworker was out of line saying that, which shows he's quite happy to proactively antagonise you, be careful around this chap, he doesn't like you or respect you. That is the 'real' issue you need to deal with.
    – Kilisi
    Apr 22 '16 at 6:06







  • 1




    <sarcasm>I wish everyone relying on the software produced by your company the best of luck. </sarcasm> Good luck for the future. Hope you find a company that is run by people with a bit more sense.
    – gnasher729
    Jul 10 '16 at 20:44










  • @gnasher729, thank you.
    – XenoMind
    Jul 11 '16 at 6:31
















up vote
1
down vote

favorite












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".







share|improve this question













closed as off-topic by gnat, Chris E, NotMe, Jim G., Masked Man♦ Apr 22 '16 at 14:28


This question appears to be off-topic. The users who voted to close gave this specific reason:


  • "Real questions have answers. Rather than explaining why your situation is terrible, or why your boss/coworker makes you unhappy, explain what you want to do to make it better. For more information, click here." – gnat, Chris E, NotMe, Masked Man
If this question can be reworded to fit the rules in the help center, please edit the question.












  • Possible duplicate of How to handle a senior colleague who is overstepping their authority?
    – Jim G.
    Apr 21 '16 at 22:40






  • 1




    The coworker was out of line saying that, which shows he's quite happy to proactively antagonise you, be careful around this chap, he doesn't like you or respect you. That is the 'real' issue you need to deal with.
    – Kilisi
    Apr 22 '16 at 6:06







  • 1




    <sarcasm>I wish everyone relying on the software produced by your company the best of luck. </sarcasm> Good luck for the future. Hope you find a company that is run by people with a bit more sense.
    – gnasher729
    Jul 10 '16 at 20:44










  • @gnasher729, thank you.
    – XenoMind
    Jul 11 '16 at 6:31












up vote
1
down vote

favorite









up vote
1
down vote

favorite











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".







share|improve this 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".









share|improve this question












share|improve this question




share|improve this question








edited Jul 10 '16 at 16:36
























asked Apr 21 '16 at 12:47









XenoMind

7161815




7161815




closed as off-topic by gnat, Chris E, NotMe, Jim G., Masked Man♦ Apr 22 '16 at 14:28


This question appears to be off-topic. The users who voted to close gave this specific reason:


  • "Real questions have answers. Rather than explaining why your situation is terrible, or why your boss/coworker makes you unhappy, explain what you want to do to make it better. For more information, click here." – gnat, Chris E, NotMe, Masked Man
If this question can be reworded to fit the rules in the help center, please edit the question.




closed as off-topic by gnat, Chris E, NotMe, Jim G., Masked Man♦ Apr 22 '16 at 14:28


This question appears to be off-topic. The users who voted to close gave this specific reason:


  • "Real questions have answers. Rather than explaining why your situation is terrible, or why your boss/coworker makes you unhappy, explain what you want to do to make it better. For more information, click here." – gnat, Chris E, NotMe, Masked Man
If this question can be reworded to fit the rules in the help center, please edit the question.











  • Possible duplicate of How to handle a senior colleague who is overstepping their authority?
    – Jim G.
    Apr 21 '16 at 22:40






  • 1




    The coworker was out of line saying that, which shows he's quite happy to proactively antagonise you, be careful around this chap, he doesn't like you or respect you. That is the 'real' issue you need to deal with.
    – Kilisi
    Apr 22 '16 at 6:06







  • 1




    <sarcasm>I wish everyone relying on the software produced by your company the best of luck. </sarcasm> Good luck for the future. Hope you find a company that is run by people with a bit more sense.
    – gnasher729
    Jul 10 '16 at 20:44










  • @gnasher729, thank you.
    – XenoMind
    Jul 11 '16 at 6:31
















  • Possible duplicate of How to handle a senior colleague who is overstepping their authority?
    – Jim G.
    Apr 21 '16 at 22:40






  • 1




    The coworker was out of line saying that, which shows he's quite happy to proactively antagonise you, be careful around this chap, he doesn't like you or respect you. That is the 'real' issue you need to deal with.
    – Kilisi
    Apr 22 '16 at 6:06







  • 1




    <sarcasm>I wish everyone relying on the software produced by your company the best of luck. </sarcasm> Good luck for the future. Hope you find a company that is run by people with a bit more sense.
    – gnasher729
    Jul 10 '16 at 20:44










  • @gnasher729, thank you.
    – XenoMind
    Jul 11 '16 at 6:31















Possible duplicate of How to handle a senior colleague who is overstepping their authority?
– Jim G.
Apr 21 '16 at 22:40




Possible duplicate of How to handle a senior colleague who is overstepping their authority?
– Jim G.
Apr 21 '16 at 22:40




1




1




The coworker was out of line saying that, which shows he's quite happy to proactively antagonise you, be careful around this chap, he doesn't like you or respect you. That is the 'real' issue you need to deal with.
– Kilisi
Apr 22 '16 at 6:06





The coworker was out of line saying that, which shows he's quite happy to proactively antagonise you, be careful around this chap, he doesn't like you or respect you. That is the 'real' issue you need to deal with.
– Kilisi
Apr 22 '16 at 6:06





1




1




<sarcasm>I wish everyone relying on the software produced by your company the best of luck. </sarcasm> Good luck for the future. Hope you find a company that is run by people with a bit more sense.
– gnasher729
Jul 10 '16 at 20:44




<sarcasm>I wish everyone relying on the software produced by your company the best of luck. </sarcasm> Good luck for the future. Hope you find a company that is run by people with a bit more sense.
– gnasher729
Jul 10 '16 at 20:44












@gnasher729, thank you.
– XenoMind
Jul 11 '16 at 6:31




@gnasher729, thank you.
– XenoMind
Jul 11 '16 at 6:31










7 Answers
7






active

oldest

votes

















up vote
5
down vote



accepted










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.






share|improve this answer



















  • 2




    Only a few weeks ago our test framework team broke my test running application by making upgrades. I had to refactor my app in order to get it working again. They did not realize their changes would significantly affect how others interacted with the system. Should I quit?
    – Elysian Fields♦
    Apr 21 '16 at 14:56






  • 8




    @enderland You will need to make that decision for yourself. You should quit mis-characterizing. If you want to equate a test breaking code by making an upgrade to the OP's situation then so be it. I don't care to debate it with you.
    – paparazzo
    Apr 21 '16 at 15:05


















up vote
17
down vote













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.






share|improve this answer



















  • 7




    @XenoMind you realize your post reads like you are creating conflict over nothing, right?
    – Elysian Fields♦
    Apr 21 '16 at 13:07






  • 3




    @XenoMind I've done that before too. It happens. Anyone who programs on a team will at some point break someone else's code. It's part of working on a team.
    – Elysian Fields♦
    Apr 21 '16 at 13:28






  • 7




    @XenoMind shrug. Your mind is 100% made up that you are right and your coworker is clueless. You don't want to try to constructively address it with either your coworker or PM. You don't seem to want to try to understand why the coworker did this (only to bash him for being an idiot). You instead want to quit. I... guess I am not sure what to tell you.
    – Elysian Fields♦
    Apr 21 '16 at 13:44






  • 4




    @Paparazzi you mean that he wants to quit because a coworker talked to the PM instead of talking to him? The coworker and PM are not saints here. But reacting and wanting to quit over something like this is not exactly reflective of a proper response. The proper response is to address the issue directly and carefully. It seems pretty obvious the OP is missing some context for how/why this happened - this could be that they are marginalized for some reason, the other coworker is just better in the PM's eyes, a hotfix bug fix, who knows.
    – Elysian Fields♦
    Apr 21 '16 at 14:02







  • 3




    @Paparazzi according to the OP the following happened. 0) coworker made changes (for unknown reasons). 1) OP and coworker had conflict about these (we don't know what conflict means here since OP hasn't said, presumably a heated email exchange). 2) coworker responds that PM has said the coworkers changes are final. 3) OP writes post here asking if he should quit.
    – Elysian Fields♦
    Apr 21 '16 at 14:10

















up vote
4
down vote













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.






share|improve this answer























  • Mostly agree with this answer but I would definite recommend NOT using the phrase "..when it's your code". It's not your code. It is never your code when you are working as part of a team for an employer. Stick to not being bypassed in the decision-making process when a project that you are responsible for it on the line.
    – Carson63000
    Apr 22 '16 at 0:33











  • @Carson63000 - took your advice
    – AndreiROM
    Apr 22 '16 at 4:51










  • Best answer of the lot, I particularly like the slap them down bit (although you probably didn't mean it physically). It's a personal issue this chap has with the OP (active dislike and no respect), the stated problem is just a symptom.
    – Kilisi
    Apr 22 '16 at 6:10

















up vote
2
down vote













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.






share|improve this answer





















  • +1 for forward it to boss... I would do the same with a short message "Hello boss, do I have to put up with crap like this?"
    – Kilisi
    Apr 22 '16 at 6:16

















up vote
2
down vote













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.






share|improve this answer




























    up vote
    1
    down vote













    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? "






    share|improve this answer

















    • 1




      Normally I would agree, but considering the OP is ready to quit over this I don't know if such a direct approach is best. I'd be very surprised if this came out of nowhere without a lot of context surrounding it.
      – Elysian Fields♦
      Apr 21 '16 at 13:17






    • 1




      If he is willing to quit over it, then there is nothing to lose and everything to gain. Does the PM know what's going on? Does he know there's a risk that he is left with a loose gun and nobody else to do the work?
      – gnasher729
      Apr 21 '16 at 13:32










    • Well, it doesn't seem one of those situations. "These changes don't address any specific problems, it's just "slight refactoring"".
      – gnasher729
      Apr 21 '16 at 14:15






    • 1




      No it is characterized as "slight refactoring" by those not responsible for the code. According to the person responsible for the code it breaks a lot of stuff.
      – paparazzo
      Apr 21 '16 at 14:25

















    up vote
    1
    down vote













    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.






    share|improve this answer























    • "that it's not my code, but theirs". That's a good idea. I'll try to talk the PM into transferring project responsibility to that guy, so that he will have to deal with the bugs that he created.
      – XenoMind
      Apr 23 '16 at 7:06


















    7 Answers
    7






    active

    oldest

    votes








    7 Answers
    7






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes








    up vote
    5
    down vote



    accepted










    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.






    share|improve this answer



















    • 2




      Only a few weeks ago our test framework team broke my test running application by making upgrades. I had to refactor my app in order to get it working again. They did not realize their changes would significantly affect how others interacted with the system. Should I quit?
      – Elysian Fields♦
      Apr 21 '16 at 14:56






    • 8




      @enderland You will need to make that decision for yourself. You should quit mis-characterizing. If you want to equate a test breaking code by making an upgrade to the OP's situation then so be it. I don't care to debate it with you.
      – paparazzo
      Apr 21 '16 at 15:05















    up vote
    5
    down vote



    accepted










    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.






    share|improve this answer



















    • 2




      Only a few weeks ago our test framework team broke my test running application by making upgrades. I had to refactor my app in order to get it working again. They did not realize their changes would significantly affect how others interacted with the system. Should I quit?
      – Elysian Fields♦
      Apr 21 '16 at 14:56






    • 8




      @enderland You will need to make that decision for yourself. You should quit mis-characterizing. If you want to equate a test breaking code by making an upgrade to the OP's situation then so be it. I don't care to debate it with you.
      – paparazzo
      Apr 21 '16 at 15:05













    up vote
    5
    down vote



    accepted







    up vote
    5
    down vote



    accepted






    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.






    share|improve this answer















    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.







    share|improve this answer















    share|improve this answer



    share|improve this answer








    edited Apr 21 '16 at 17:35


























    answered Apr 21 '16 at 14:42









    paparazzo

    33.3k657106




    33.3k657106







    • 2




      Only a few weeks ago our test framework team broke my test running application by making upgrades. I had to refactor my app in order to get it working again. They did not realize their changes would significantly affect how others interacted with the system. Should I quit?
      – Elysian Fields♦
      Apr 21 '16 at 14:56






    • 8




      @enderland You will need to make that decision for yourself. You should quit mis-characterizing. If you want to equate a test breaking code by making an upgrade to the OP's situation then so be it. I don't care to debate it with you.
      – paparazzo
      Apr 21 '16 at 15:05













    • 2




      Only a few weeks ago our test framework team broke my test running application by making upgrades. I had to refactor my app in order to get it working again. They did not realize their changes would significantly affect how others interacted with the system. Should I quit?
      – Elysian Fields♦
      Apr 21 '16 at 14:56






    • 8




      @enderland You will need to make that decision for yourself. You should quit mis-characterizing. If you want to equate a test breaking code by making an upgrade to the OP's situation then so be it. I don't care to debate it with you.
      – paparazzo
      Apr 21 '16 at 15:05








    2




    2




    Only a few weeks ago our test framework team broke my test running application by making upgrades. I had to refactor my app in order to get it working again. They did not realize their changes would significantly affect how others interacted with the system. Should I quit?
    – Elysian Fields♦
    Apr 21 '16 at 14:56




    Only a few weeks ago our test framework team broke my test running application by making upgrades. I had to refactor my app in order to get it working again. They did not realize their changes would significantly affect how others interacted with the system. Should I quit?
    – Elysian Fields♦
    Apr 21 '16 at 14:56




    8




    8




    @enderland You will need to make that decision for yourself. You should quit mis-characterizing. If you want to equate a test breaking code by making an upgrade to the OP's situation then so be it. I don't care to debate it with you.
    – paparazzo
    Apr 21 '16 at 15:05





    @enderland You will need to make that decision for yourself. You should quit mis-characterizing. If you want to equate a test breaking code by making an upgrade to the OP's situation then so be it. I don't care to debate it with you.
    – paparazzo
    Apr 21 '16 at 15:05













    up vote
    17
    down vote













    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.






    share|improve this answer



















    • 7




      @XenoMind you realize your post reads like you are creating conflict over nothing, right?
      – Elysian Fields♦
      Apr 21 '16 at 13:07






    • 3




      @XenoMind I've done that before too. It happens. Anyone who programs on a team will at some point break someone else's code. It's part of working on a team.
      – Elysian Fields♦
      Apr 21 '16 at 13:28






    • 7




      @XenoMind shrug. Your mind is 100% made up that you are right and your coworker is clueless. You don't want to try to constructively address it with either your coworker or PM. You don't seem to want to try to understand why the coworker did this (only to bash him for being an idiot). You instead want to quit. I... guess I am not sure what to tell you.
      – Elysian Fields♦
      Apr 21 '16 at 13:44






    • 4




      @Paparazzi you mean that he wants to quit because a coworker talked to the PM instead of talking to him? The coworker and PM are not saints here. But reacting and wanting to quit over something like this is not exactly reflective of a proper response. The proper response is to address the issue directly and carefully. It seems pretty obvious the OP is missing some context for how/why this happened - this could be that they are marginalized for some reason, the other coworker is just better in the PM's eyes, a hotfix bug fix, who knows.
      – Elysian Fields♦
      Apr 21 '16 at 14:02







    • 3




      @Paparazzi according to the OP the following happened. 0) coworker made changes (for unknown reasons). 1) OP and coworker had conflict about these (we don't know what conflict means here since OP hasn't said, presumably a heated email exchange). 2) coworker responds that PM has said the coworkers changes are final. 3) OP writes post here asking if he should quit.
      – Elysian Fields♦
      Apr 21 '16 at 14:10














    up vote
    17
    down vote













    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.






    share|improve this answer



















    • 7




      @XenoMind you realize your post reads like you are creating conflict over nothing, right?
      – Elysian Fields♦
      Apr 21 '16 at 13:07






    • 3




      @XenoMind I've done that before too. It happens. Anyone who programs on a team will at some point break someone else's code. It's part of working on a team.
      – Elysian Fields♦
      Apr 21 '16 at 13:28






    • 7




      @XenoMind shrug. Your mind is 100% made up that you are right and your coworker is clueless. You don't want to try to constructively address it with either your coworker or PM. You don't seem to want to try to understand why the coworker did this (only to bash him for being an idiot). You instead want to quit. I... guess I am not sure what to tell you.
      – Elysian Fields♦
      Apr 21 '16 at 13:44






    • 4




      @Paparazzi you mean that he wants to quit because a coworker talked to the PM instead of talking to him? The coworker and PM are not saints here. But reacting and wanting to quit over something like this is not exactly reflective of a proper response. The proper response is to address the issue directly and carefully. It seems pretty obvious the OP is missing some context for how/why this happened - this could be that they are marginalized for some reason, the other coworker is just better in the PM's eyes, a hotfix bug fix, who knows.
      – Elysian Fields♦
      Apr 21 '16 at 14:02







    • 3




      @Paparazzi according to the OP the following happened. 0) coworker made changes (for unknown reasons). 1) OP and coworker had conflict about these (we don't know what conflict means here since OP hasn't said, presumably a heated email exchange). 2) coworker responds that PM has said the coworkers changes are final. 3) OP writes post here asking if he should quit.
      – Elysian Fields♦
      Apr 21 '16 at 14:10












    up vote
    17
    down vote










    up vote
    17
    down vote









    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.






    share|improve this answer















    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.







    share|improve this answer















    share|improve this answer



    share|improve this answer








    edited Apr 22 '16 at 4:57









    Wesley Long

    44.6k15100159




    44.6k15100159











    answered Apr 21 '16 at 12:55









    Elysian Fields♦

    96.7k46292449




    96.7k46292449







    • 7




      @XenoMind you realize your post reads like you are creating conflict over nothing, right?
      – Elysian Fields♦
      Apr 21 '16 at 13:07






    • 3




      @XenoMind I've done that before too. It happens. Anyone who programs on a team will at some point break someone else's code. It's part of working on a team.
      – Elysian Fields♦
      Apr 21 '16 at 13:28






    • 7




      @XenoMind shrug. Your mind is 100% made up that you are right and your coworker is clueless. You don't want to try to constructively address it with either your coworker or PM. You don't seem to want to try to understand why the coworker did this (only to bash him for being an idiot). You instead want to quit. I... guess I am not sure what to tell you.
      – Elysian Fields♦
      Apr 21 '16 at 13:44






    • 4




      @Paparazzi you mean that he wants to quit because a coworker talked to the PM instead of talking to him? The coworker and PM are not saints here. But reacting and wanting to quit over something like this is not exactly reflective of a proper response. The proper response is to address the issue directly and carefully. It seems pretty obvious the OP is missing some context for how/why this happened - this could be that they are marginalized for some reason, the other coworker is just better in the PM's eyes, a hotfix bug fix, who knows.
      – Elysian Fields♦
      Apr 21 '16 at 14:02







    • 3




      @Paparazzi according to the OP the following happened. 0) coworker made changes (for unknown reasons). 1) OP and coworker had conflict about these (we don't know what conflict means here since OP hasn't said, presumably a heated email exchange). 2) coworker responds that PM has said the coworkers changes are final. 3) OP writes post here asking if he should quit.
      – Elysian Fields♦
      Apr 21 '16 at 14:10












    • 7




      @XenoMind you realize your post reads like you are creating conflict over nothing, right?
      – Elysian Fields♦
      Apr 21 '16 at 13:07






    • 3




      @XenoMind I've done that before too. It happens. Anyone who programs on a team will at some point break someone else's code. It's part of working on a team.
      – Elysian Fields♦
      Apr 21 '16 at 13:28






    • 7




      @XenoMind shrug. Your mind is 100% made up that you are right and your coworker is clueless. You don't want to try to constructively address it with either your coworker or PM. You don't seem to want to try to understand why the coworker did this (only to bash him for being an idiot). You instead want to quit. I... guess I am not sure what to tell you.
      – Elysian Fields♦
      Apr 21 '16 at 13:44






    • 4




      @Paparazzi you mean that he wants to quit because a coworker talked to the PM instead of talking to him? The coworker and PM are not saints here. But reacting and wanting to quit over something like this is not exactly reflective of a proper response. The proper response is to address the issue directly and carefully. It seems pretty obvious the OP is missing some context for how/why this happened - this could be that they are marginalized for some reason, the other coworker is just better in the PM's eyes, a hotfix bug fix, who knows.
      – Elysian Fields♦
      Apr 21 '16 at 14:02







    • 3




      @Paparazzi according to the OP the following happened. 0) coworker made changes (for unknown reasons). 1) OP and coworker had conflict about these (we don't know what conflict means here since OP hasn't said, presumably a heated email exchange). 2) coworker responds that PM has said the coworkers changes are final. 3) OP writes post here asking if he should quit.
      – Elysian Fields♦
      Apr 21 '16 at 14:10







    7




    7




    @XenoMind you realize your post reads like you are creating conflict over nothing, right?
    – Elysian Fields♦
    Apr 21 '16 at 13:07




    @XenoMind you realize your post reads like you are creating conflict over nothing, right?
    – Elysian Fields♦
    Apr 21 '16 at 13:07




    3




    3




    @XenoMind I've done that before too. It happens. Anyone who programs on a team will at some point break someone else's code. It's part of working on a team.
    – Elysian Fields♦
    Apr 21 '16 at 13:28




    @XenoMind I've done that before too. It happens. Anyone who programs on a team will at some point break someone else's code. It's part of working on a team.
    – Elysian Fields♦
    Apr 21 '16 at 13:28




    7




    7




    @XenoMind shrug. Your mind is 100% made up that you are right and your coworker is clueless. You don't want to try to constructively address it with either your coworker or PM. You don't seem to want to try to understand why the coworker did this (only to bash him for being an idiot). You instead want to quit. I... guess I am not sure what to tell you.
    – Elysian Fields♦
    Apr 21 '16 at 13:44




    @XenoMind shrug. Your mind is 100% made up that you are right and your coworker is clueless. You don't want to try to constructively address it with either your coworker or PM. You don't seem to want to try to understand why the coworker did this (only to bash him for being an idiot). You instead want to quit. I... guess I am not sure what to tell you.
    – Elysian Fields♦
    Apr 21 '16 at 13:44




    4




    4




    @Paparazzi you mean that he wants to quit because a coworker talked to the PM instead of talking to him? The coworker and PM are not saints here. But reacting and wanting to quit over something like this is not exactly reflective of a proper response. The proper response is to address the issue directly and carefully. It seems pretty obvious the OP is missing some context for how/why this happened - this could be that they are marginalized for some reason, the other coworker is just better in the PM's eyes, a hotfix bug fix, who knows.
    – Elysian Fields♦
    Apr 21 '16 at 14:02





    @Paparazzi you mean that he wants to quit because a coworker talked to the PM instead of talking to him? The coworker and PM are not saints here. But reacting and wanting to quit over something like this is not exactly reflective of a proper response. The proper response is to address the issue directly and carefully. It seems pretty obvious the OP is missing some context for how/why this happened - this could be that they are marginalized for some reason, the other coworker is just better in the PM's eyes, a hotfix bug fix, who knows.
    – Elysian Fields♦
    Apr 21 '16 at 14:02





    3




    3




    @Paparazzi according to the OP the following happened. 0) coworker made changes (for unknown reasons). 1) OP and coworker had conflict about these (we don't know what conflict means here since OP hasn't said, presumably a heated email exchange). 2) coworker responds that PM has said the coworkers changes are final. 3) OP writes post here asking if he should quit.
    – Elysian Fields♦
    Apr 21 '16 at 14:10




    @Paparazzi according to the OP the following happened. 0) coworker made changes (for unknown reasons). 1) OP and coworker had conflict about these (we don't know what conflict means here since OP hasn't said, presumably a heated email exchange). 2) coworker responds that PM has said the coworkers changes are final. 3) OP writes post here asking if he should quit.
    – Elysian Fields♦
    Apr 21 '16 at 14:10










    up vote
    4
    down vote













    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.






    share|improve this answer























    • Mostly agree with this answer but I would definite recommend NOT using the phrase "..when it's your code". It's not your code. It is never your code when you are working as part of a team for an employer. Stick to not being bypassed in the decision-making process when a project that you are responsible for it on the line.
      – Carson63000
      Apr 22 '16 at 0:33











    • @Carson63000 - took your advice
      – AndreiROM
      Apr 22 '16 at 4:51










    • Best answer of the lot, I particularly like the slap them down bit (although you probably didn't mean it physically). It's a personal issue this chap has with the OP (active dislike and no respect), the stated problem is just a symptom.
      – Kilisi
      Apr 22 '16 at 6:10














    up vote
    4
    down vote













    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.






    share|improve this answer























    • Mostly agree with this answer but I would definite recommend NOT using the phrase "..when it's your code". It's not your code. It is never your code when you are working as part of a team for an employer. Stick to not being bypassed in the decision-making process when a project that you are responsible for it on the line.
      – Carson63000
      Apr 22 '16 at 0:33











    • @Carson63000 - took your advice
      – AndreiROM
      Apr 22 '16 at 4:51










    • Best answer of the lot, I particularly like the slap them down bit (although you probably didn't mean it physically). It's a personal issue this chap has with the OP (active dislike and no respect), the stated problem is just a symptom.
      – Kilisi
      Apr 22 '16 at 6:10












    up vote
    4
    down vote










    up vote
    4
    down vote









    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.






    share|improve this answer















    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.







    share|improve this answer















    share|improve this answer



    share|improve this answer








    edited Apr 22 '16 at 4:51


























    answered Apr 21 '16 at 16:42









    AndreiROM

    44.1k21101173




    44.1k21101173











    • Mostly agree with this answer but I would definite recommend NOT using the phrase "..when it's your code". It's not your code. It is never your code when you are working as part of a team for an employer. Stick to not being bypassed in the decision-making process when a project that you are responsible for it on the line.
      – Carson63000
      Apr 22 '16 at 0:33











    • @Carson63000 - took your advice
      – AndreiROM
      Apr 22 '16 at 4:51










    • Best answer of the lot, I particularly like the slap them down bit (although you probably didn't mean it physically). It's a personal issue this chap has with the OP (active dislike and no respect), the stated problem is just a symptom.
      – Kilisi
      Apr 22 '16 at 6:10
















    • Mostly agree with this answer but I would definite recommend NOT using the phrase "..when it's your code". It's not your code. It is never your code when you are working as part of a team for an employer. Stick to not being bypassed in the decision-making process when a project that you are responsible for it on the line.
      – Carson63000
      Apr 22 '16 at 0:33











    • @Carson63000 - took your advice
      – AndreiROM
      Apr 22 '16 at 4:51










    • Best answer of the lot, I particularly like the slap them down bit (although you probably didn't mean it physically). It's a personal issue this chap has with the OP (active dislike and no respect), the stated problem is just a symptom.
      – Kilisi
      Apr 22 '16 at 6:10















    Mostly agree with this answer but I would definite recommend NOT using the phrase "..when it's your code". It's not your code. It is never your code when you are working as part of a team for an employer. Stick to not being bypassed in the decision-making process when a project that you are responsible for it on the line.
    – Carson63000
    Apr 22 '16 at 0:33





    Mostly agree with this answer but I would definite recommend NOT using the phrase "..when it's your code". It's not your code. It is never your code when you are working as part of a team for an employer. Stick to not being bypassed in the decision-making process when a project that you are responsible for it on the line.
    – Carson63000
    Apr 22 '16 at 0:33













    @Carson63000 - took your advice
    – AndreiROM
    Apr 22 '16 at 4:51




    @Carson63000 - took your advice
    – AndreiROM
    Apr 22 '16 at 4:51












    Best answer of the lot, I particularly like the slap them down bit (although you probably didn't mean it physically). It's a personal issue this chap has with the OP (active dislike and no respect), the stated problem is just a symptom.
    – Kilisi
    Apr 22 '16 at 6:10




    Best answer of the lot, I particularly like the slap them down bit (although you probably didn't mean it physically). It's a personal issue this chap has with the OP (active dislike and no respect), the stated problem is just a symptom.
    – Kilisi
    Apr 22 '16 at 6:10










    up vote
    2
    down vote













    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.






    share|improve this answer





















    • +1 for forward it to boss... I would do the same with a short message "Hello boss, do I have to put up with crap like this?"
      – Kilisi
      Apr 22 '16 at 6:16














    up vote
    2
    down vote













    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.






    share|improve this answer





















    • +1 for forward it to boss... I would do the same with a short message "Hello boss, do I have to put up with crap like this?"
      – Kilisi
      Apr 22 '16 at 6:16












    up vote
    2
    down vote










    up vote
    2
    down vote









    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.






    share|improve this answer













    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.







    share|improve this answer













    share|improve this answer



    share|improve this answer











    answered Apr 21 '16 at 14:23









    ventsyv

    1,243313




    1,243313











    • +1 for forward it to boss... I would do the same with a short message "Hello boss, do I have to put up with crap like this?"
      – Kilisi
      Apr 22 '16 at 6:16
















    • +1 for forward it to boss... I would do the same with a short message "Hello boss, do I have to put up with crap like this?"
      – Kilisi
      Apr 22 '16 at 6:16















    +1 for forward it to boss... I would do the same with a short message "Hello boss, do I have to put up with crap like this?"
    – Kilisi
    Apr 22 '16 at 6:16




    +1 for forward it to boss... I would do the same with a short message "Hello boss, do I have to put up with crap like this?"
    – Kilisi
    Apr 22 '16 at 6:16










    up vote
    2
    down vote













    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.






    share|improve this answer

























      up vote
      2
      down vote













      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.






      share|improve this answer























        up vote
        2
        down vote










        up vote
        2
        down vote









        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.






        share|improve this answer













        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.







        share|improve this answer













        share|improve this answer



        share|improve this answer











        answered Apr 21 '16 at 19:46









        Kurt Tappe

        73135




        73135




















            up vote
            1
            down vote













            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? "






            share|improve this answer

















            • 1




              Normally I would agree, but considering the OP is ready to quit over this I don't know if such a direct approach is best. I'd be very surprised if this came out of nowhere without a lot of context surrounding it.
              – Elysian Fields♦
              Apr 21 '16 at 13:17






            • 1




              If he is willing to quit over it, then there is nothing to lose and everything to gain. Does the PM know what's going on? Does he know there's a risk that he is left with a loose gun and nobody else to do the work?
              – gnasher729
              Apr 21 '16 at 13:32










            • Well, it doesn't seem one of those situations. "These changes don't address any specific problems, it's just "slight refactoring"".
              – gnasher729
              Apr 21 '16 at 14:15






            • 1




              No it is characterized as "slight refactoring" by those not responsible for the code. According to the person responsible for the code it breaks a lot of stuff.
              – paparazzo
              Apr 21 '16 at 14:25














            up vote
            1
            down vote













            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? "






            share|improve this answer

















            • 1




              Normally I would agree, but considering the OP is ready to quit over this I don't know if such a direct approach is best. I'd be very surprised if this came out of nowhere without a lot of context surrounding it.
              – Elysian Fields♦
              Apr 21 '16 at 13:17






            • 1




              If he is willing to quit over it, then there is nothing to lose and everything to gain. Does the PM know what's going on? Does he know there's a risk that he is left with a loose gun and nobody else to do the work?
              – gnasher729
              Apr 21 '16 at 13:32










            • Well, it doesn't seem one of those situations. "These changes don't address any specific problems, it's just "slight refactoring"".
              – gnasher729
              Apr 21 '16 at 14:15






            • 1




              No it is characterized as "slight refactoring" by those not responsible for the code. According to the person responsible for the code it breaks a lot of stuff.
              – paparazzo
              Apr 21 '16 at 14:25












            up vote
            1
            down vote










            up vote
            1
            down vote









            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? "






            share|improve this answer













            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? "







            share|improve this answer













            share|improve this answer



            share|improve this answer











            answered Apr 21 '16 at 13:14









            gnasher729

            70.7k31131222




            70.7k31131222







            • 1




              Normally I would agree, but considering the OP is ready to quit over this I don't know if such a direct approach is best. I'd be very surprised if this came out of nowhere without a lot of context surrounding it.
              – Elysian Fields♦
              Apr 21 '16 at 13:17






            • 1




              If he is willing to quit over it, then there is nothing to lose and everything to gain. Does the PM know what's going on? Does he know there's a risk that he is left with a loose gun and nobody else to do the work?
              – gnasher729
              Apr 21 '16 at 13:32










            • Well, it doesn't seem one of those situations. "These changes don't address any specific problems, it's just "slight refactoring"".
              – gnasher729
              Apr 21 '16 at 14:15






            • 1




              No it is characterized as "slight refactoring" by those not responsible for the code. According to the person responsible for the code it breaks a lot of stuff.
              – paparazzo
              Apr 21 '16 at 14:25












            • 1




              Normally I would agree, but considering the OP is ready to quit over this I don't know if such a direct approach is best. I'd be very surprised if this came out of nowhere without a lot of context surrounding it.
              – Elysian Fields♦
              Apr 21 '16 at 13:17






            • 1




              If he is willing to quit over it, then there is nothing to lose and everything to gain. Does the PM know what's going on? Does he know there's a risk that he is left with a loose gun and nobody else to do the work?
              – gnasher729
              Apr 21 '16 at 13:32










            • Well, it doesn't seem one of those situations. "These changes don't address any specific problems, it's just "slight refactoring"".
              – gnasher729
              Apr 21 '16 at 14:15






            • 1




              No it is characterized as "slight refactoring" by those not responsible for the code. According to the person responsible for the code it breaks a lot of stuff.
              – paparazzo
              Apr 21 '16 at 14:25







            1




            1




            Normally I would agree, but considering the OP is ready to quit over this I don't know if such a direct approach is best. I'd be very surprised if this came out of nowhere without a lot of context surrounding it.
            – Elysian Fields♦
            Apr 21 '16 at 13:17




            Normally I would agree, but considering the OP is ready to quit over this I don't know if such a direct approach is best. I'd be very surprised if this came out of nowhere without a lot of context surrounding it.
            – Elysian Fields♦
            Apr 21 '16 at 13:17




            1




            1




            If he is willing to quit over it, then there is nothing to lose and everything to gain. Does the PM know what's going on? Does he know there's a risk that he is left with a loose gun and nobody else to do the work?
            – gnasher729
            Apr 21 '16 at 13:32




            If he is willing to quit over it, then there is nothing to lose and everything to gain. Does the PM know what's going on? Does he know there's a risk that he is left with a loose gun and nobody else to do the work?
            – gnasher729
            Apr 21 '16 at 13:32












            Well, it doesn't seem one of those situations. "These changes don't address any specific problems, it's just "slight refactoring"".
            – gnasher729
            Apr 21 '16 at 14:15




            Well, it doesn't seem one of those situations. "These changes don't address any specific problems, it's just "slight refactoring"".
            – gnasher729
            Apr 21 '16 at 14:15




            1




            1




            No it is characterized as "slight refactoring" by those not responsible for the code. According to the person responsible for the code it breaks a lot of stuff.
            – paparazzo
            Apr 21 '16 at 14:25




            No it is characterized as "slight refactoring" by those not responsible for the code. According to the person responsible for the code it breaks a lot of stuff.
            – paparazzo
            Apr 21 '16 at 14:25










            up vote
            1
            down vote













            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.






            share|improve this answer























            • "that it's not my code, but theirs". That's a good idea. I'll try to talk the PM into transferring project responsibility to that guy, so that he will have to deal with the bugs that he created.
              – XenoMind
              Apr 23 '16 at 7:06















            up vote
            1
            down vote













            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.






            share|improve this answer























            • "that it's not my code, but theirs". That's a good idea. I'll try to talk the PM into transferring project responsibility to that guy, so that he will have to deal with the bugs that he created.
              – XenoMind
              Apr 23 '16 at 7:06













            up vote
            1
            down vote










            up vote
            1
            down vote









            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.






            share|improve this answer















            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.







            share|improve this answer















            share|improve this answer



            share|improve this answer








            edited Apr 22 '16 at 13:59


























            answered Apr 22 '16 at 13:43









            Dan

            4,752412




            4,752412











            • "that it's not my code, but theirs". That's a good idea. I'll try to talk the PM into transferring project responsibility to that guy, so that he will have to deal with the bugs that he created.
              – XenoMind
              Apr 23 '16 at 7:06

















            • "that it's not my code, but theirs". That's a good idea. I'll try to talk the PM into transferring project responsibility to that guy, so that he will have to deal with the bugs that he created.
              – XenoMind
              Apr 23 '16 at 7:06
















            "that it's not my code, but theirs". That's a good idea. I'll try to talk the PM into transferring project responsibility to that guy, so that he will have to deal with the bugs that he created.
            – XenoMind
            Apr 23 '16 at 7:06





            "that it's not my code, but theirs". That's a good idea. I'll try to talk the PM into transferring project responsibility to that guy, so that he will have to deal with the bugs that he created.
            – XenoMind
            Apr 23 '16 at 7:06



            Comments

            Popular posts from this blog

            What does second last employer means? [closed]

            Installing NextGIS Connect into QGIS 3?

            One-line joke