How to deal with coworker undoing my (dev) commit

Question

I'm a developer who recently got switched to a project that has been run single-handedly by a co-worker for a few years.

The following has happened more than once:

My co-worker will go straight to our boss and explain to him why solution x (for an item assigned to me) isn't great because of whatever reason, and will go ahead and revert my commit without discussing it with me directly, or including me in the discussion with the boss.

I only find out when I happen to notice his commit that undoes my work, usually with a comment along the lines of "Reverting commit x following discussion with boss, this solution is not good because of y".

Let me note that his position is totally arguable - but so is my side sometimes. (However, our boss is a very busy, hands-off type of manager. Chances are that if you go to him and argue a dev-related point, he'll tell you to go ahead with it.)

What should I do?

EDIT:

Just to note: The issues he brings up are usually related to background that I was not aware of (ie. issues that came up before I joined the project), or a change in requirements that he finds out about from management (sometimes from discussions that he initiates, without my knowledge). Rarely is it actual "bad code".

Answer 1

You should talk to your boss and ask him to call you in every time such a revert is contemplated. Your boss is busy but if he can take time to listen to him, he can take time to listen to you. If these reversions keep happening again and again unchallenged, his perception of your competence will be colored and you may very well get to hear some unpleasant feedback about yourself at performance review time.

Your priority at this point sums up to one word: ACCESS. You absolutely need to be in your boss's cubicle or office whenever he is in that office arguing for a reversion. If you are not in there, you don't get a chance to explain why you did the things nor why you made the choices you made. They can revert the changes you made even if you argue your point but they can't screw around with your credibility as a competent professional. If there is a method to the colleague's madness, you need to hear it and challenge so that a decision is made based on a fair hearing of the opinions involved

Don't allow yourself to be put off by your boss's pleading that he doesn't have the time and that you are working remotely. You have to DEMAND access. It wouldn't hurt your boss to put you on Skype and set up a GotoMeeting or a teleconference to hash it out. I take it that you are on this site because you are sick and tired of having hours and days of your work obliterated let alone having to redo the whole thing. So you need to state to the boss that you need to participate because this workflow as such is inefficient. You don't want to be enlightened as to which approach they want either at performance review time or even before, if the boss gets impatient with you

As for the topic of your discussion on meetup day: you are asking your boss that the next time they talk about your code and reverting it - that you are part of the discussion. It's your code, and you know which piece of code your colleague wants to revert, so you know exactly what the topic of discussion, and what you have to say. Keep the discussion focused on the technical aspects. No need to talk about the less attractive aspects of your co-worker's personality. You are establishing and asserting your own professional credibility, without which you won't have a voice going forward

Answer 2

Vietnhi Phuvan's answer is great but I think there is something to do first: Talk to the colleague.

So you say your colleague has worked on this project for years, but then you commit something he doesn't agree with. Maybe he hasn't seen it before but then that's the issue. It's very likely that he has a better knowledge of the product and the code base.

Before implementing your fix/feature, you should double check with him if your design is going to integrate well with the architecture. And then you could ask a quick code review to make sure he doesn't see anything suspicious that could badly react etc...

You might be as good as him technically speaking, but he definitely has more knowledge about the product and thus his opinion will most likely be the one that will be implemented (this being fair or not is another issue).

If you do that, there won't be any issue involving your boss anymore. If this still happens when your colleague actually gave this thumb up, then apply Vietnhi Phuvan's answer.

PS: if you are working remotely. You can just ask a skype etc... or do a more formal review.

Answer 3

In this case, time is being wasted.

First, you are wasting time implementing features that are not only unnecessary, but, as deemed by a coworker, bad enough to require removal.

Second, your coworker is wasting your boss's time on code matters.

The interactions suggest that something is very wrong with your development process.

1. Who enters tickets into the system? Who vets and approves tickets? Who assigns them? What happens to most tickets? Who guides the development process? Whose vision is being implemented? Who is the customer?
2. Why are developers going to the boss to "undo" tickets? Why aren't developers going to each other, discussing the issues, then presenting a unified face to the boss? Why aren't the developers empowered to make these decisions?

Wasted work, particularly when its not rare, is a significant problem.

I'd go to the boss and make one or more of the following points and suggestions:

• "I've implemented several tasks that were subsequently removed. How can I verify that the task I'm about to work on is useful and necessary before spending time on it? Is there a better way to assign tasks so that those tasks which my co-worker appears to know a great deal about are assigned to him, rather than me? Can we have a weekly or daily standup meeting discussing the tasks we intend to work on, so that those with particular information can chime in on a given task?"
• "Can we adjust the process so that rollbacks must be discussed among team members prior to bringing the issue to you? This should lighten your workload, and get us all on the same page."
• "Can we have each task approved by at least two developers before it is assigned to ensure tasks are useful, and any rollbacks must include discussions with those who approved it so we can make course corrections as a team, rather than individually?'

Honestly it appears there's a severe lack of communication. This could be because there's no leadership or vision.

If the above suggestions aren't taken, you can either live with it, or attempt to be the communications your team so badly needs.

Every time something like this happens - whether to you or anyone else - try one or more of the following:

1. Talk to the individual who had the ticket removed. Ask them for the background as to why they had it removed. Find out if there's a conflict between the ticket and the feature list, or if it's a personal vision they have for the product.
2. Talk to the person who created the ticket. Convey the information you learned in the above step and find out if they were aware of this. Ask them what feature or problem the ticket was meant to manage.
3. Make sure all this information is captured in the design document(s).

Essentially you become an information hub, and you actively move information and the team's vision around so that everyone is on the same page. This can usually be done without process changes or approval, but it's time consuming.

Lastly, if you want to discourage people from removing tasks, have a lengthy conversation about the task. Bring your chair into their office, and really get into the nitty gritty with them to make sure you fully understand what's going on. Don't just accept a quick flippant answer and move on, but really show that you want to understand the overall vision and understanding you have for the project.

This accomplishes three things - one, you spend their time and eventually they'll learn that unless it's worth their time talking to you, it's probably better to let it slide. Two, you will gain their vision for the product/project, and hopefully over time they will gain your vision. Three, the relationship between you will hopefully improve and they will stop going straight to the boss, but to you.

Always be friendly and humble, but fight for what you understand the vision of the product/project to be. If it becomes obvious they are defining the project, then talking with them and disseminating that information will be your best bet at unifying the team.

Lastly, all this talking should give you an idea which tickets come by your desk that they are likely to reject. Go ask them about the ticket before working on it if it seems to be one they'd try to kill later.

Answer 4

Question: My coworker is doing something really annoying, and I haven't talked to him about it. What should I do?

Answer: Talk to him about it. (And him means him, not your other workers, or your boss, or his boss, or HR.)

That is always the answer in a professional workplace. And obviously, you always go into that conversation carefully and professionally. I really think the bulk of the answer should be as simple as this.

However, there is one other side-issue though that needs to be addressed. I hate jumping to conclusions, but there's a possibility that your coworkers think your contributions aren't super great, which is why they're not really respecting them. After you've had the direct conversation above, you may also want to ask a direct question about whether your contributions are sort of sucking, and that's why this is is happening. You should do this, because it's the sort of thing many people are extremely uncomfortable bringing up themselves. You could even 'solve' this problem, by improving communication, but fail to detect this more serious problem.

If they do think some of your changes suck, you need to get on top of this. Solving that problem is an entirely different problem though, which is a little too far afield to discuss here I think.

Answer 5

I agree with Vietnhi how to start covering your... reputation.

You should also ask for a better process. I'll leave the actual details of advocating process change and concentrate on the goals.

If your code passes the tests then that should be good enough for the bleeding-edge development branch (by definition of the development branch), even there's some good reason not to release it. Reverting the change seems to me like an over-reaction, unless your company is flying version control by the seat of its pants. It depends a bit how you use source control, but generally speaking if there's a problem, he shouldn't need to revert it, he should just not take it.

If your code doesn't pass the tests, then your process needs to stop it reaching places it will do damage. Presumably that's what your colleague is trying to achieve by reverting it -- but there's the process issue. If he has to revert it to prevent problems then it's too late, it's already in the place where it can cause problems. You could request this code review before commit rather than after (it's daft, but maybe the way you're using source control is daft and so this is the best there is). You could use more branches, so your colleague can see and complain about the code without reverting it.

You could change the testing/ticketing system, so that the right response to a change that solves the current ticket but is bad for other reasons is to add tests that capture the "other reasons", rather than to revert the change and re-do the original ticket from scratch. In particular, if he finds out a new requirement from management at the same time as you're working according to the previously-known requirements, then he should go through some kind of requirements-change process (maybe just raise a new ticket saying, "requirements have changed"). That process should not be just to jettison all work that relied on the previous requirements: that's not a good way to deal with new requirements.

Also, if you're regularly in a position that you do a chunk of work without knowing that it's useless, then you need more communication before you start work for the day. So you should seek that. Being off-site means that you don't have the opportunity to say out loud in the morning, "I'm going to use the renuberator to solve this issue", and for all the old-timers who've been there longer than you to groan, "aargh, you can't do that, the renuberator is held together with spit and bailing wire and won't stand the pressure".

You could ask your colleague not to bother the boss first when there's an issue with your code, just tell you what the problem is. Then you can mutually discuss a better solution and take that to the boss. Saying "this needs to be reverted" is a lot like saying, "ForOhFor's entire day yesterday was wasted", which doesn't reflect well on anyone. Your colleague might not agree, but if he refuses then at least you have positive evidence that he's knowingly screwing you over, rather than just following a workflow that's surprisingly aggressive towards stuff he disagrees with.

Answer 6

Don't know anything about the size of the company, but here's what I surmise:

This guy feels threatened, even if you may not be a better dev. Though I'm sure there are many economically sound situations where a person would be fine with being the only coder on a small project or at a small company, the fact that he was the sole worker on this project should be a HUGE red flag.

It implies...

• the company does not place a lot of weight in software development. If so you'd be walking into a better process and a bigger team. Besides, what good dev wouldn't at some point run from a solitary situation like that to become better by working with other devs?

• They probably brought you in because they want to increase speed on the project (mythical man month, anyone?) and to lower their "bus factor" by disseminating very specific project/codebase knowledge. If he were a "team player" he'd realize this and instead of going to the boss and reverting your changes, he'd sit you down and help you understand how to better reason about the system, or suggest that you hold pre-design discussions or something.

• He's used to doing things his way and resistant to change. Best case scenario is that he's an awesome dev but a lame social being who makes work awkward. Worst case is that all that those lame parts are still true -plus- he may not always be right about design decisions and/or good practices.

As others have pointed out, this situation will probably erode your reputation over time. You probably want to be somewhere else.

Answer 7

Start generating tiny changes. Instead of rewriting a whole subsystem and then committing that, commit each and every little step along the way. Force the "guy that has the ear of the manager" to go to the manager at every step and say that the changes you're making are harmful. If the manager has any sense, all the "But [x]" and "Because [y]" will become wearisome, and the manager will start to immediately discredit the useless party's rantings about the harmfulness of your code.

I'm fairly trollish in how I deal with corporate types. I'm a naysayer against bad ideas while some corporate lackeys appear to be naysayers against good ideas, because those represent change... So, I've developed a lesser strategy. The only solution (which for reference, I've never been able to completely execute properly in corporate hell) is to spam the system with little good ideas that can't be refuted.

If all this fails, do the American thing. Pre-solve a big problem and submit the solution to it slowly so that scenario 1 occurs but in such a way that it is that much more impossible to refute. In the mean time, take the money and run. Work slow, cash in fast. Jerk manager brought it upon the whole organization.