19 ms·

Building an Inclusive Code Review Culture

164 points by whockey 8y ago

crunchlibrarian 8y ago
Most code reviews I've participated in have devolved into the senior/loudest person making sure that people know who they are and what everyone's place in the hierarchy is. Even in reviews where the reviewee had some amazing code that was kind of groundbreaking in one area, still have to find something to gripe about because I have 20 years on this kid. This seems to be quite common in science/engineering, not just in code reviews. I wish I could find that company where nobody gives a shit about their place in the hierarchy and everyone isn't constantly trying to gun for other people's jobs to make their linkedin profiles look more impressive. It's been a looooong time now, still searching.
- ghthor 8y ago
  If you're in NYC or SF apply to foursquare. We're not perfect, but we have a nice culture that is engineer driven and is very egalitarian.
- notyourwork 8y ago
  My current company doesn’t have that problem (at least in my team) but I’m sure some teams do. I think this is everywhere and depends on team culture.
- Bjartr 8y ago
  > I wish I could find that company where nobody gives a shit about their place in the hierarchy and everyone isn't constantly trying to gun for other people's jobs to make their linkedin profiles look more impressive. It's been a looooong time now, still searching. They definitely exist (I work at such a place) so I wish you the best of luck in your search!
- lolc 8y ago
  Yes. There shouldn't be any reviewee except the code itself. But this is hard to get right. One of the questions I try to ask myself with any comment I write as a reviewer: "Would I accept this comment?".
  - jelambs 8y ago
    Author here, I think that’s a great approach. We surface our guidelines for every PR by including a link to them in the description template. This acts as a reminder for people to be thoughtful about their review. I think the fact that our guidelines were based on input from the most senior to the most junior engineers says a lot about how much we value everyone’s opinions and perspective, not just the loudest voices.
- daveFNbuck 8y ago
  > still have to find something to gripe about because I have 20 years on this kid I wish I had someone with decades more experience than me taking the time to find areas where my code could improve. Regardless of their motivation, this sounds like an amazing resource that you're lucky to have.
  - nilkn 8y ago
    I think their motivation still matters quite a bit. Just because someone has 20+ years of experience doesn't mean they're actually leveraging any of that for their review. If they're nitpicking something unimportant and they're only doing it for political reasons, then in that act they are contributing negative value to the team, regardless of experience.
    - daveFNbuck 8y ago
      If someone is that much more experienced than you are, it can be hard for you to tell the difference between nitpicking and something that experience has taught them is more important than you realize. Even if it is just nitpicking, that still means your code has nits to pick.
      - starbugs 8y ago
        Be sure that I can come up with nitpicking on just about anything that you write, regardless how brilliant you think your piece of code is. This just costs money, burns people, and results in a bad culture. But I am sure as long as you're not the one who is in the weaker position that's totally ok for you, because you give considerably more fks about yourself than about your company's success.
        megaman22 8y ago
        Unless code review is a rubber-stamping process (in which case why bother? just party on production...), you're inviting criticism and improvement, so freaking out about receiving some and getting defensive or calling people toxic is... less than productive. One prolly shouldn't be a jackass as a reviewer, but if comments or questions on what you're doing get your back up, one should perhaps grow a thicker skin as a reviewee.
- starbugs 8y ago
  Not sure why this is being down voted. This is exactly the number one thing I have experienced happening with code reviews, especially peer reviews. This attitude often completely breaks the effectiveness of the whole process, making it a deal breaker for quick iterations and agile projects.
  - kanox 8y ago
    Maybe because many people haven't experienced this? The parent poster also said this: > I wish I could find that company where nobody gives a shit about their place in the hierarchy and everyone isn't constantly trying to gun for other people's jobs to make their linkedin profiles look more impressive. This does not resonate at all.
    - starbugs 8y ago
      So "I haven't experienced this before therefore it doesn't exist. Have a downvote :)"? I kind of agree that the parent poster's tone could have been chosen with a bit more care though.
      - UncleMeat 8y ago
        OP is implying that this problem exists everywhere. This is simply not the case.
        starbugs 8y ago
        Agreeing on that. But oh look, it's no longer being downvoted. Perhaps there's something to this after all?
    - nck4222 8y ago
      >Maybe because many people haven't experienced this? Oh god I hope not. What better way to create an echo chamber than to silence the voices of everyone who has different experiences than you...
