5 ms·

Ask HN: Advice for dealing with a difficult co-worker

16 points by justanengineer 12y ago

I'll try to keep this short. Essentially, I work at a startup and work very closely with another engineer of comparable experience as me. He's been at the company since it was started (2 years) while I joined 6 months ago. We've been having some conflicts. From my perspective, the issue is that he doesn't see any difference between his opinion and fact. He frequently makes changes to shared code that affects things I'm working on without checking with me. In fact, recently, he's taken to deleting entire modules of my code that he feels are poorly designed and replacing them with new versions, which often have changed APIs and require work on my part to correct. When I ask him why he would do this without even consulting me, his response is to argue - in his mind, his version is "right," so why should he need to talk to me about it? At first I tried to ignore this and keep working. When it continued to affect my work, I tried to discuss it with him, using "I" statements and explaining how his behavior impacted me. Finally, I escalated to our supervisor, the director of engineering. He asks for examples and tries to help us compromise on specific issues. My problem is not any one of these issues but the general trend of disrespect. I suggested I be reassigned to other projects but this is not possible. Basically, I love this company but these interactions are really impacting me. Sometimes when this happens I become very angry and have a difficult time thinking clearly or working productive. I don't think I can really change the situation, and I really don't want to quit. TL;DR: I guess what I'm hoping for is some advice on how to be more zen about this situation - how to keep working productively in spite of interpersonal conflicts, how to proactively prevent disagreements from happening, and how to deal with them more effectively when they arise.

itbeho 12y ago
Life's too short to be miserable at work. I'd chalk it up as a learning experience and move on. Lots of opportunity out there, and you'll probably land somewhere that you can either learn or teach things that you'll never be able to in your current gig.
- justanengineer 12y ago
  Thanks for the advice. I guess I just don't want to think about quitting. First, I really do enjoy my work except for these conflicts, for example when he's working on something separate from me. Second, I worry about quitting so soon because I was at my previous job for only two years and this one for six months. I don't want to be seen as a "job hopper."
  - devb0x 12y ago
    back your self up with well written code, committed into a VCS with proper comments. For each one that is rewritten mark those commits somewhere in a list of notes. Discuss each one with him if his check in comment is not clear as to why. When he's right, leave it, when he's being a jerk note it. If all else fails you have documented your reasons. Then go and find a new gig cuz you've done all you can.
vladmk 12y ago
I'll give you three responses (a new method of mine to leave you the decision) a) Just get over it, what doesn't kill you makes you stronger, keep coding and keep letting him delete your stuff. Eventually you should learn what he'll delete. b)If you're not happy 100% happy what you're doing for a few days in a row reconsider your options and change altogether aka quit. - Steve Jobs commencement speech philosophy. c)Keep going to your supervisor and work your way up the ladder.
sergiotapia 12y ago
Talk to your supervisor in dollars and cents. His shitty attitude is costing the business time and money because you're forced to rewrite existing code whenever he feels like rewriting a module. Personally though, I would quit and find somewhere else to work only because your supervisor doesn't care about your problem. It's not like there's a shortage for software devs.
frankydp 12y ago
I would think that the only way to overcome a disregard issue would be to somehow increase your personal relationship. If he is acting from a position of "factual" strength then the only way to change his behavior would be to introduce emotion into the thought process. These type of coworkers can be exceedingly difficult if not impossible. The above is only speculation, and has never actually worked for me in a total resolution, but it has made it slightly better overall. TLDR Heartstring attack.
tomcam 12y ago
No disrespect meant; I don't know either one of you. But is it possible your work is in fact subpar? This has happened to me (I was the one who needed to improve). I urge you to look at your work in that light and see things from your coworker's perspective.
- wmf 12y ago
  If one of my coworkers was doing subpar work I'd still discuss it with them before rewriting it.
- danieltillett 12y ago
  Even if the work is subpar this is no reason to not speak to the poster. This issue is really one of respect. While we are going down the path of wild speculation in the absence of any evidence, I have found these types of "dissings" are a reflection of the dissee being more competent than the disser.
- greenyoda 12y ago
  "But is it possible your work is in fact subpar?" That might be the case, but throwing out large pieces of somebody else's code without talking to them about it is not a civilized way to behave. If I saw a problem with somebody's code, I'd try to patiently explain to them what the problem was, and how it could be done better. If they ignored me, I'd make my case to our manager in a rational way and let them decide who was right. If the manager thinks that just throwing out somebody's code is acceptable behavior, I'd agree with the people who advised looking for a job elsewhere.
