My coworker (who is very clever, but with severly limited inter-personal skills), keeps refactoring my code even when it is work in progress and assigned to me as a task. Whereas I fully subscribed to the idea of collective ownership of code, I find this extremely irritating, but attempts to have him stop seem to have no effect. My analysis of his personality is that he considers himself the best, and if it had not been for him, the codebase would have been in a mess. I should add that I am not a novice, I know my skills and I produce quality work. Some of the refactorings are indeed to the better, most are basically just introduction of a style that he likes better than mine.
In addition, he has a almost child-like need to have the last word in any discussion and has never any word of praise for work done by co-workers. There is always something that he, the master, would have done differently. I feel this is strongly affecting the quality of my work-life. What should I do ?

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.
If this question can be reworded to fit the rules in the help center, please edit the question.

1

Is he your senior (employee, not age-wise), or is this a supposed 'level' playing field?
–
invertFeb 4 '11 at 13:18

2

We are a startup with little formalities, but I consider this a level field, but I do not think he does.
–
ThuneGrillFeb 4 '11 at 13:25

11 Answers
11

It doesn't sound that bad to me. When I saw this post title, "How to handle coworker with 'obsessive refactoring disorder'", I was afraid it was going to be one of my coworkers posting about me! You have a consistent code base. You admit that many of the changes are improvements. I think your best course of action is to let it go.

I feel this is strongly affecting the quality of my work-life.

This statement concerns me. I know this easier said than done, but don't let something like this affect your happiness. The answers that suggest you should find another job are too extreme -- there will always be personality differences in any programming shop. So this guy has poor social skills -- you'll find programmers like that everywhere. My advice would be to play to his strengths. Ask him to write up some coding standards and a style guide. Debate them among the team, and then try to get everyone to adhere to them.

I don't think you should let anyone do as they please with the code base. That's why we work as a team, to make quality software; you can't just let someone assume they are always right and their changes are always good, because they will end up making mistakes. Also, social skills can and should be learned, and "you'll find programmers like that everywhere" is not an excuse for behaving like a child.
–
NiphraFeb 4 '11 at 14:25

2

Sorry @Marcie, but this is just wrong advice. People will step over you as much as you let them, so sooner or later, if your bosses are not setting limits, you will have to. Otherwise OP will have this douchebag changing his code, while OP remains responsible for its correct function. If anything, rather than putting up with programmers because that's how they are, I'd say learn to pick your fights, fight the ones worth fighting, and read a book or two on how to handle problem children because that's what you have to do in programming shops more often than not.
–
Gabriel MaganaFeb 7 '11 at 14:56

2

How is this the accepted answer? "It's not that bad." The guy is exhibiting child-like behavior! It's unacceptable and needs to be addressed, not ignored.
–
Mark CanlasFeb 18 '11 at 21:59

+1 for phrasing it "re-factoring should be a collaborative process". If he sees it as an opportunity to show off knowledge, then you're likely to get more traction. From there, I'd try to build a rapport so you can come to a shared understanding of work style boundaries. This may fail (and often does with this sort of personality) but at least you tried to improve the situation before it escalates.
–
Steve JacksonFeb 4 '11 at 13:40

Do you have any official code guidelines? If not there is the time to sit down and make them. Then there won't be any disputes whose style is better.

Have a nice and polite talk with your colleague. Ask him for the reasons he's doing continuous code rewritings. Attempt to come to a mutual understanding and respect.

If that fails and the coding guidelines idea is rejected then the only option is to escalate the issue to the management:

1) Rewriting of all of the code to meet the style view of only one person is disrespectful of other team members

2) Rewriting the good and working code is double work which means time and money waste, decreased productivity (unless his code reviewing function is official)

3) This sort of an unauthorized activity has impact on the team morale

Your best bet is to define the coding guidelines and the code review policy. Many reasonable teams are capable of coming to a mutual agreement on their own, but if it fails then there has to be law. Without it it's not going anywhere. That has to be brought up to the management as well as a constructive improvement to the work process.

I guess we should, but it is noc. I do not think we can t only about tabs, spaces and indentations. More commonly, it is about how methods and variables are named, splitting a 10-line method in two, changing method signatures, etstandardize on all this, as there is (at must always be IMHO) some room for personal preferences here. He is the king of indirections, causing hus domain model to have so many layers that only he can understand.
–
ThuneGrillFeb 4 '11 at 13:23

2