- mattlondon 8y ago
  We dont have that problem where I work so it does exist. I've sort of experienced something similar myself when I've been doing reviews though - the feeling that you've got to find something to comment on. I've also been "star-struck" by getting reviewed by someone very senior or "famous" in the open source/tech world and basically blindly doing what they suggest. The problem we do have though is huge queues for qualified reviewers and getting randomly allocated a reviewer somewhere on the other side of the planet so that even if they have minor comments (e.g. trivial typos in comments) you're looking at a 48 hour turnaround to get your code checked in sometimes. I guess for the age/hierarchy thing, it could be possible to make the reviews double-blind via the tooling? I.e. reviewers dont know who they are reviewing, and the reviewee doesn't know who is reviewing them. Obviously once the code is committed then everything would become clear and transparent. Might help in larger orgs, although I dont doubt that it would be fairly easy to make an educated guess who is writing the code a lot of the time, and you'd be able to dig into git/whatever to see the details, but just hiding it in the review tool might go a long way to prevent unconscious biases. If someone has a real axe to grind is deliberately going out of their way to find out who wrote the code during a double-blind review so they can make special comments then you probably have a bigger problem.
- sanderjd 8y ago
  This is one failure mode that definitely exists. Another failure mode is less experienced folks who believe all their code is perfect and take criticism personally. I honestly don't know which failure mode is more common. I do know that I had the latter problem in spades when I was earlier in my career and that I'm really paranoid now about being that senior person on a power trip. But if everyone is trying really hard to both act in good faith themselves and assume good faith in their coworkers, careful reviews are the best way I'm aware of for getting great code into the tree.
- reggieband 8y ago
  We have a reasonable way of dealing with this - bugs found in code reviews MUST be fixed - coding style violations MUST be fixed (ideally all of these are caught by lint but not all are) - everything else is treated as optional Some code review tools even provide the ability to specify required vs. optional feedback. We now use github reviews which doesn't have this feature so we usually just add OPTIONAL to any review comment that isn't in the MUST fix category. Occasionally a reviewer and reviewee will get into discussion/disagreement over the approach a particular code change. In those cases if it isn't clearly a bug or a style violation we err on the side of the reviewee.
- ironjunkie 8y ago
  I have seen that in a lot of places also. There is that need for the reviewer to prove himself by nitpicking non-issues in the code.
zhangela 8y ago
How do you all make sure the code review requests get load balanced across the team, as opposed to 2-3 people getting all the PR requests?
- notyourwork 8y ago
  Not everyone is the right person for a specific code review. Even on small teams someone may be more of a subject matter expert in one facet of your system or code. Therefore load balancing isn’t really the right way to look at it. The idea should be to seek feedback inclusively and welcomed from all teammates. As a submitter your job is to make sure you get the right feedback if there is someone more knowledgeable of a topic. This is why standup is a good place to discuss a code review where you can identify need for time and also identify right people.
  - zhangela 8y ago
    Agreed it shouldn’t be an even distribution of review requests across the board. That said, if a few people are getting all the reviews, it’s difficult for them to make progress on their project work, and for other engineers to learn code review best practices and get familiar with the codebase.
    - notyourwork 8y ago
      It’s a balance but you need to balance team priorities. If you aren’t shipping code because of your time on code reviews you need to better manage your time. Call it out during stand up (assuming your team has them) and make it clear you don’t have time or code reviews today because you need to focus on your deliverable. If the review is more important your team can identify this collectively. However, individuals should never feel you describe, if so it’s a lack of coordination across team.
- jelambs 8y ago
  Author here, that’s a great question! We approach this by ensuring that there are always multiple people that can review a given codebase or service. In practice what this looks like is we have teams that own our different services. Rather than just assign a random person from that team if you’re making a PR for one of their services, we utilize what we call “open” slack channels, where any one can ask questions of the team. So you’ll go to the teams’s slack and ask for someone to review. We recommend @ mentioning the people who’ve most recently made significant changes to the code you’re working in as they’re most likely to be the best reviewers. But by sharing the responsibility across each team, that ensures there’s no piece of code that only one person across the whole engineering organization is qualified to review. For projects within a team, there will generally be one or two dedicated reviewers and we utilize stand ups to check in and make sure no one is overloaded with reviews. And since the whole team has familiarity with the project, it’s easy to swap out a reviewer if someone is overwhelmed or on vacation.
