At my job as a software engineer, I am in a situation where I am right and my coworker is wrong. This is definitive; it's a black and white situation that can be "Googled" for an answer.

Normally I would just let this slide but the problem is that it disrupts workflow. In Ruby on Rails, you use these things called migrations to edit the database.

The bottom line is that I use migrations correctly, he does not, and it creates problems in our workflow. I have mentioned it to him as sort of a suggestion, but the response I received was "well, to each his own". False. In this case there is a defined practice that is not to be deviated from. My boss knows this, but I haven't brought the issue up with him because I would like to do it correctly.

All I want is for my boss to ask my coworker to change this annoying habit. I don't want to be a "tattle-tale" but I also don't want to have to continue cleaning up other people's slop.

  • 1
    Have you told him? It is unclear from your question.
    – aclear16
    Commented May 19, 2014 at 21:53
  • "Duuude, you're throwing off my groove man."
    – Omegacron
    Commented Mar 8, 2017 at 21:12

10 Answers 10


From your explanations, the problem isn't that he is wrong per se. The problem is that he is disrupting workflow because his method of doing things is not working.

You are not going to win anybody over by waving a print-out of the correct way to do migrations. Your job is not teach him how to do migrations or wave the flag of rightness in the face of his wrongness; your job is to do your own work.

The focus of your discussion with him and/or your boss should be that his method of doing things is disrupting your workflow. It's not about emphasizing that the other guy is wrong, it is about your workflow disruption.


Like it or not, you'll have to escalate to your boss. Otherwise, your partner in crime is not going to change what he is doing, and he'll be spreading his defective code all over the firm's repositories.

You are tired of cleaning up after him, and you want a change. Good. Because you can't be around him forever and he'll do this stuff while you are on vacation or on personal days. You just can't keep an eye on him every hour of the day, every day. It's just not realistic.

So escalate it to your boss and have your boss lean on him. Regardless of whether you feel guilty - and you shouldn't, this has to stop. You have to go to your boss because you don't have the authority to order him to stop, he knows it and he is acting accordingly.

Follow-up comment from @MJ6 "Agree. You've approached it with him and he disagreed. This is a business concern and your boss needs to weigh in. It does not have to be a tattle. Address is positively - "Coworker and I have been approaching this differently, and I am concerned about the integrity of our code. Can you confirm for us which way it should be done?"

You are far more diplomatic than I will ever be :)

Follow-up comment from @Carson63000 "After seeing Brian's response [about the boss] to my comment question, this is definitely the right approach. If the boss was non-technical, this would all come down to politics. But as Brian says the boss is a well-qualified, technical CTO, it's perfectly reasonable to present the opposing views and ask for a ruling. Nothing tattling about it. A technical team needs to be pulling in the same direction and it's the senior technical person who determines that direction."


I agree with this answer. You need to focus on the root of the problem and in this case it is the workflow.

What are his arguments for his process? What are the problems caused by his process? How much of a disruption to the workflow is it? What problem is solved by following the "correct" process?

Telling someone they are wrong and you are right will probably only get you negativity unless it is someone you know very well that won't take it personally. It comes off as arrogant and elitist.

Instead of saying that you are right and they are wrong and using Google to back you up it is a much better idea to explain the problem it is causing and how you have to work around the issue and how the situation can be improved.

Also, scope and severity is sometimes relevant. I sometimes tend to argue the "perfect" approach and later on, given some time and perspective, I realize that I was arguing about trivialities.

Familiar with Scrum? Scrum has retrospective built in so you can raise these issues and discuss it in a team environment. This may be an option for you if you are struggling getting the message across. If you are not doing Scrum suggest a weekly / fortnightly meeting where you discuss issues with your process / workflow and how it can be improved. Time box meetings to 30/60 minutes so management doesn't get upset with too much time spent in this meeting and scrapping it.


There are times when a solution that was "googled" is beyond a shadow of a doubt the far superior approach to a problem or falls under best or at least better practices.

If this is such a case and you find yourself at a stalemate with your coworker about this, then it's important to go up the food chain and try to gently force the issue. Make your argument to your lead and present it in a respectful manner both towards him and in regard to your coworker, but be adamant about where you believe your approach is better.
Do your homework beforehand so you have a strong case: find out why your coworker believes his solution is better and listen. Then have a one on one meeting with your lead and present the issue. Present it from a technical standpoint, not as if it's a personal issue you're trying to resolve. It's not a race between you and your coworkers. It's most certainly never personal, then your well-researched case loses credibility. Be prepared to have your idea or standpoint shot down either way, that's the way it sometimes goes. Go there to talk but first and foremost, once you've made your case, listen to his or her why's and hows.