- justanengineer 12y ago
  This is fair enough. I feel that like everyone I do make mistakes and I try to own them. I've agreed somewhat with some of the changes he's made, just not the way he's doing it unannounced and without input from anyone else.
- noodle 12y ago
  If his code is sub-par, the professional response would be to make comments on his commits and/or otherwise try to provide guidance/mentorship. Not completely strip out his code behind his back and replace it. The problem here actually sounds like this coworker is used to working alone and doesn't know how to work on a team.
deleted 12y ago
[deleted]
dennybritz 12y ago
This may not be what you want to hear, but if your supervisor is unresponsive to your complaints then you may be best off switching jobs. Assuming it's even possible, changing your colleague's behavior would probably take a very long time. Being miserable at work drags you down emotionally and will affect your whole life, so I recommend getting out of there.
Jupe 12y ago
Change it back?
akg_67 12y ago
>How to be more zen about this situation Worry about the things that you can control and ignore the things that you can't control. The things you can't control is how your coworker and supervisor will behave. Can you control their behavior? If not, then why worry about it and get stressed about it. You can't change people. Your coworker has been there from the start, so he has the rapport and line of communication you don't and most probably will never unless your coworker falters or you move into a different group/project where you can shine on your own. You will likely lose a head-on battle. The things you can control is your reaction to your coworker and supervisor behavior, working on this job, working for this company, etc. So decide, how do you want to react? Complain, whine, hope for the best or quit. If you want to stay at the company, why not make friends with this coworker? Improve your personal relationship with him. You might then be able to influence his behavior. Arguing, complaining, escalating wouldn't take you far except out the door.
jlees 12y ago
Do you have a code review process? Could you initiate one?
jaimehamby 12y ago
Dealing with difficult people is easier when the person is just generally obnoxious or when the behavior affects more than one person. http://www.essayscouncil.com/professional_help.php http://www.essayscouncil.com/professional_help.php
jasonkester 12y ago
Isn't there a build that's breaking somewhere because of this? It sounds like you're describing symptoms of a shop that's not set up quite right. You say you've got a guy making breaking changes to shared code, and not fixing up the references. That's something that should rapidly self-report in the form of a broken build. The dev in question will get the big flashing "cone of shame" left on his desk, be assigned the task of "build master" for a while, and have his commit rolled back. This sort of thing runs automatically (apart from cone delivery) at most shops. You also seem to have a bit of a "code ownership" thing going on at your workplace, since you mentioned "your code" and "his code" a few times. Gotta get rid of that. Let your buddy change whatever he likes. No skin off your nose, so long as he fixes up the references. It sounds like there must be some silly policy in place that's either not letting him do that or not requiring him to. Gotta fix that too. Naturally, these are technical fixes that don't address the underlying social problem. Fortunately, that's the only kind of fix that an Aspergers Sociopath developer of the type you describe will respond to. Make the rules say that he shouldn't be such a dick, and he'll adjust his algorithm to at least stop being that particular flavor of dick. Good luck!
- britknight 12y ago
  Seconded. If your commits consistently fix things while his consistently break them, that will be noticed. Just focus on doing your work as best you can and try not to let this guy get to you.
IlPeach 12y ago
on top of what akg_67 said (Worry about the things that you can control and ignore the things that you can't control.) I need to add that your story seems to implicate you do not have a way to measure the efforts put into your code, quality assurance is one you can use and it's quite well known. In the teams I've been part of and managed, egos always tend to come into play when writing code: I got better ideas, I got better line indenting, blah blah... been there, done that. I think it's mostly important to focus on the outcome: practically speaking the way I would tackle this is by introducing some level of QA, either by introducing TDD or else. You start by writing tests as use case scenarios, and then implement the code. Once this is done, if any of your colleagues wants to re-implement the code/module/whatever, let them do it, but the tests need to pass and the improvement should be measurable. Otherwise who f*ing cares? Peace!
brudgers 12y ago
The flawed premise is experience. To a headhunter, two resumes may look comparable, yet for the problem at hand one person is objectively more experienced than the other.
RogerL 12y ago
Can you put this in terms of dollars and cents? If the two pieces of code are largely equivalent, then your co-worker is wasting a lot of the company's money. If his truly are much better (in a way that matters to the execution of the company's goals), well, then maybe you need to step it up somehow. I'm not sure why your director is not addressing this, but nothing stops you from doing the analysis and presenting the argument.
bjourne 12y ago
Maybe he doesn't see him replacing "your" code with better code as a hostile action? I'd try to swallow my pride and see if this guy can teach me something about coding. At an old work I had a colleague doing it to me, and maybe because I believe myself to be an amazing coder it was more amusing than threatening. It led to me having lots of time browsing hacker news and working on my own projects while he had to work weekends and many late nights because he took on to much responsibility and wanted to control everything.

