Mixing
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]
Clash 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?
software-industry colleagues
asked Feb 4 '15 at 12:42
C Bauer
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
 |Â
show 3 more comments
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?
software-industry colleagues
asked Feb 4 '15 at 12:42
C Bauer
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
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
 |Â
show 3 more comments
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?
software-industry colleagues
asked Feb 4 '15 at 12:42
C Bauer
475212
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?
software-industry colleagues
asked Feb 4 '15 at 12:42
C Bauer
475212
edited Feb 4 '15 at 12:59
asked Feb 4 '15 at 12:42
C Bauer
475212
asked Feb 4 '15 at 12:42
C Bauer
475212
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
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
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
 |Â
show 3 more comments
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
 |Â
show 3 more comments
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.
edited May 3 at 21:46
RandomUs1r
68129
answered Feb 4 '15 at 14:46
HLGEM
133k25226489
suggest improvements |Â
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.
edited May 3 at 21:46
RandomUs1r
68129
answered Feb 4 '15 at 14:46
HLGEM
133k25226489
suggest improvements |Â
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.
edited May 3 at 21:46
RandomUs1r
68129
answered Feb 4 '15 at 14:46
HLGEM
133k25226489
suggest improvements |Â
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.
edited May 3 at 21:46
RandomUs1r
68129
answered Feb 4 '15 at 14:46
HLGEM
133k25226489
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.
edited May 3 at 21:46
RandomUs1r
68129
answered Feb 4 '15 at 14:46
HLGEM
133k25226489
edited May 3 at 21:46
RandomUs1r
68129
edited May 3 at 21:46
RandomUs1r
68129
edited May 3 at 21:46
RandomUs1r
68129
68129
answered Feb 4 '15 at 14:46
HLGEM
133k25226489
answered Feb 4 '15 at 14:46
HLGEM
133k25226489
answered Feb 4 '15 at 14:46
HLGEM
133k25226489
133k25226489
suggest improvements |Â
suggest improvements |Â
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