In the end, in many work environments (whether they be technical or not), due to either technical, historical or personal reasons, solution approaches might be chosen that are not always what google might tell you to be the ideal one or what you might think, are. We all know that.
Whether google is right (or whether you are) might in the end be of lesser consequence than deciding on a single approach that will be the standard to work by and that sort of team/technical decision is what your lead or manager is there for and can help achieve not only for you but for the whole team.

There is always deviation from a chosen standard or a chosen way of doing things -much to anyone's frustration from time to time-, but I personally feel it is very important to keep it at a minimum. It makes working with coworkers easier and it makes your work easier.


You cannot clean up after someones slop for a long time and finally be sick and tired of it and go to management. There has to be a grace period and there must be several opportunities for him to correct his behavior. This may take one or more discussions. Document when you asked him to correct as you might need this later.

I propose an alternate solution after speaking to him. Each and every time the workflow is interrupted ask him to fix it instead of fixing it yourself. Remain pleasant but but mention that it could have been avoided if he used the alternate method. Under no circumstances correct his mistake. If the issue is severe enough it will eventually affect a deadline. When this is a business problem and not merely an annoyance then go to management. Take your documentation and I think you will get full support from management.


You have three options:

  1. Verbally explain to your coworker why he is wrong. If he refuses to understand, raise your voice and waive your arms so that your coworkers can see that you're on the right side of the argument.
  2. Reserve a conference room and schedule a one hour meeting with your coworker. Create a PowerPoint presentation with no fewer than 20 slides. When preparing for the meeting, plan to speak for 55 minutes and leave 5 minutes for questions.
  3. Do your homework. Assemble compelling evidence from credible sources that demonstrate why your opinion is correct. Tuck these inside of an email with all relevant hyperlinks. Use friendly and disarming language. Send it to your coworker in the morning before he/she arrives.

If you do any or all of these, and your coworker still disagrees, then invite your boss to a small informal meeting so that he/she can weigh in and break the tie.

Hint: Option #3 has the highest probability of success. ;)


I think you're going with the right approach. The colleague hasn't been receptive of your advice so you're left with little choice but to talk to the manager about it.

I agree that this shouldn't be you telling on them, it would be better to submit it to the CTO as a company standard. When using migrations, you've researched and found problems using certain methods and you are concerned that these problems may start to surface within the company. Therefore you would like to propose a standard to be used in new projects and have colleagues(implicitly including the problem colleague) take half an hour to update theirs to meet it.

This fixes the problem without directly attacking the colleague and prevents the problem from resurfacing in the future if any new developers also try to use the wrong technique.


From your point of view, this is a bug, or at least an enhancement. Open a ticket in the bug tracker and keep-on documenting it as long as it remains a pain for you. It will educate the guy about your feelings and your management about the situation ( time lost). So you can hope it could change things but I admit that it can also stay the same.

Don't forget this is a very delicate situation and that the guy ego can resists a bit or totally. I mean, I don't necessary believe in the PowerPoint solution that is a kind of violent solution: he seems to have his own idea about it, and maybe he thinks you are wrong and he is right. That's why you should go take a couple of beers with him and ask him about his method, understand it and talk about it, before trying to explain him he is wrong.

If you are not comfortable with the beer thing, it can easily be done with coffee at the workplace, but I think you need a special place to speak about special things and not being in the usual context, to go on.


In software, as with many things, there are plenty of ways to accomplish the same task. Some people have different methods, right or wrong. Saying that he is wrong will be a tough way to approach it. That will put him on the defensive. Instead of right or wrong, just mention that there may be a BETTER way of doing ABC and suggest why. Recommend refactoring. I'm always refactoring as I find better ways to do things. It's a natural part of development. I would encourage your group to have some standards in place also. Get in a room with your co-workers and boss to define a few standards. It sounds like this particular issue would be a good place to start. It makes maintenance a easier as well.


Inform your co-worker that in order to be productive, he's going to need to clean up his mess. Tell him that you'd like to do things the easy way, which is why you came to him first; but that you're not going to hesitate to inform your boss if the behavior continues. Set a deadline and give it to him (make sure it's reasonable). Do not bargain or argue if he balks, it's a waste of time.

If the material that needs fixing isn't done by the deadline, escalate. That's all you can do.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .