How to react when code reviews take a lot of time and can get disrespectful?

If you feel hostility during the reviews, especially if they are in person, I'd suggest investigating whether it's only directed at you or a pattern for PRs submitted by other team members as well. If it's not a pattern across the board, you could take a look at other PRs that didn't go through as many iterations and/or not met with hostility to see what the differences are (they could be interpersonal and not technical, but either way it's good idea to find out what's behind this).

However, if the lead responds this way regardless of who submitted the PR, I would try to have a discussion with him on "code review standards and conventions". This reframe is important, as it bring it up to the process / standards level and away from any individual PR, which is beneficial because:

• Defending a PR can appear defensive and will probably lead to the same type of interaction you're currently having while reviewing the process makes it less personal
• Getting things documented in a process / standards can be referenced later, so there's less debate at the individual PR level and becomes a policy vs. exception level conversation, which is way easier to navigate
• Improving the process can lead to improvements at the overall team / department level to find the right balance between quality and speed, also what's a showstopper vs. a nit comment

Feel free to DM me on Slack if you want to explore this topic a bit further.

First, let me acknowledge how maddening this situation can feel.

The biggest problem is that the reviews happen in person and the reviewer gets nasty and yells at times. He is extremely rude and after a few minutes he tries to explain that all the feedback is for my own good like am a kid. I expect some amount of professionalism but I feel disrespected because of the attitude.

An engineering lead shouldn't make anyone they are responsible for feel this way, even if reviewing their code can be frustrating. You don't deserve to be yelled at, no matter what your code looks like. Many people struggle at having efficient code review processes because code reviews are ultimate tests of communication and trust between people, and we generally suck at it.

It's quite possible your lead has a behavior problem, or there's generally a lack of commonly agreed upon standards like Casey said. 2-3 days is a long time, the general SLA for a healthy software team is 24 hours / 1 business day, and preferably much faster than that.

But who's at fault here isn't ultimately that important, because usually all parties contribute to the problem. As you can't count on others to change, it's important you to ask yourself this question: How am I contributing to this? Why might a code reviewer take a really long time to review my code?

A couple of reasons I can think of:

1. The reviewer is extremely busy and preoccupied with other work.
2. The reviewer isn't familiar with the particular code base.
3. The reviewer doesn't like to review the code for specific engineers, because historically these engineers' cls have required many iterations and many comments, which were (1) energy consuming for the reviewer (2) produced unpleasant human interactions.

If #1 or #2 is true, escalate to your manager and maybe get more help for your leads to distribute review responsibilities.

But it's also possible #3 is in play here. As a code reviewer, I am partial to, and am more responsive to, certain code authors. It's not that I want to be and I personally strive to do better, but I just know from experience that certain people produce code reviews that align better with the principles and styles of our code base compared to others. It's just human nature to delay activities that produce stress - and both code authors and the code reviewers find lengthy code reviews to be stressful and frustrating.

If your lead is otherwise pretty fast on reviews with other folks in your team, I would definitely try to understand if I have done everything I can to produce clean, easy-to-approve code reviews. I would recommend watching this Taro Video for some guidance, but one of the key there is that "getting the code to work" / "not have bugs" is merely the first and easiest step. There's usually equivalent amount work to get the code, PR/CL description, test plan, etc, to be sufficiently up to standard BEFORE sending it out for review. I wrote a quick this to describe what code reviewers generally look in a code review and it might be helpful to you as well.

It's also not impossible that your lead feels guilty about being an a** and would appreciate the opportunity to help you understand how to prepare such clean, easy-to-approve code reviews in your code base. Either way, a conversation would likely help, especially after reading this you would like to change how to approach code reviews in the future.