aequitas 8y ago
"If someone has committed many crimes against the style guide in a PR, the reviewer should point them to the style guide..." Everything a computer can do trivially should not be done by humans. There are plenty of tools available to validate code to all the standards you can dream up. And most languages allow you to even automatically fix style errors or even enforce it for compilation (thank you Go). So instead of codifying it in a style guide document, codify it in config files for linting and autoformat tools instead. The defaults of those tools are often fine for what you need and exceptions can as easily be documented in them as well.
- ISL 8y ago
  > Everything a computer can do trivially should not be done by humans. Agreed, to a point. In many contexts, it is important for humans to do things themselves occasionally in order to learn how, even if a computer is generally used to do those things far more quickly.
  - jelambs 8y ago
    Agreed, computers are generally way better than humans at catching many style issues. We utilize linters extensively, those enforce many of our style guide rules. However, there are some, such as the example pictured in the article, that aren’t always detectable with a linter. In these cases, we use the style guide as the source of truth to reduce the amount of personal preference that comes into code reviews.
    - aequitas 8y ago
      Agree, for everything that doesn't go automatically or would be to much effort to automate a single source of truth must be maintained.
  - aequitas 8y ago
    I agree with that if you would be learning a language. But even then, being bothered by indenting, alignment, spacing etc gets tiresome and the small amounts of time lost accumulate over the day.
spenrose 8y ago
Based on my experience with Mozilla's mature code review culture, this article is excellent. If I were going to make one suggestion, it would be to emphasize the points that author jelambs makes below: this approach to code review is inseparable from a commitment to deep shared understanding of the code base. It both depends on and supports that understanding. It's an investment in quality as embodied in a particular technical approach and body of work. It's not cheap, but what it buys you can be very valuable.
tdsamardzhiev 8y ago
The real problem here are people with bad attitude and poor communication skills. Bullying other people is a punishable offense in real life, and I don't see why code reviews should be any different. Have some basic rules regarding communication. Issue a public warning for first-time offenders. Give them the boot if they do it again. There, problem solved.
- sqrt17 8y ago
  You sound like you didn't read the article. There's nothing about political correctness or try-hard inclusivity in that article but many (or indeed all) the things that common sense would dictate as a base of working code reviews.
  - tdsamardzhiev 8y ago
    No, I didn't read the article. But I did read the entire comment section, if that counts :)
- ergothus 8y ago
  It seems overly simplistic to say that effective code reviews are inevitable if only you can prevent people from being rude. Certainly not a bad START, but I dare to think there may be additional ways a review can be a GOOD one as opposed to just not being a BAD one. It's easy to forget that we're still learning how to write "good" code, and that many of our best practices continue to evolve, occasionally into VERY different things. A Code Review has to be able to identify poor practices as distinct from UNUSUAL practices, with that latter evaluated in terms of cost-benefits and not forgotten even when the costs are too high in the current project - that may be a practice to try out where there's less impact to being inconsistent. A Code Review has to balance the subjective opinions of multiple devs to try and achieve some consensus that is treated as objective. None of this is easy nor truly figured out, and not being a jerk is just one of multiple steps to accomplish.
- maerF0x0 8y ago
  @tdsamardzhiev What sorts of "bullying" have you seen in code reviews before? Having some anti-pattern examples could be useful to codify into a developer guid.
wowYuck 8y ago
Yuck.
egyptiankarim 8y ago
Neat to see that they started by interviewing a diverse subset of their engineers; that type of user-centric research is invaluable. Moreover, I wonder what of their methodology could be mapped to a live analysis of the code review conversation threads they're having via GitHub. More than anything else, though, I'm curious where teams like this still go to buy those amazing Apple Cinema displays?!
brian-armstrong 8y ago
Not focusing on style violations is foolish. Imagine someone submitted an English paper littered with grammatical errors and typos. It would be difficult to find the intended meaning and bigger picture. Style violations are the same, they have to be fixed before a deeper review can even take place.
KKKKkkkk1 8y ago
How common is it to get unsolicited reviews on your PRs? In my team, I have some colleagues who will routinely pipe up when they see a PR being uploaded by an "outsider" and will write a litany of complaints in order to block progress and establish their dominance. (I should mention that these colleagues work in a branch office, so this is their only way to assert themselves.)
- knocte 8y ago
  > in order to block progress This is your subjective interpretation of the facts. Learn how they complain (in the end, they only can complain about technical facts: learn them, and be correct next time), and you will not receive complaints anymore. I'm guessing you're new to code reviews right?
  - deleted 8y ago
    [deleted]
