
Ask HN: Advice for dealing with a difficult co-worker - justanengineer
I&#x27;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&#x27;s been at the company since it was started (2 years) while I joined 6 months ago. We&#x27;ve been having some conflicts. From my perspective, the issue is that he doesn&#x27;t see any difference between his opinion and fact. He frequently makes changes to shared code that affects things I&#x27;m working on without checking with me. In fact, recently, he&#x27;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 &quot;right,&quot; so why should he need to talk to me about it?<p>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 &quot;I&quot; 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.<p>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&#x27;t think I can really change the situation, and I really don&#x27;t want to quit.<p>TL;DR: I guess what I&#x27;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.
======
akg_67
>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.

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

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

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

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

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

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

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

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

------
IlPeach
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!

------
jaimehamby
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)

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

~~~
greenyoda
_" 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.

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

------
jlees
Do you have a code review process?

Could you initiate one?

------
Jupe
Change it back?

