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.

It sounds like you are using Programmers to vent. Probably not a good idea. It also sounds like you are already convinced that you are right and he is wrong. Also not a good idea.
–
NickCFeb 22 '11 at 0:22

1

@Renesis, yes I'm also venting. It's par for the course... but truth to be told, I'm without ideas on how to deal with him, either I'm right or wrong.
–
TioFeb 22 '11 at 0:42

I can see how your question is different than the one you linked to, but would you mind editing this one to make it less of a vent and more focused on your actual question of how one resolves a conflict with a fellow developer (as opposed to from a managerial position)? Thanks.
–
Anna Lear♦Feb 22 '11 at 4:55

14 Answers
14

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.

@Renesis, I get it, it's just about selling my ideas to him, but I don't how I can sell for example the short tags argument, because it's in the PHP documentation, that we should use the full tag, instead of the short one.. it's right there on the documentation.. what can I say more? Btw, I wasn't the only one to raise my voice off course, who started it? I really don't remember...
–
TioFeb 22 '11 at 1:07

@Tio If you act nice, and it was his "fault", maybe he'll feel bad about it. If it was your "fault" then you just "apologized". Win-Win. Sort of. Nevermind, I suck at interacting with non-electronic beings.
–
Sicarius NoctisFeb 22 '11 at 1:32

9

@Tio That argument is an appeal to authority--which isn't really an acceptable argument. You would need to learn why PHP says not to use short tags and why that applies to your situation.
–
ProdigySimFeb 22 '11 at 1:45

1

This whole post is gold, and reinforces the idea that you need to put in his head also, not only in yours. Or else, you might end feeling bad with yourself for not doing it in the first place.
–
Coyote21Feb 22 '11 at 15:15

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.

@Morons, I don't think it's unfair, I think it's stupid, and he had a chance to defend himself on the spot.. because it was right in front of him.. besides, when I see code written by a programmer with 4/5 years of experience that generates a primary key for a table with a random number, should I stay silent? I don't think so.. but you make a good point.. no doubt about that..
–
TioFeb 22 '11 at 0:17

15

+1 An apology would be in order.
–
user1249Feb 22 '11 at 1:01

7

"... and he had a chance to defend himself on the spot". He shouldn't have had to defend himself! You were way out of line criticizing his code to your boss. "[The boss] asked about it, so I told him." You didn't have to do that. You shouldn't have done that. You could have just said "Oh ... its nothing" and changed the subject.
–
Stephen CFeb 22 '11 at 4:16

5

"... should I stay silent". In front of your boss? In this circumstance? Absolutely yes!
–
Stephen CFeb 22 '11 at 4:22

2

I don't think he deserves an apology - if the code was awful it was awful - that's it.
–
Jimmy CFeb 22 '11 at 10:39

there's probably a reason why a 'senior' developer was hired instead of this guy being promoted. probably more than one reason. Precisely. I also agree with ignoring him, up to a point.
–
George MarianFeb 22 '11 at 4:07

3

Unfortunately, I can't recommend the act of ignoring him. Ignoring someone whom you are not in complete terms with and have some face time with every day and that someone has the backing of the management may get you fired or let go in the long run (or after one heated argument too many). Only thing you can do is to apologize as early as possible (or find a new job).
–
SpoikeFeb 22 '11 at 8:07

1

If this guy is an 'asshole', ignore him. It looks like that if you don't ignore him you'll get an ulcer... Apply your team leading to people that want to learn and progress.
–
GuillaumeFeb 22 '11 at 9:06

1

@Steven... I think ignoring him, is really not the way to go, this way I'm just working alone, and I don' want that..
–
TioFeb 22 '11 at 9:08

1

@Tio: working alone is better than working with someone who seems to be uncooperative and resentful. Lead by example.
–
Steven A. LoweFeb 22 '11 at 15:36

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.

@jmquigley, I'm not trying to shove new ideas down people throats, I'm discussing this ideas first with everyone else, to see what they think about it..and trying to find the most diplomatic way about it.. but this guy keeps refusing everything I say.. and that's not the case, actually we have a freelancer working there that was interviewed at the same time for my position, I got the job, he didn't, and we get just along fine.. event today I spent about two hours working with him on his laptop, and everything went really well... thanks..
–
TioFeb 21 '11 at 23:45

yeah, that may have been a little too strong of wording on my part. The larger point was about getting your boss to push your ideas through the group after you get buy in from the boss.
–
jmqFeb 21 '11 at 23:50

