Taro Logo
3

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

Profile picture
Anonymous User at Taro Community7 months ago

I am on a tight deadline to deliver an impactful and complex feature. Whenever I send my PR out for review, my lead takes at least 2-3 days to start reviewing the code. Then, there are either a lot of non actionable comments or feedback on tests. So I started sending out a test plan in advance which also receives a lot of feedback. When I turnaround with a refined PR, the lead again takes 2-3 days for a review. I am worried that there are too many iterations for a simple PR and I am chasing the lead for reviews. When I hinted about the review taking time, I got a response that the code shouldn’t have had so many flaws to begin with. The code doesn’t have bugs, he was nit picking on unit tests that could be refactored for better maintainability. I agree, but should that be a show stopper?

I had my code reviewed by a peer and received feedback that there are no blocking changes and the code is mergeable. For a complex feature, I expected 1-2 iterations but each iteration is draining and am starting to wonder if I am really that bad an engineer. 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 I'm a kid. I expect some amount of professionalism but I feel disrespected because of the attitude. Is it normal for 2-3 iterations for a slightly complex PR and should I have to chase reviewers each time? Do you any tips on handling the behavioral issues?

113
2

Discussion

(2 comments)
  • 4
    Profile picture
    Head of Engineering at Capgemini
    7 months ago

    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.

  • 5
    Profile picture
    Tech Lead, Senior Software Engineer [L5] at Google
    7 months ago

    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.