5 ms·

I went through this phase with a difficult coworker over code, would take code reviews personally, developed long running branches in an ivory tower with no inp

by dalore 8y ago

I went through this phase with a difficult coworker over code, would take code reviews personally, developed long running branches in an ivory tower with no input or discussion. Learned to let go and he has his parts of the code base and I have mine. Not ideal, but worked as we were a 2 man dev team at the time. Then he left and we grew the team. Now we got a few minefields left in the code base that anytime we need to add a feature or work in the area we have issues due to technical debt. What could one have done instead? Anyways the situation is a lot better, the new team all mesh well and discuss issues without taking it personally. Take away (probably obvious) is that good communication amongst team members is vital.

taneq 8y ago
> What could one have done instead? Got rid of the co-worker much earlier on, by the sounds of it.
- mikekchar 8y ago
  This is half of the right answer. The part where the OP's story breaks down is "he has his parts of the code base and I have mine". "Letting go" is different than "giving up". "Letting go" means realising that a single decision is not going to destroy the world (unless it is -- then don't let go ;-)). "Giving up" means never trying to find consensus on the rest of the issues. If you can't find a way to work together so that your code is sensible, then one of you should leave -- as quickly as possible. Over a long period of time, if you shut down your communication channels, then you will grow even further apart. This is what leads to the problem. Some people are inflexible. They have a need to have things their own way. They panic if the code is not how they would like it. Don't be that person and don't accept anyone else on the team like that either. Be compassionate and help the person improve, but don't enable their poor behaviour. You're the one who will ultimately pay. But you can't help everyone. And sometimes you can't leave. That's life. Not every situation is fixable.
majormajor 8y ago
There's a lot in here that might boil down to how you asked the questions/gave the feedback, but there are also certainly cases where you just aren't getting through to someone. Something I often do there is sanity check my approach with my manager and some trusted coworkers. Did you talk to anyone else about where the two of your coworkers communication was breaking down? Sometimes others have additional perspective on why you aren't getting through to someone since they have a different vantage point. I've also had cases where my manager basically tells me "no, I don't think you're doing anything wrong, let me do some investigation myself" - and if other people have had the same experience as me, that's occasionally led to positive organizational changes such as shifting people around onto different projects where their skills fit better.
BSVino 8y ago
Hello there, author of the article here. You bring up a great point: This is a case in which the stakes are high and some things I said in the article don't apply. In this case I would suggest that there should have been a lead or senior overseeing your coworker who was responsible for the quality of their code. This person should have already demonstrated good judgment in code quality, should have some people skill and backbone in dealing with folks who take code reviews personally and have the authority of the team to make the final decision on whether code gets integrated into your mainline branch. If you're not that person then there's not much that you can do about a coworker's bad code other than push the team towards a stronger structure and process to protect it from bad code.

by dalore 8y ago

taneq 8y ago

> What could one have done instead? Got rid of the co-worker much earlier on, by the sounds of it.

mikekchar 8y ago
This is half of the right answer. The part where the OP's story breaks down is "he has his parts of the code base and I have mine". "Letting go" is different than "giving up". "Letting go" means realising that a single decision is not going to destroy the world (unless it is -- then don't let go ;-)). "Giving up" means never trying to find consensus on the rest of the issues. If you can't find a way to work together so that your code is sensible, then one of you should leave -- as quickly as possible. Over a long period of time, if you shut down your communication channels, then you will grow even further apart. This is what leads to the problem. Some people are inflexible. They have a need to have things their own way. They panic if the code is not how they would like it. Don't be that person and don't accept anyone else on the team like that either. Be compassionate and help the person improve, but don't enable their poor behaviour. You're the one who will ultimately pay. But you can't help everyone. And sometimes you can't leave. That's life. Not every situation is fixable.

majormajor 8y ago

There's a lot in here that might boil down to how you asked the questions/gave the feedback, but there are also certainly cases where you just aren't getting through to someone. Something I often do there is sanity check my approach with my manager and some trusted coworkers. Did you talk to anyone else about where the two of your coworkers communication was breaking down? Sometimes others have additional perspective on why you aren't getting through to someone since they have a different vantage point. I've also had cases where my manager basically tells me "no, I don't think you're doing anything wrong, let me do some investigation myself" - and if other people have had the same experience as me, that's occasionally led to positive organizational changes such as shifting people around onto different projects where their skills fit better.

BSVino 8y ago

Hello there, author of the article here. You bring up a great point: This is a case in which the stakes are high and some things I said in the article don't apply. In this case I would suggest that there should have been a lead or senior overseeing your coworker who was responsible for the quality of their code. This person should have already demonstrated good judgment in code quality, should have some people skill and backbone in dealing with folks who take code reviews personally and have the authority of the team to make the final decision on whether code gets integrated into your mainline branch. If you're not that person then there's not much that you can do about a coworker's bad code other than push the team towards a stronger structure and process to protect it from bad code.