Part of the reason for a coding standard is to avoid the inevitable issues that will arise with conflicting personal preferences - you have a set of "team" preferences which are agreed (and reviewable i.e. they shouldn't be regarded as set in stone but they should be adhered to until the team agrees to change them). Beyond that however, yes what he's doing is wrong and there is always going to be some variation between styles of implementation
–
MurphFeb 4 '11 at 13:31

I don't particularly agree with the "look for another job" bit - but fundamentally if he's hacking about with your code (when its work in progress) he's a) not doing his job and b) making yours harder - and that's a management problem.
–
MurphFeb 4 '11 at 13:28

1

"that's a management problem". Generally, that can only be fixed by "look for another job". Since management created the situation, they're unlikely to fix it.
–
S.LottFeb 4 '11 at 13:41

5

@S.Lott, management does not know everything, and they may not be aware of this problem.
–
user1249Feb 4 '11 at 14:08

1

@Thorbjørn Ravn Andersen: "they may not be aware". Agreed. "Talk to your boss and ask him to stop your co-worker. If that does not work, look for another job". I believe that the answer covers that case nicely.
–
S.LottFeb 4 '11 at 14:10

1

I do agree with the "look for another job" bit. This is really the only thing that OP truly has under his control. If you have a coworker who is "managing upward" combined with a boos who is mentally weak or does not care, this is really the only reasonable recourse OP has, unless OP is willing to adapt and put up with crap knowing it's never going to change.
–
Gabriel MaganaFeb 7 '11 at 14:59

In addition, he has a almost
child-like need to have the last word
in any discussion and has never any
word of praise for work done by
coworkers

I think this is the root cause. I have had coworkers like this before, they think they are way better everyone around and they having the last word actually helps the others and the discussion.

There are two ways to deal with these types.

If that person is relatively junior (than you) (not in terms of age, in terms of experience, and not necessarity anything like designation), try to have a talk with him. Or have someone with more experience which this person may have a good regard for talk to him: that he need not always be right, that he should have an outlook of respecting others ald all that stuff.
Personally I have been with such a coworker and this kind of talk did help. He is at least a little better now.

If that person is not someone who can be talked to, or not is relatively senior, take this up with your boss. Tell him/her that his activities are impacting your efficiency.

If he is your boss or way higher than your boss, look for a different job.

When coming up against any kind of force, you have two ways to go, either push against it or go along with it. Your main issue seems to be a psychological one, his refactoring your code and know-it-all attitude is hurting your work pride and might make you feel a bit insecure.

One way to go is to try and look at the style of refactoring he's doing, if it's mainly a style issue try to look at it with open eyes and see if there isn't any positive to it. If you can find value in it then why not let him keep at it? Be secure in your capabilities and see it as being the bigger person tolerating someone with a defiency instead of being insulted. We can chose how we see things and how we react to them.

Otherwise the only way is to make him stop. If you haven't, have a frank and clear discussion with him. Not merely complaining and being confrontational but explaining your point of view and why you don't like him refactoring your code. Make it as honest and non-confrontional as possible. Perhaps you could come up with some kind of compromise where he only refactors code that really needs refactoring.

Otherwise talk to your boss and have him sit down with all of you and resolve this issue

First, your team needs a coding standard. It won't solve your problems, but it will be a step in the right direction.

I wouldn't be too critical of your insensitive coworker (in part because he's an awful lot like a younger version of me!!!), but he needs to learn that there are negative consequences to the project (and hence to himself) of refactoring code while other people are working on it. Professional engineering is about trade-offs, and it seems that he hasn't yet learned about the "down sides" of refactoring code independently of other's work on the same files.

Since he appears to be insensitive to feedback, I too would recommend a private conversation with him, with a supportive coworker present so it doesn't turn into a "me vs you" one-on-one incident. Failing that, raise the issue to the team. Failing that, raise the issue to management.

Raise the issue publicly by keeping track of and reporting every time you have a merge conflict (or other problem) due to his independent refactoring. Like, in the stand-up meetings, report progress and plans, and report the blocker that three times this week, your work has been halted by merge conflicts due to others refactoring the code that was assigned to you to work on. Say that the refactorings were good; you are keeping them, but that it would do less damage to productivity if they'd work with you on it.

If you're willing to live with some real drama, consider going to the team and management after getting hit with big merge conflicts on one of his refactorings and saying that you cannot work on your assigned tasks until he finishes his refactoring of your code. That you will stop all work and wait patiently until he finishes all of his refactorings before it is possible for you to do your asssigned work.

I have taken this to extremes. Prepare to deal with a lot of drama. There is risk. There will be results. (...not always the results you want, unless you play it really well. ;-)

I just wanted to propose a very technical solution to the problem. If you're using a decentralized scm like git or mercurial, you could just wait to push the commits until you're done with a task. That way he won't be able to mess with work in progress.

I know this isn't a perfect solution, but I thought that it might make you feel better if you could hide your changes from him until you're comfortable having him review and edit your code.

I would also like to add that code review isn't a bad thing and if he's doing this in his spare time it means that you're getting it for free. If you get proper code guidelines all of his refactoring should be improvements and not introduction of style.

Make it clear that this is a collaboration effort. As some of the refactorings he does are to the better, I would suggest that you agree with your boss that all refactorings must be done in active collaboration with all the persons actively working on the codebase being refactored.

In this particular situation this would mean that all refactorings MUST be done as pair programming, and I would suggest that YOU type what HE thinks should be done. Any refactorings not done in this way, is to be discarded, and your boss must state that this is the new policy.

How many people are there on the team? The thing about collective ownership is that it is owned by the team, not that the best developer owns the entire teams' code.

And though I am a big advocate for refactoring everything that can be better (if it isn't perfect, improve), I can see that it is extremely annoying that the person in question is refactoring code that is still work in progress. Normally when I find something to refactor, I normally take it up with the guy who wrote it, just asking, "is there any reason this could not have been done like this?". Most of the time, I get an answer like "oh sure, that can be changed", but sometimes, I get answers like, "I am still working on it", or "actually I was about to delete that". And then I'll leave it alone. This also has the positive effect that the knowledge about the code base is better spread among the team.

My advice is to take it up with the team. Let the team reach a consensus that you have refactorings get reviewed by other team members. It should be a team concern, not an individual one.

PS: If the guy was in fact the one in the other question, my advice to him was to involve the team more in his refactorings ;)

Do you have automated tests? If so, refactoring is frequently quite a bit more work. If he has to also fix the tests then maybe he'll be less inclined to muck with your code. If you have to fix the tests then that gives you some more leverage to go to your manager and show how he is wasting your time thereby giving the manager an economical reason to get involved.