How to solve conflicts with another programmer

Question

I've read this question, but I think it doesn't really applies in my case.

I have issues working with another developer in my company and I'm not sure how to fix them when there is no team lead to help mediate or buffer our relations.

Two months ago I was hired as a senior web developer. It's small company ( about 30 people ). The programming team is consisted by me and another programmer.

This programmer is in a junior role, although he does not report to me. Ever since my first day, we've been clashing in various points.

For example, he's refused to use a test server and a project management tool that I proposed to everybody and to which my boss agreed.

He has also refused to compromise during discussions of best practices and coding standards. He is convinced that his way is the only true way to do things and doesn't take my arguments into consideration.

He is even insisting that we are not a team and that I should just work on my projects and not bother him. He's also complaining about me to our boss.

I'm passionate about improving our work environment and workflows. I try not force my opinions on others and always ask everybody what they think about it. Every new idea that I bring to the table is discussed and generally everyone works together to come up with a good compromise, except him. He's always negative and rejecting my proposals outright.

I criticized his code shortly after starting at this company and that's a way to kill of a healthy relation.

How can I approach resolving our issues?

Answer 1

my position is above his

Be aware that he might not have this same feeling, having been at the company longer than you.

When I mentioned that we are a team, he told me: "We are not a team, you work on your projects and I work on mine".

Essentially you used the "we are a team" line to try to win the argument your way. His isn't the best retort, but at least to him is some sort of compromise to let you do your thing your way.

If you want to win the short tags and echo shortcut argument, you are going to need to have a good reason why not. It can be annoying for someone used to these shortcuts to have to look at code with the full shortcut-less style, or even difficult to change if code is not well organized. So, back it up.

Let's just say, that the switch in my brain flipped, I raised my voice, and I told him that he was going nuts. This was the most improper way to deal it with, I know, but there are certain things that can't be said to me.

At this point, you are probably going to need to apologize, or else this experience will color every future experience you have with him.

I want, to implement more changes on our work workflow, and I know that it's going to be a pain, with him always complaining and saying things like this.

"I want to continue to be productive, but I know it's going to be a pain with the new guy coming in and wanting to change everything without learning how things go here first" — your co-worker.

For example, when I was trying to implement the project management tool, I took the time to talk to everybody that was going to be involved in it, to see what they think about it. everyone was positive except him, he responded that it was just a mean to control us even more.

Implementing changes in a business is all about selling your idea. The reality could be either exactly as you describe it, or he may be the only one saying what everyone is thinking.

He showed up at the time I saw that piece of code, he saw my face and asked about it, so I told him. I know the worst thing that can be said to a programmer is saying that their code is awful, but I've already learned that my code isn't the best of the world, so I take criticism in a completely different way now. maybe he doesn't.

Ripping a band-aid off sometimes works, but in business it can also cause rifts that never heal. You really should have just fixed it or talked to him about it. Again, if you are proposing changes, you've got to sell them. By that I mean: You've got to persuade him to understand why it is important to change. Not just why it's "wrong" but also why it's worth the time.

---

P.S. Just wanted to add a link to an answer that I wholeheartedly agree with, that deals with a very similar problem to yours: Dealing with inflexible programmers.

Answer 2

So basically , on the 4th day on the job you bad mouthed him to his boss about a piece of code you know nothing about, without asking him about it and now he hates your guts and you think its unfair...

I think you need to apologize to him. If I was him, I would not want to be part on your "team" either.

Answer 3

taking everything at face value...

Fire him

oh wait, he doesn't work for you.

Train him

oh wait, you're not on the same team.

Convince him

oh wait, you said his baby was ugly on day 4. not good.

Ignore him

be happy and productive in your own world, since its clear that you're not his boss, not his mentor, not his teammate, and he's not interested.

there's probably a reason why a 'senior' developer was hired instead of this guy being promoted. probably more than one reason.

Answer 4

You can't shove new ideas down people's throats. It takes buy in from others or... you guessed it already, you have conflicts. You're not his boss, but I'm assuming you have the ear OF the boss. Bring your ideas up to the boss, get him/her to buy in and let the BOSS filter them down through the group and make it policy. If you were the boss you could do what you're doing, but you already admitted you are not. The other issue is that your "newer" ideas may be encroaching on his comfort zone. I'm ok with taking people out of their comfort zones to improve, but not everyone WANTS to do that (leading to conflicts).