Confusion 8y ago
Good article, but I don't understand why the word 'inclusive' is in the title.

164 points by whockey 8y ago

Most code reviews I've participated in have devolved into the senior/loudest person making sure that people know who they are and what everyone's place in the hierarchy is. Even in reviews where the reviewee had some amazing code that was kind of groundbreaking in one area, still have to find something to gripe about because I have 20 years on this kid. This seems to be quite common in science/engineering, not just in code reviews. I wish I could find that company where nobody gives a shit about their place in the hierarchy and everyone isn't constantly trying to gun for other people's jobs to make their linkedin profiles look more impressive. It's been a looooong time now, still searching.

ghthor 8y ago
If you're in NYC or SF apply to foursquare. We're not perfect, but we have a nice culture that is engineer driven and is very egalitarian.
notyourwork 8y ago
My current company doesn’t have that problem (at least in my team) but I’m sure some teams do. I think this is everywhere and depends on team culture.
Bjartr 8y ago
> I wish I could find that company where nobody gives a shit about their place in the hierarchy and everyone isn't constantly trying to gun for other people's jobs to make their linkedin profiles look more impressive. It's been a looooong time now, still searching. They definitely exist (I work at such a place) so I wish you the best of luck in your search!
lolc 8y ago
Yes. There shouldn't be any reviewee except the code itself. But this is hard to get right. One of the questions I try to ask myself with any comment I write as a reviewer: "Would I accept this comment?".
- jelambs 8y ago
  Author here, I think that’s a great approach. We surface our guidelines for every PR by including a link to them in the description template. This acts as a reminder for people to be thoughtful about their review. I think the fact that our guidelines were based on input from the most senior to the most junior engineers says a lot about how much we value everyone’s opinions and perspective, not just the loudest voices.
daveFNbuck 8y ago
> still have to find something to gripe about because I have 20 years on this kid I wish I had someone with decades more experience than me taking the time to find areas where my code could improve. Regardless of their motivation, this sounds like an amazing resource that you're lucky to have.
- nilkn 8y ago
  I think their motivation still matters quite a bit. Just because someone has 20+ years of experience doesn't mean they're actually leveraging any of that for their review. If they're nitpicking something unimportant and they're only doing it for political reasons, then in that act they are contributing negative value to the team, regardless of experience.
  - daveFNbuck 8y ago
    If someone is that much more experienced than you are, it can be hard for you to tell the difference between nitpicking and something that experience has taught them is more important than you realize. Even if it is just nitpicking, that still means your code has nits to pick.
    - starbugs 8y ago
      Be sure that I can come up with nitpicking on just about anything that you write, regardless how brilliant you think your piece of code is. This just costs money, burns people, and results in a bad culture. But I am sure as long as you're not the one who is in the weaker position that's totally ok for you, because you give considerably more fks about yourself than about your company's success.
      - megaman22 8y ago
        Unless code review is a rubber-stamping process (in which case why bother? just party on production...), you're inviting criticism and improvement, so freaking out about receiving some and getting defensive or calling people toxic is... less than productive. One prolly shouldn't be a jackass as a reviewer, but if comments or questions on what you're doing get your back up, one should perhaps grow a thicker skin as a reviewee.
starbugs 8y ago
Not sure why this is being down voted. This is exactly the number one thing I have experienced happening with code reviews, especially peer reviews. This attitude often completely breaks the effectiveness of the whole process, making it a deal breaker for quick iterations and agile projects.
- kanox 8y ago
  Maybe because many people haven't experienced this? The parent poster also said this: > I wish I could find that company where nobody gives a shit about their place in the hierarchy and everyone isn't constantly trying to gun for other people's jobs to make their linkedin profiles look more impressive. This does not resonate at all.
  - starbugs 8y ago
    So "I haven't experienced this before therefore it doesn't exist. Have a downvote :)"? I kind of agree that the parent poster's tone could have been chosen with a bit more care though.
    - UncleMeat 8y ago
      OP is implying that this problem exists everywhere. This is simply not the case.
      - starbugs 8y ago
        Agreeing on that. But oh look, it's no longer being downvoted. Perhaps there's something to this after all?
  - nck4222 8y ago
    >Maybe because many people haven't experienced this? Oh god I hope not. What better way to create an echo chamber than to silence the voices of everyone who has different experiences than you...
