Coworker is overcomplicating a project to the extreme - and I'll be forced to maintain if I don't speak up - What do I do? [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
0
down vote

favorite












I am a software engineer and one of my coworkers is going off the deep end - I can identify pattern obsession tendencies, misapplication of programming models (async-await for a list needed on the back-end), and other terrible implementations of relatively simple stuff that now makes it incredibly complicated.



Full disclosure: I was pulled off the project publicly earlier in the process after my boss did a code review (we don't really do code reviews, and I'll admit the code was not good because I was being lazy) and because he thought I wasn't 'getting it'. I was pissed and embarrassed by it, and when I watched the commits afterward I saw this coworker doing the exact thing that I did, only they weren't being watched and humiliated. This might be because this coworker has more experience than I do so my boss didn't check their commits. Both myself and 2 other developers (not the one who wrote it) have spoken about the code and the decisions being made and all are in agreement that it sucks.



I have now been put back on the project, and am dealing with the overhead of all the junk code. I don't want this responsibility, and it's hard to do really anything on it.



I've spoken directly to the coworker, voiced my concerns, and they've gone ahead and done it their way anyway. This is an office that very strictly follows TDD and SOLID principles, but this coworker is not doing any of it.



I don't want to shoulder the responsibility for maintenance on this project, but I don't want the other coworker to be humiliated like I was. What can I do?







share|improve this question














closed as off-topic by gnat, Garrison Neely, jcmeloni, Chris E, IDrinkandIKnowThings Feb 10 '15 at 4:40


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, Garrison Neely, jcmeloni, Chris E, IDrinkandIKnowThings
If this question can be reworded to fit the rules in the help center, please edit the question.








  • 3




    I think the core of the problem is that the code reviews are embarrassing/humiliating. If you can address that, then having some sort of "Is this what we want?" look at your coworker's output is a non-issue, plus it means that you don't get treated that way again either.
    – Hazel
    Feb 4 '15 at 12:50






  • 5




    "This is an office that very strictly follows TDD and SOLID principles, but they are not doing any of it." That's a contradiction right there. Either the office is following or it's not following. Rephrase your sentence.
    – Vietnhi Phuvan
    Feb 4 '15 at 12:51






  • 3




    OK, let him have his chance at spending quality time with the boss. Unless you want to make a career out of saving him from himself. You felt humiliated but it didn't kill you. I expect it won't kill him either. I get humiliated. I learn. I move on. Not the end of the world. And I've been humiliated more than a few times :) I'll give you credit for being considerate and generous in your atttitude.
    – Vietnhi Phuvan
    Feb 4 '15 at 12:56







  • 2




    You talked to your co-worker and he chose not to listen. Wash your hands of it, let him take the consequences of his actions. You've done what you could, that's it. Walk away from him and don't look back. Let him take care of himself. You've got other things to do.
    – Vietnhi Phuvan
    Feb 4 '15 at 13:04











  • Even if the code review is bad, it shouldn't be made to be humiliating. The purpose is a legitimate critique and exchange of knowledge. It's a terrible idea to have one code review, and then basically punish the employee because of it -- now you're taking away the employee's chance to respond to the critique, and you're giving them every reason to want to avoid code reviews.
    – Kai
    Feb 5 '15 at 18:05
















up vote
0
down vote

favorite












I am a software engineer and one of my coworkers is going off the deep end - I can identify pattern obsession tendencies, misapplication of programming models (async-await for a list needed on the back-end), and other terrible implementations of relatively simple stuff that now makes it incredibly complicated.



Full disclosure: I was pulled off the project publicly earlier in the process after my boss did a code review (we don't really do code reviews, and I'll admit the code was not good because I was being lazy) and because he thought I wasn't 'getting it'. I was pissed and embarrassed by it, and when I watched the commits afterward I saw this coworker doing the exact thing that I did, only they weren't being watched and humiliated. This might be because this coworker has more experience than I do so my boss didn't check their commits. Both myself and 2 other developers (not the one who wrote it) have spoken about the code and the decisions being made and all are in agreement that it sucks.



I have now been put back on the project, and am dealing with the overhead of all the junk code. I don't want this responsibility, and it's hard to do really anything on it.



I've spoken directly to the coworker, voiced my concerns, and they've gone ahead and done it their way anyway. This is an office that very strictly follows TDD and SOLID principles, but this coworker is not doing any of it.



I don't want to shoulder the responsibility for maintenance on this project, but I don't want the other coworker to be humiliated like I was. What can I do?







share|improve this question














closed as off-topic by gnat, Garrison Neely, jcmeloni, Chris E, IDrinkandIKnowThings Feb 10 '15 at 4:40


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, Garrison Neely, jcmeloni, Chris E, IDrinkandIKnowThings
If this question can be reworded to fit the rules in the help center, please edit the question.








  • 3




    I think the core of the problem is that the code reviews are embarrassing/humiliating. If you can address that, then having some sort of "Is this what we want?" look at your coworker's output is a non-issue, plus it means that you don't get treated that way again either.
    – Hazel
    Feb 4 '15 at 12:50






  • 5




    "This is an office that very strictly follows TDD and SOLID principles, but they are not doing any of it." That's a contradiction right there. Either the office is following or it's not following. Rephrase your sentence.
    – Vietnhi Phuvan
    Feb 4 '15 at 12:51






  • 3




    OK, let him have his chance at spending quality time with the boss. Unless you want to make a career out of saving him from himself. You felt humiliated but it didn't kill you. I expect it won't kill him either. I get humiliated. I learn. I move on. Not the end of the world. And I've been humiliated more than a few times :) I'll give you credit for being considerate and generous in your atttitude.
    – Vietnhi Phuvan
    Feb 4 '15 at 12:56







  • 2




    You talked to your co-worker and he chose not to listen. Wash your hands of it, let him take the consequences of his actions. You've done what you could, that's it. Walk away from him and don't look back. Let him take care of himself. You've got other things to do.
    – Vietnhi Phuvan
    Feb 4 '15 at 13:04











  • Even if the code review is bad, it shouldn't be made to be humiliating. The purpose is a legitimate critique and exchange of knowledge. It's a terrible idea to have one code review, and then basically punish the employee because of it -- now you're taking away the employee's chance to respond to the critique, and you're giving them every reason to want to avoid code reviews.
    – Kai
    Feb 5 '15 at 18:05












up vote
0
down vote

favorite









up vote
0
down vote

favorite











I am a software engineer and one of my coworkers is going off the deep end - I can identify pattern obsession tendencies, misapplication of programming models (async-await for a list needed on the back-end), and other terrible implementations of relatively simple stuff that now makes it incredibly complicated.



Full disclosure: I was pulled off the project publicly earlier in the process after my boss did a code review (we don't really do code reviews, and I'll admit the code was not good because I was being lazy) and because he thought I wasn't 'getting it'. I was pissed and embarrassed by it, and when I watched the commits afterward I saw this coworker doing the exact thing that I did, only they weren't being watched and humiliated. This might be because this coworker has more experience than I do so my boss didn't check their commits. Both myself and 2 other developers (not the one who wrote it) have spoken about the code and the decisions being made and all are in agreement that it sucks.



I have now been put back on the project, and am dealing with the overhead of all the junk code. I don't want this responsibility, and it's hard to do really anything on it.



I've spoken directly to the coworker, voiced my concerns, and they've gone ahead and done it their way anyway. This is an office that very strictly follows TDD and SOLID principles, but this coworker is not doing any of it.



I don't want to shoulder the responsibility for maintenance on this project, but I don't want the other coworker to be humiliated like I was. What can I do?







share|improve this question














I am a software engineer and one of my coworkers is going off the deep end - I can identify pattern obsession tendencies, misapplication of programming models (async-await for a list needed on the back-end), and other terrible implementations of relatively simple stuff that now makes it incredibly complicated.



Full disclosure: I was pulled off the project publicly earlier in the process after my boss did a code review (we don't really do code reviews, and I'll admit the code was not good because I was being lazy) and because he thought I wasn't 'getting it'. I was pissed and embarrassed by it, and when I watched the commits afterward I saw this coworker doing the exact thing that I did, only they weren't being watched and humiliated. This might be because this coworker has more experience than I do so my boss didn't check their commits. Both myself and 2 other developers (not the one who wrote it) have spoken about the code and the decisions being made and all are in agreement that it sucks.



I have now been put back on the project, and am dealing with the overhead of all the junk code. I don't want this responsibility, and it's hard to do really anything on it.



I've spoken directly to the coworker, voiced my concerns, and they've gone ahead and done it their way anyway. This is an office that very strictly follows TDD and SOLID principles, but this coworker is not doing any of it.



I don't want to shoulder the responsibility for maintenance on this project, but I don't want the other coworker to be humiliated like I was. What can I do?









share|improve this question













share|improve this question




share|improve this question








edited Feb 4 '15 at 12:59

























asked Feb 4 '15 at 12:42









C Bauer

475212




475212




closed as off-topic by gnat, Garrison Neely, jcmeloni, Chris E, IDrinkandIKnowThings Feb 10 '15 at 4:40


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, Garrison Neely, jcmeloni, Chris E, IDrinkandIKnowThings
If this question can be reworded to fit the rules in the help center, please edit the question.




closed as off-topic by gnat, Garrison Neely, jcmeloni, Chris E, IDrinkandIKnowThings Feb 10 '15 at 4:40


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, Garrison Neely, jcmeloni, Chris E, IDrinkandIKnowThings
If this question can be reworded to fit the rules in the help center, please edit the question.







  • 3




    I think the core of the problem is that the code reviews are embarrassing/humiliating. If you can address that, then having some sort of "Is this what we want?" look at your coworker's output is a non-issue, plus it means that you don't get treated that way again either.
    – Hazel
    Feb 4 '15 at 12:50






  • 5




    "This is an office that very strictly follows TDD and SOLID principles, but they are not doing any of it." That's a contradiction right there. Either the office is following or it's not following. Rephrase your sentence.
    – Vietnhi Phuvan
    Feb 4 '15 at 12:51






  • 3




    OK, let him have his chance at spending quality time with the boss. Unless you want to make a career out of saving him from himself. You felt humiliated but it didn't kill you. I expect it won't kill him either. I get humiliated. I learn. I move on. Not the end of the world. And I've been humiliated more than a few times :) I'll give you credit for being considerate and generous in your atttitude.
    – Vietnhi Phuvan
    Feb 4 '15 at 12:56







  • 2




    You talked to your co-worker and he chose not to listen. Wash your hands of it, let him take the consequences of his actions. You've done what you could, that's it. Walk away from him and don't look back. Let him take care of himself. You've got other things to do.
    – Vietnhi Phuvan
    Feb 4 '15 at 13:04











  • Even if the code review is bad, it shouldn't be made to be humiliating. The purpose is a legitimate critique and exchange of knowledge. It's a terrible idea to have one code review, and then basically punish the employee because of it -- now you're taking away the employee's chance to respond to the critique, and you're giving them every reason to want to avoid code reviews.
    – Kai
    Feb 5 '15 at 18:05












  • 3




    I think the core of the problem is that the code reviews are embarrassing/humiliating. If you can address that, then having some sort of "Is this what we want?" look at your coworker's output is a non-issue, plus it means that you don't get treated that way again either.
    – Hazel
    Feb 4 '15 at 12:50






  • 5




    "This is an office that very strictly follows TDD and SOLID principles, but they are not doing any of it." That's a contradiction right there. Either the office is following or it's not following. Rephrase your sentence.
    – Vietnhi Phuvan
    Feb 4 '15 at 12:51






  • 3




    OK, let him have his chance at spending quality time with the boss. Unless you want to make a career out of saving him from himself. You felt humiliated but it didn't kill you. I expect it won't kill him either. I get humiliated. I learn. I move on. Not the end of the world. And I've been humiliated more than a few times :) I'll give you credit for being considerate and generous in your atttitude.
    – Vietnhi Phuvan
    Feb 4 '15 at 12:56







  • 2




    You talked to your co-worker and he chose not to listen. Wash your hands of it, let him take the consequences of his actions. You've done what you could, that's it. Walk away from him and don't look back. Let him take care of himself. You've got other things to do.
    – Vietnhi Phuvan
    Feb 4 '15 at 13:04











  • Even if the code review is bad, it shouldn't be made to be humiliating. The purpose is a legitimate critique and exchange of knowledge. It's a terrible idea to have one code review, and then basically punish the employee because of it -- now you're taking away the employee's chance to respond to the critique, and you're giving them every reason to want to avoid code reviews.
    – Kai
    Feb 5 '15 at 18:05







3




3




I think the core of the problem is that the code reviews are embarrassing/humiliating. If you can address that, then having some sort of "Is this what we want?" look at your coworker's output is a non-issue, plus it means that you don't get treated that way again either.
– Hazel
Feb 4 '15 at 12:50




I think the core of the problem is that the code reviews are embarrassing/humiliating. If you can address that, then having some sort of "Is this what we want?" look at your coworker's output is a non-issue, plus it means that you don't get treated that way again either.
– Hazel
Feb 4 '15 at 12:50




5




5




"This is an office that very strictly follows TDD and SOLID principles, but they are not doing any of it." That's a contradiction right there. Either the office is following or it's not following. Rephrase your sentence.
– Vietnhi Phuvan
Feb 4 '15 at 12:51




"This is an office that very strictly follows TDD and SOLID principles, but they are not doing any of it." That's a contradiction right there. Either the office is following or it's not following. Rephrase your sentence.
– Vietnhi Phuvan
Feb 4 '15 at 12:51




3




3




OK, let him have his chance at spending quality time with the boss. Unless you want to make a career out of saving him from himself. You felt humiliated but it didn't kill you. I expect it won't kill him either. I get humiliated. I learn. I move on. Not the end of the world. And I've been humiliated more than a few times :) I'll give you credit for being considerate and generous in your atttitude.
– Vietnhi Phuvan
Feb 4 '15 at 12:56





OK, let him have his chance at spending quality time with the boss. Unless you want to make a career out of saving him from himself. You felt humiliated but it didn't kill you. I expect it won't kill him either. I get humiliated. I learn. I move on. Not the end of the world. And I've been humiliated more than a few times :) I'll give you credit for being considerate and generous in your atttitude.
– Vietnhi Phuvan
Feb 4 '15 at 12:56





2




2




You talked to your co-worker and he chose not to listen. Wash your hands of it, let him take the consequences of his actions. You've done what you could, that's it. Walk away from him and don't look back. Let him take care of himself. You've got other things to do.
– Vietnhi Phuvan
Feb 4 '15 at 13:04





You talked to your co-worker and he chose not to listen. Wash your hands of it, let him take the consequences of his actions. You've done what you could, that's it. Walk away from him and don't look back. Let him take care of himself. You've got other things to do.
– Vietnhi Phuvan
Feb 4 '15 at 13:04













Even if the code review is bad, it shouldn't be made to be humiliating. The purpose is a legitimate critique and exchange of knowledge. It's a terrible idea to have one code review, and then basically punish the employee because of it -- now you're taking away the employee's chance to respond to the critique, and you're giving them every reason to want to avoid code reviews.
– Kai
Feb 5 '15 at 18:05




Even if the code review is bad, it shouldn't be made to be humiliating. The purpose is a legitimate critique and exchange of knowledge. It's a terrible idea to have one code review, and then basically punish the employee because of it -- now you're taking away the employee's chance to respond to the critique, and you're giving them every reason to want to avoid code reviews.
– Kai
Feb 5 '15 at 18:05










1 Answer
1






active

oldest

votes

















up vote
5
down vote



accepted










The core of your problem is that if you in particular speak up about the code, it looks like sour grapes because you were dinged once before.



However, one way to approach it is to go to your boss and talk about how the code review really helped open your eyes to what you were doing and that you think that it should become part of the process for everyone.



Talk about how that will ensure the TDD and SOLID principles will be followed and how you can catch errors before they become embedded in the system. Go research the benefits of code review and propose that it will save time in the long run by reducing bugs. It will also help people who will be maintaining the system understand the code that is being written, it will provide cross training, etc.



Now this is not just about you finding someone else to humiliate in turn but about improving everyone's code. Once there is code review, the mistakes this person is making will be obvious if they are as bad as you say.



Plus, code review really is a good thing to have in all programming environments. We review 100% of our code before going to QA and I wouldn't have it any other way. I have learned a lot, others have learned a lot and boy have we prevented a bunch of bugs.






share|improve this answer





























    1 Answer
    1






    active

    oldest

    votes








    1 Answer
    1






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes








    up vote
    5
    down vote



    accepted










    The core of your problem is that if you in particular speak up about the code, it looks like sour grapes because you were dinged once before.



    However, one way to approach it is to go to your boss and talk about how the code review really helped open your eyes to what you were doing and that you think that it should become part of the process for everyone.



    Talk about how that will ensure the TDD and SOLID principles will be followed and how you can catch errors before they become embedded in the system. Go research the benefits of code review and propose that it will save time in the long run by reducing bugs. It will also help people who will be maintaining the system understand the code that is being written, it will provide cross training, etc.



    Now this is not just about you finding someone else to humiliate in turn but about improving everyone's code. Once there is code review, the mistakes this person is making will be obvious if they are as bad as you say.



    Plus, code review really is a good thing to have in all programming environments. We review 100% of our code before going to QA and I wouldn't have it any other way. I have learned a lot, others have learned a lot and boy have we prevented a bunch of bugs.






    share|improve this answer


























      up vote
      5
      down vote



      accepted










      The core of your problem is that if you in particular speak up about the code, it looks like sour grapes because you were dinged once before.



      However, one way to approach it is to go to your boss and talk about how the code review really helped open your eyes to what you were doing and that you think that it should become part of the process for everyone.



      Talk about how that will ensure the TDD and SOLID principles will be followed and how you can catch errors before they become embedded in the system. Go research the benefits of code review and propose that it will save time in the long run by reducing bugs. It will also help people who will be maintaining the system understand the code that is being written, it will provide cross training, etc.



      Now this is not just about you finding someone else to humiliate in turn but about improving everyone's code. Once there is code review, the mistakes this person is making will be obvious if they are as bad as you say.



      Plus, code review really is a good thing to have in all programming environments. We review 100% of our code before going to QA and I wouldn't have it any other way. I have learned a lot, others have learned a lot and boy have we prevented a bunch of bugs.






      share|improve this answer
























        up vote
        5
        down vote



        accepted







        up vote
        5
        down vote



        accepted






        The core of your problem is that if you in particular speak up about the code, it looks like sour grapes because you were dinged once before.



        However, one way to approach it is to go to your boss and talk about how the code review really helped open your eyes to what you were doing and that you think that it should become part of the process for everyone.



        Talk about how that will ensure the TDD and SOLID principles will be followed and how you can catch errors before they become embedded in the system. Go research the benefits of code review and propose that it will save time in the long run by reducing bugs. It will also help people who will be maintaining the system understand the code that is being written, it will provide cross training, etc.



        Now this is not just about you finding someone else to humiliate in turn but about improving everyone's code. Once there is code review, the mistakes this person is making will be obvious if they are as bad as you say.



        Plus, code review really is a good thing to have in all programming environments. We review 100% of our code before going to QA and I wouldn't have it any other way. I have learned a lot, others have learned a lot and boy have we prevented a bunch of bugs.






        share|improve this answer














        The core of your problem is that if you in particular speak up about the code, it looks like sour grapes because you were dinged once before.



        However, one way to approach it is to go to your boss and talk about how the code review really helped open your eyes to what you were doing and that you think that it should become part of the process for everyone.



        Talk about how that will ensure the TDD and SOLID principles will be followed and how you can catch errors before they become embedded in the system. Go research the benefits of code review and propose that it will save time in the long run by reducing bugs. It will also help people who will be maintaining the system understand the code that is being written, it will provide cross training, etc.



        Now this is not just about you finding someone else to humiliate in turn but about improving everyone's code. Once there is code review, the mistakes this person is making will be obvious if they are as bad as you say.



        Plus, code review really is a good thing to have in all programming environments. We review 100% of our code before going to QA and I wouldn't have it any other way. I have learned a lot, others have learned a lot and boy have we prevented a bunch of bugs.







        share|improve this answer














        share|improve this answer



        share|improve this answer








        edited May 3 at 21:46









        RandomUs1r

        68129




        68129










        answered Feb 4 '15 at 14:46









        HLGEM

        133k25226489




        133k25226489












            Comments

            Popular posts from this blog

            Long meetings (6-7 hours a day): Being “babysat” by supervisor

            What does second last employer means? [closed]

            One-line joke