JMHO

I am curious though, did your coworker apply for and get turned down for the same job you are currently doing? I have seen that conflict before too.

Answer 5

Go have a beer with him outside the office and talk with him for a few hours.

If you come back from that and you still feel like you have to shove things down his throat to get him to work with you, it's your fault.

Answer 6

Some bedtime reading to help you resolve the situation.

It worked wonders for my confrontations in my previous job.

Answer 7

My suggestion is try leading by example. Write your own projects in the way you like them (using short-tags or echos or whatever), and create a coding conventions wiki page, where you describe coding standards of you projects. It's pretty normal that one firm has many different conventions (one for c++, one for c#, one for collaboration projects, etc). But it's important that they are used consistently inside the same projects.

Of course one problem might be that the other developer writes ten times more code than you. Then changing his way of thinking might be difficult.

Answer 8

You got a problem? Just listen what happened to me.

A guy was hired for a position I had my eye on, and on his fourth day he really embarrassed me in front of the boss. I don't know what he's got against me.

Coming in from outside, he doesn't understand the situation, but thinks everything should be done his way. I tried to suggest that we could work separately in our own ways, since we really don't work on projects together, and he blew up at me and said I was nuts. Jerk.

Since then, he's been trying to sic the boss on me, and trying to implement systems that make things work his way. I've been getting the work done for a long time now, and he comes in and now I'm the incompetent bad guy. This sucks.

I've tried being reasonable, but it looks like if I give this guy an inch he'll take a mile.

Any ideas on how to handle this?

Answer 9

Some people are just set in their ways.

Things like issue tracking and test servers aren't optional, they are an absolute must for all but the smallest of startups.

If he's only objecting against reasonable stuff because he doesn't like you, that's fair enough but if he's really against changes because he wants to keep things as they are, you have to keep continuing to push things through and ignore him.

But I had run-ins with some of my colleagues and the lesson I learned was that either one of us was cherishing his own ignorance rather than strive to eliminate it or we were basically saying the same thing, only in a different way.

What you should try to convince him is that the changes will result in less drudgery and more productive work, And of course make sure that they really will.

Answer 10

I don't tell him what to do..

Since the day I started to work at the company, I managed to implement a kind of a test server which he refuses to use, implemented a project management tool which he refuses to use also, and I'm in the process of implementing version control using mercurial ( damn Mercurial that's giving me so much headaches ), which he is going to use..

If that last part isn't telling him what to do, I don't know what is. Are you prepared to leave this job if he doesn't? My guess is that you may not see how much change you are trying to impose upon him and what his views are on this change. While management may intervene, I'd suspect you may be inviting some passive-aggressive stuff with him that isn't healthy.

I'd suggest trying to have a private discussion with him and get more on his side of the story on some things here. In a way I see this as a bit of a chest-thumping exercise that isn't really productive though I may just be reading into things a bit here. Are you wanting to seem like the judge of good code that doesn't make mistakes? That is how you seem in this story as you are bringing in a few practices relatively quickly that may or may not have been why you were hired.

---

Within my own stuff I may organize things and suggest it to others to see if it would be accepted or not. Pushing something on someone may work and it may backfire. The latter is more likely with things that may take a while before a dividend is seen I'd think as there is a part of faith and trust there. I know that I don't like to impose responsibility onto others & don't want to be forceful but that's my style & choice. I'd likely spend a few months getting to know how things are done, what kind of formalities are in place or not, what structure is there, who is playing what role, etc. While some things have to be absorbed quickly to get some work done and show some signs of productivity, there are some dynamics that may take a while for me to notice a pattern or habit of others along with seeing what kind of rhythm does a place have. Is everyone a cowboy that just does their own thing? Are there common practices where most people get together for lunch or the odd dinner after a sprint?

I can admire the ideal of wanting best practices and coding standards though I'm pretty sure I wouldn't expect that of my workplace. There is an aspect of getting things done which can mean things aren't always going to be perfect and that there is a good enough standard around most of the time that has been my experience. Things can change and sometimes new practices will be better though sometimes an experiment will show why some practices may not work so well in my situation.

