4

This question already has an answer here:

Last week I was assigned a project by our manager. I started it and worked on it in between some priority work which came up. The project was stuck. So our manager and I decided to forward the project to my colleague who had completed his projects. He accepted the project and completed it. As it was my project, I reviewed it. I found some mistakes, so I pointed them out and asked him to correct them and a few other changes, even though he was already working on another project. He made those changes and I found more mistakes, so I shouted at him.

Was I right to do that?

Should I point out their mistakes in this situation or not?

marked as duplicate by Strader, Philip Kendall, gnat, Blrfl, mcknz Apr 21 at 18:23

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • 1
    Where the second set of mistakes 1) the same mistakes, 2) newly introduced by the first fixes, or 3) more mistakes that you found when reviewing the code again? Also, can you explain more clearly what you mean by "a little hyper"? Shouted at him? Called him stupid, etc.? – mkennedy Apr 18 at 16:34
  • The whole point is I pointed his mistake and got hyper on him. But the project was mine he had help out. – mecisozok Apr 18 at 16:34
  • What I had done is wrong or right. In IT Industry – mecisozok Apr 18 at 16:35
  • @mkennedy thanks for making it clear – mecisozok Apr 18 at 16:39
  • 1
    When you say "I shouted at him" do you literally mean you raised your voice and yelled at him? Or is this just a way of saying "I told him he made some mistakes"? Telling someone they made mistakes is fine, yelling at people is wrong. – DaveG Apr 18 at 17:52
19

The problem isn't that you raised the mistakes with your colleague, but -how- you raised them. You state that you "shouted", and "got hyper" with your colleague.

In a professional environment, shouting is rarely, if ever, appropriate.

You should reflect, truthfully, on how you communicated with your colleague, and consider, perhaps, apologizing.

In general, when providing feedback, one should focus on objective facts, without emotional response to them: code review is not emotional, it's factual. Requiring multiple passes is not abnormal, and certainly does not justify yelling at your co-worker.

One other thing important to realize is: while you may have been assigned the work, the project is not "yours": it belongs to the company. Any emotional investment you may have into the code in question is likely misplaced.

The moment your manager asked the other developer to help out, they became just as rightfully involved in the project as you. Unless your manager has delegated authority to you, above the other developer, they are a -peer-, and should be treated as such.

11

No. You were wrong.

In some cultures such behavior may be more acceptable than in others. Even if my American sensibilities don't fit where you are, fear and intimidation rarely work as well in the long run than as pride and ownership.

This person may try harder to not draw your wrath, but they will forever be less likely to respect you or help you willingly. You just made any excuse they can find to avoid you more attractive. And if they see you are about to make a mistake, I doubt they're going to lift a finger to avoid it. If I had done the same, I would be apologizing for my behavior.

This doesn't mean you can't address issues or that you cannot be direct in doing so. But attacking someone is not the way.

  • You can apologize. You probably should apologize. – O. Jones Apr 20 at 21:48
4

This is very concerning considering that you do not know that shouting is unacceptable in the workplace. Let me ask you this: How does shouting produce productivity in someone? That was definitely not OK because you don't know how to keep your emotions in check. Not only have you hurt that person by embarrassing them, but you've made yourself look unstable and difficult to work with.

To answer your question: There is nothing wrong with pointing out mistakes to a peer. As peers, you are supposed to help each other to get the project/work completed to your manager's standards. If I were you, I would frame it as, "How can I help this person to minimize the mistakes the next time?"

This person has every right to be there just like you do. This person has feelings, a family, friends, just like you do. You are in no position to look down on them in the form of an emotional outburst. You need to apologize.

2

No, code reviews are a standard software development process. If a bug is caught during code review it is definitely not a case for shouting and also not for the manager. If you want bug-free code, do the following:

  • write tests (in extreme cases: test driven development)

  • give coding guidelines

  • do reviews without shouting

  • communicate to the manager about peoples performance only when being asked by the manager (i.e. when problems in the project become or will become apparent to the customer/manager.

Shouting and running to the manager leads to a messed up up culture of dealing with mistakes. People will be more busy to cover their ass and at some point shouting back than fixing the bugs, and in the end the code will be worse, since people will not like to be part of that process.

Not the answer you're looking for? Browse other questions tagged or ask your own question.