itbeho 12y ago

Life's too short to be miserable at work. I'd chalk it up as a learning experience and move on. Lots of opportunity out there, and you'll probably land somewhere that you can either learn or teach things that you'll never be able to in your current gig.

justanengineer 12y ago
Thanks for the advice. I guess I just don't want to think about quitting. First, I really do enjoy my work except for these conflicts, for example when he's working on something separate from me. Second, I worry about quitting so soon because I was at my previous job for only two years and this one for six months. I don't want to be seen as a "job hopper."
- devb0x 12y ago
  back your self up with well written code, committed into a VCS with proper comments. For each one that is rewritten mark those commits somewhere in a list of notes. Discuss each one with him if his check in comment is not clear as to why. When he's right, leave it, when he's being a jerk note it. If all else fails you have documented your reasons. Then go and find a new gig cuz you've done all you can.

vladmk 12y ago

I'll give you three responses (a new method of mine to leave you the decision) a) Just get over it, what doesn't kill you makes you stronger, keep coding and keep letting him delete your stuff. Eventually you should learn what he'll delete. b)If you're not happy 100% happy what you're doing for a few days in a row reconsider your options and change altogether aka quit. - Steve Jobs commencement speech philosophy. c)Keep going to your supervisor and work your way up the ladder.

sergiotapia 12y ago

Talk to your supervisor in dollars and cents. His shitty attitude is costing the business time and money because you're forced to rewrite existing code whenever he feels like rewriting a module. Personally though, I would quit and find somewhere else to work only because your supervisor doesn't care about your problem. It's not like there's a shortage for software devs.

frankydp 12y ago

I would think that the only way to overcome a disregard issue would be to somehow increase your personal relationship. If he is acting from a position of "factual" strength then the only way to change his behavior would be to introduce emotion into the thought process. These type of coworkers can be exceedingly difficult if not impossible. The above is only speculation, and has never actually worked for me in a total resolution, but it has made it slightly better overall. TLDR Heartstring attack.

tomcam 12y ago

No disrespect meant; I don't know either one of you. But is it possible your work is in fact subpar? This has happened to me (I was the one who needed to improve). I urge you to look at your work in that light and see things from your coworker's perspective.

wmf 12y ago
If one of my coworkers was doing subpar work I'd still discuss it with them before rewriting it.
danieltillett 12y ago
Even if the work is subpar this is no reason to not speak to the poster. This issue is really one of respect. While we are going down the path of wild speculation in the absence of any evidence, I have found these types of "dissings" are a reflection of the dissee being more competent than the disser.
greenyoda 12y ago
"But is it possible your work is in fact subpar?" That might be the case, but throwing out large pieces of somebody else's code without talking to them about it is not a civilized way to behave. If I saw a problem with somebody's code, I'd try to patiently explain to them what the problem was, and how it could be done better. If they ignored me, I'd make my case to our manager in a rational way and let them decide who was right. If the manager thinks that just throwing out somebody's code is acceptable behavior, I'd agree with the people who advised looking for a job elsewhere.
justanengineer 12y ago
This is fair enough. I feel that like everyone I do make mistakes and I try to own them. I've agreed somewhat with some of the changes he's made, just not the way he's doing it unannounced and without input from anyone else.
noodle 12y ago
If his code is sub-par, the professional response would be to make comments on his commits and/or otherwise try to provide guidance/mentorship. Not completely strip out his code behind his back and replace it. The problem here actually sounds like this coworker is used to working alone and doesn't know how to work on a team.

deleted 12y ago

[deleted]

dennybritz 12y ago

This may not be what you want to hear, but if your supervisor is unresponsive to your complaints then you may be best off switching jobs. Assuming it's even possible, changing your colleague's behavior would probably take a very long time. Being miserable at work drags you down emotionally and will affect your whole life, so I recommend getting out of there.

Jupe 12y ago

Change it back?

akg_67 12y ago

>How to be more zen about this situation Worry about the things that you can control and ignore the things that you can't control. The things you can't control is how your coworker and supervisor will behave. Can you control their behavior? If not, then why worry about it and get stressed about it. You can't change people. Your coworker has been there from the start, so he has the rapport and line of communication you don't and most probably will never unless your coworker falters or you move into a different group/project where you can shine on your own. You will likely lose a head-on battle. The things you can control is your reaction to your coworker and supervisor behavior, working on this job, working for this company, etc. So decide, how do you want to react? Complain, whine, hope for the best or quit. If you want to stay at the company, why not make friends with this coworker? Improve your personal relationship with him. You might then be able to influence his behavior. Arguing, complaining, escalating wouldn't take you far except out the door.

jlees 12y ago

Do you have a code review process? Could you initiate one?

jaimehamby 12y ago

Dealing with difficult people is easier when the person is just generally obnoxious or when the behavior affects more than one person. http://www.essayscouncil.com/professional_help.php http://www.essayscouncil.com/professional_help.php

jasonkester 12y ago

Isn't there a build that's breaking somewhere because of this? It sounds like you're describing symptoms of a shop that's not set up quite right. You say you've got a guy making breaking changes to shared code, and not fixing up the references. That's something that should rapidly self-report in the form of a broken build. The dev in question will get the big flashing "cone of shame" left on his desk, be assigned the task of "build master" for a while, and have his commit rolled back. This sort of thing runs automatically (apart from cone delivery) at most shops. You also seem to have a bit of a "code ownership" thing going on at your workplace, since you mentioned "your code" and "his code" a few times. Gotta get rid of that. Let your buddy change whatever he likes. No skin off your nose, so long as he fixes up the references. It sounds like there must be some silly policy in place that's either not letting him do that or not requiring him to. Gotta fix that too. Naturally, these are technical fixes that don't address the underlying social problem. Fortunately, that's the only kind of fix that an Aspergers Sociopath developer of the type you describe will respond to. Make the rules say that he shouldn't be such a dick, and he'll adjust his algorithm to at least stop being that particular flavor of dick. Good luck!

britknight 12y ago
Seconded. If your commits consistently fix things while his consistently break them, that will be noticed. Just focus on doing your work as best you can and try not to let this guy get to you.

IlPeach 12y ago

on top of what akg_67 said (Worry about the things that you can control and ignore the things that you can't control.) I need to add that your story seems to implicate you do not have a way to measure the efforts put into your code, quality assurance is one you can use and it's quite well known. In the teams I've been part of and managed, egos always tend to come into play when writing code: I got better ideas, I got better line indenting, blah blah... been there, done that. I think it's mostly important to focus on the outcome: practically speaking the way I would tackle this is by introducing some level of QA, either by introducing TDD or else. You start by writing tests as use case scenarios, and then implement the code. Once this is done, if any of your colleagues wants to re-implement the code/module/whatever, let them do it, but the tests need to pass and the improvement should be measurable. Otherwise who f*ing cares? Peace!

brudgers 12y ago

The flawed premise is experience. To a headhunter, two resumes may look comparable, yet for the problem at hand one person is objectively more experienced than the other.

RogerL 12y ago

Can you put this in terms of dollars and cents? If the two pieces of code are largely equivalent, then your co-worker is wasting a lot of the company's money. If his truly are much better (in a way that matters to the execution of the company's goals), well, then maybe you need to step it up somehow. I'm not sure why your director is not addressing this, but nothing stops you from doing the analysis and presenting the argument.

bjourne 12y ago

Maybe he doesn't see him replacing "your" code with better code as a hostile action? I'd try to swallow my pride and see if this guy can teach me something about coding. At an old work I had a colleague doing it to me, and maybe because I believe myself to be an amazing coder it was more amusing than threatening. It led to me having lots of time browsing hacker news and working on my own projects while he had to work weekends and many late nights because he took on to much responsibility and wanted to control everything.