@Tio: It sounds like you're discussing stuff, he's voicing objections, and then you're basically ignoring him and pressing forward with your ideas anyway. What objections does he have to these things your propose?
–
Anon.Feb 21 '11 at 23:55

@Anon, for the project management tool, he said that it would only serve as a means to control us even more, for the test server ( which is a pre-production server, to show the site to the client before going live ), he said that it was a waste of time, because he was fast uploading things to the server, instead of me, I don't need to upload anything, I just need to do a push and it's done, for this recent discussion he just said that I shouldn't teach him how to do things, and that he knows how to do it..
–
TioFeb 22 '11 at 0:06

@Tio: He does sound like he's being unreasonable, then. Regardless, you're not his direct senior, and as such it's really not your place to be pushing changes over his objections. This is somewhere where you need to be getting your boss involved, rather than trying to make huge waves yourself.
–
Anon.Feb 22 '11 at 0:13

good point, but I already tried to relate with him out of the office, and he always says no.. I asked him to go for a beer ( or whatever ) with me and others, with me alone and he always refuses..
–
TioFeb 22 '11 at 21:14

@Tio: What do you mean by "whatever"? Some people have very good reasons not to touch anything alcoholic, or even be around alcohol, and they don't necessarily want to discuss them. Alternately, you may have alienated him enough so he wants nothing to do with you. For this to work, you need to find some way to figure out why he always says "no".
–
David ThornleyMar 1 '11 at 18:43

@David Thornley With whatever I mean other occasions where everybody in the office gathered to have lunch together, or simply drink a coffee..
–
TioMar 12 '11 at 20:45

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.

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.

thanks for the insight on the other side.. the only thing I see wrong in there is "been trying to sic the boss on me".. that's the only thing I don't do..
–
TioMar 2 '11 at 9:30

@Tio: From your post: "Our boss is going to intervene in a few days. I talked to him today, and the other programmer sent him an email the day we had the discussion, complaining." Close enough, I think. I'm glad you're trying to understand what he's thinking, since that's the only way to resolve this situation satisfactorily (I don't consider making him quit and go away mad really satisfactory).
–
David ThornleyMar 2 '11 at 18:06

I agree completely, I don't want him to quit.. that would be awful... but I have to say, that if he doesn't want to move forward or learn new things and improve himself, where is he going? And where is he taking the company?
–
TioMar 12 '11 at 20:47

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.

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.

Like I always say and know too well, change is hard, I really don't think so ( but I've been wrong other times ), since I always start with, so what do you think about this? Then we talk about it, he blatantly refuses it, and then I present it to my boss, the only thing we agreed on was the source control bit.. what would you do when you arrive at a company, that doesn't even has a folder structure for projects defined, domains registered in the name of former employees ( programmers ), etc etc?
–
TioFeb 22 '11 at 0:37

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

I do not think that harrassing colleagues is a good idea. The best way is to show that this new thing X will make his life easier instead.
–
user1249Feb 22 '11 at 9:22

1

Yeah, and sometimes this never, ever works. Had 2 ppl who would object to anything at all put in front of them because they liked to argue. Best thing ever was when they eventually left. Some people don't ever like to listen to reason.
–
quickly_nowFeb 22 '11 at 10:18

@MainMa, "Everyone means you? You and your three coworkers? You and your one hundred colleagues?", me and 6 co-workers and two of my bosses..
–
TioFeb 22 '11 at 21:15

@Tio: Eight against one is a lot. It might be a sign that your lone coworker must improve his social skills and/or be more cooperative with others.
–
MainMaFeb 23 '11 at 15:00

@MainMa: It may also be a sign that the coworker is feeling insulted, belittled, and besieged, and is responding by being stubborn and unyielding. What I've heard out of the OP doesn't sound like fine social skills either. (Consider the story of the Wind and the Sun betting on who can get a cloak off a traveler - when the Wind blew, the traveler clutched his coat tighter, then the Sun came out and he removed it himself.)
–
David ThornleyMar 1 '11 at 18:38

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.

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

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 =).

That makes a lot of sense, but when I see something so wrong, I just can't help myself to be the wheel of change.. and I think you should tell them... honesty is the way to go..
–
TioFeb 22 '11 at 21:19

most junior programmers want to keep their jobs for sometime.. atleast 2 years b4 they start talking the truth
–
VigneshFeb 23 '11 at 4:45