mattlondon 8y ago
We dont have that problem where I work so it does exist. I've sort of experienced something similar myself when I've been doing reviews though - the feeling that you've got to find something to comment on. I've also been "star-struck" by getting reviewed by someone very senior or "famous" in the open source/tech world and basically blindly doing what they suggest. The problem we do have though is huge queues for qualified reviewers and getting randomly allocated a reviewer somewhere on the other side of the planet so that even if they have minor comments (e.g. trivial typos in comments) you're looking at a 48 hour turnaround to get your code checked in sometimes. I guess for the age/hierarchy thing, it could be possible to make the reviews double-blind via the tooling? I.e. reviewers dont know who they are reviewing, and the reviewee doesn't know who is reviewing them. Obviously once the code is committed then everything would become clear and transparent. Might help in larger orgs, although I dont doubt that it would be fairly easy to make an educated guess who is writing the code a lot of the time, and you'd be able to dig into git/whatever to see the details, but just hiding it in the review tool might go a long way to prevent unconscious biases. If someone has a real axe to grind is deliberately going out of their way to find out who wrote the code during a double-blind review so they can make special comments then you probably have a bigger problem.
sanderjd 8y ago
This is one failure mode that definitely exists. Another failure mode is less experienced folks who believe all their code is perfect and take criticism personally. I honestly don't know which failure mode is more common. I do know that I had the latter problem in spades when I was earlier in my career and that I'm really paranoid now about being that senior person on a power trip. But if everyone is trying really hard to both act in good faith themselves and assume good faith in their coworkers, careful reviews are the best way I'm aware of for getting great code into the tree.
reggieband 8y ago
We have a reasonable way of dealing with this - bugs found in code reviews MUST be fixed - coding style violations MUST be fixed (ideally all of these are caught by lint but not all are) - everything else is treated as optional Some code review tools even provide the ability to specify required vs. optional feedback. We now use github reviews which doesn't have this feature so we usually just add OPTIONAL to any review comment that isn't in the MUST fix category. Occasionally a reviewer and reviewee will get into discussion/disagreement over the approach a particular code change. In those cases if it isn't clearly a bug or a style violation we err on the side of the reviewee.
ironjunkie 8y ago
I have seen that in a lot of places also. There is that need for the reviewer to prove himself by nitpicking non-issues in the code.

zhangela 8y ago

How do you all make sure the code review requests get load balanced across the team, as opposed to 2-3 people getting all the PR requests?

notyourwork 8y ago
Not everyone is the right person for a specific code review. Even on small teams someone may be more of a subject matter expert in one facet of your system or code. Therefore load balancing isn’t really the right way to look at it. The idea should be to seek feedback inclusively and welcomed from all teammates. As a submitter your job is to make sure you get the right feedback if there is someone more knowledgeable of a topic. This is why standup is a good place to discuss a code review where you can identify need for time and also identify right people.
- zhangela 8y ago
  Agreed it shouldn’t be an even distribution of review requests across the board. That said, if a few people are getting all the reviews, it’s difficult for them to make progress on their project work, and for other engineers to learn code review best practices and get familiar with the codebase.
  - notyourwork 8y ago
    It’s a balance but you need to balance team priorities. If you aren’t shipping code because of your time on code reviews you need to better manage your time. Call it out during stand up (assuming your team has them) and make it clear you don’t have time or code reviews today because you need to focus on your deliverable. If the review is more important your team can identify this collectively. However, individuals should never feel you describe, if so it’s a lack of coordination across team.
jelambs 8y ago
Author here, that’s a great question! We approach this by ensuring that there are always multiple people that can review a given codebase or service. In practice what this looks like is we have teams that own our different services. Rather than just assign a random person from that team if you’re making a PR for one of their services, we utilize what we call “open” slack channels, where any one can ask questions of the team. So you’ll go to the teams’s slack and ask for someone to review. We recommend @ mentioning the people who’ve most recently made significant changes to the code you’re working in as they’re most likely to be the best reviewers. But by sharing the responsibility across each team, that ensures there’s no piece of code that only one person across the whole engineering organization is qualified to review. For projects within a team, there will generally be one or two dedicated reviewers and we utilize stand ups to check in and make sure no one is overloaded with reviews. And since the whole team has familiarity with the project, it’s easy to swap out a reviewer if someone is overwhelmed or on vacation.

aequitas 8y ago