Answer 11

everyone was positive except him, he responded that it was just a mean to control us even more

Everyone means you? You and your three coworkers? You and your one hundred colleagues?

If it's just between you and him, I don't think you can do too much. You can talk with him in front of your boss to convince to change the workflow and to do things your way, but then, if the boss takes his side, there will be no other options.

If it's between the every coworker on one side, and him on the other side, it will be easier to convince the boss that there is something wrong with this person, and that it's difficult to work with a person like that.

In all cases, be very careful when dealing with starting flame wars IRL. On some subjects, other developers will never agree with you¹, and discussing those subjects will bring nothing except confrontation.

But there are also subjects which can be discussed in order to make a business decision. For example, when you talk about coding standards, it is to the boss to decide if some standards must be implemented in your company codebase. If she/he decides that coding standards may make code more readable and easy to maintain, it would be more or less easy to enforce. For example, coding standards may be enforced automatically before committing changes.

Finally, for a few things, if you're really convinced you're right and your coworker is wrong, you can try to make his live difficult. For example, recently I had a bad experience with a coworker who refused to use a version control. Being required to work on the same project with this person, I started to send him the diff of the files before and after commit, letting him to apply those changes to his source files he kept locally on his machine. For me, producing a diff was easy. For him, applying a diff to the files he changed himself just before was much more difficult.

^{¹ You can recognize those subjects by two factors. First, there is no consensus between developers on the subject (for example nobody agrees if UML must be used in every large project, or if it's just a waste of time, whereas most developers agree that coding standards must be enforced in large codebases). Second (optional), some subjects don't make any sense (for example the assertion "ASP.NET is better than PHP" is a nonsense: in some circumstances ASP.NET will be better; in others, it will be better to use PHP).}

Answer 12

TL;DR (it all)

If he truly is a different position than yours, then think that his mandate might be different. In fact his salary might be quite different too and therefore his willingness to do some of the stuff he does not like.

Maybe he rightly thinks that others should be in charge of whatever you are trying to get him to do.

Just a few pointers to what might be happening (very hypothetically).

Not sure this helps, but if it does then great.

Answer 13

If you want this relationship to improve, you are going to have do all the work. It's clear that he's not going to be moved by technical arguments. I expect he is somewhat anxious. If you can alleviate his anxiety, he will be much more agreeable.

So you need to figure out what he wants from the job, besides money, and then try to give him as much of it as you can. Maybe it's some respect, maybe it's just less hassle, maybe it's just some kind words. He probably knows he's not the greatest programmer, and he probably needs this job a lot worse than you do. Maybe he's been there for a while, getting a little bit comfortable, but still worried that if he were let go he might not have an easy time getting another position. Then you show up and in the first week you suggest rather bluntly that he's not quite up to it. Even if his code is terrible, you should apologize, and make it sound sincere.

I had to go read about PHP short tags and the echo shortcut. Are you planning to distribute your application to an environment where short tags aren't supported? Anyway, wouldn't it be easy enough to automatically convert them if necessary? If the answers are no and yes, I wouldn't worry about it.

The next time you change positions, resolve not to criticize ANYTHING for at least a month, and never criticize another person's work until you know the person. Probably, when you spend all day writing 200 lines of code, and someone points that a couple of library calls would have done the same, you just smack your head and say "Duuuuh! Thanks!"

NOT EVERYONE THINKS LIKE YOU DO.

Answer 14

first of all. In any company, Its good to have freedom to use whatever tools someone wants as long as work gets done. Second off, the code went through reviews with the person who was holding your position before, I guess, if something got checked in then the reviewers are also to fault. So, the junior programmer had caught you on the wrong foot. I would suggest to give him a free hand and don't try to push too hard.

BTW the whole team thing sucks to people who do actual work (Trying to put the button in the right place for the looks that product manager wants), rather than for people who can develop fancy tools and get reputation that's useful only for appraisals more often than not.

I see a lot of my seniors trying to push as hard as you. I just don't tell it to there face, but within my mind, I would always want them to die in a motorbike accident =).