"If someone has committed many crimes against the style guide in a PR, the reviewer should point them to the style guide..." Everything a computer can do trivially should not be done by humans. There are plenty of tools available to validate code to all the standards you can dream up. And most languages allow you to even automatically fix style errors or even enforce it for compilation (thank you Go). So instead of codifying it in a style guide document, codify it in config files for linting and autoformat tools instead. The defaults of those tools are often fine for what you need and exceptions can as easily be documented in them as well.

ISL 8y ago
> Everything a computer can do trivially should not be done by humans. Agreed, to a point. In many contexts, it is important for humans to do things themselves occasionally in order to learn how, even if a computer is generally used to do those things far more quickly.
- jelambs 8y ago
  Agreed, computers are generally way better than humans at catching many style issues. We utilize linters extensively, those enforce many of our style guide rules. However, there are some, such as the example pictured in the article, that aren’t always detectable with a linter. In these cases, we use the style guide as the source of truth to reduce the amount of personal preference that comes into code reviews.
  - aequitas 8y ago
    Agree, for everything that doesn't go automatically or would be to much effort to automate a single source of truth must be maintained.
- aequitas 8y ago
  I agree with that if you would be learning a language. But even then, being bothered by indenting, alignment, spacing etc gets tiresome and the small amounts of time lost accumulate over the day.

spenrose 8y ago

Based on my experience with Mozilla's mature code review culture, this article is excellent. If I were going to make one suggestion, it would be to emphasize the points that author jelambs makes below: this approach to code review is inseparable from a commitment to deep shared understanding of the code base. It both depends on and supports that understanding. It's an investment in quality as embodied in a particular technical approach and body of work. It's not cheap, but what it buys you can be very valuable.

tdsamardzhiev 8y ago

The real problem here are people with bad attitude and poor communication skills. Bullying other people is a punishable offense in real life, and I don't see why code reviews should be any different. Have some basic rules regarding communication. Issue a public warning for first-time offenders. Give them the boot if they do it again. There, problem solved.

sqrt17 8y ago
You sound like you didn't read the article. There's nothing about political correctness or try-hard inclusivity in that article but many (or indeed all) the things that common sense would dictate as a base of working code reviews.
- tdsamardzhiev 8y ago
  No, I didn't read the article. But I did read the entire comment section, if that counts :)
ergothus 8y ago
It seems overly simplistic to say that effective code reviews are inevitable if only you can prevent people from being rude. Certainly not a bad START, but I dare to think there may be additional ways a review can be a GOOD one as opposed to just not being a BAD one. It's easy to forget that we're still learning how to write "good" code, and that many of our best practices continue to evolve, occasionally into VERY different things. A Code Review has to be able to identify poor practices as distinct from UNUSUAL practices, with that latter evaluated in terms of cost-benefits and not forgotten even when the costs are too high in the current project - that may be a practice to try out where there's less impact to being inconsistent. A Code Review has to balance the subjective opinions of multiple devs to try and achieve some consensus that is treated as objective. None of this is easy nor truly figured out, and not being a jerk is just one of multiple steps to accomplish.
maerF0x0 8y ago
@tdsamardzhiev What sorts of "bullying" have you seen in code reviews before? Having some anti-pattern examples could be useful to codify into a developer guid.

wowYuck 8y ago

Yuck.

egyptiankarim 8y ago

Neat to see that they started by interviewing a diverse subset of their engineers; that type of user-centric research is invaluable. Moreover, I wonder what of their methodology could be mapped to a live analysis of the code review conversation threads they're having via GitHub. More than anything else, though, I'm curious where teams like this still go to buy those amazing Apple Cinema displays?!

brian-armstrong 8y ago

Not focusing on style violations is foolish. Imagine someone submitted an English paper littered with grammatical errors and typos. It would be difficult to find the intended meaning and bigger picture. Style violations are the same, they have to be fixed before a deeper review can even take place.

KKKKkkkk1 8y ago

How common is it to get unsolicited reviews on your PRs? In my team, I have some colleagues who will routinely pipe up when they see a PR being uploaded by an "outsider" and will write a litany of complaints in order to block progress and establish their dominance. (I should mention that these colleagues work in a branch office, so this is their only way to assert themselves.)

knocte 8y ago
> in order to block progress This is your subjective interpretation of the facts. Learn how they complain (in the end, they only can complain about technical facts: learn them, and be correct next time), and you will not receive complaints anymore. I'm guessing you're new to code reviews right?
- deleted 8y ago
  [deleted]

Confusion 8y ago

Good article, but I don't understand why the word 'inclusive' is in the title.