4 ms·

I'm not really convinced. Code reviews are a great opportunity for learning, improve and share knowledge. Are extremely useful for onboarding new members on a p

I'm not really convinced. Code reviews are a great opportunity for learning, improve and share knowledge. Are extremely useful for onboarding new members on a project. You can learn a lot seeing others code, asking questions in place or receiving suggestions. Sadly a lot of teams and companies see that as a performance metric (how measuring patches/commit measures how good somebody is programming?) or as a process that must be passed asap.

varjag 5y ago
What if most of the team are already competent, experienced programmers? Sure there's always something to learn but perhaps not as much on a routine code review. > Are extremely useful for onboarding new members on a project. You can learn a lot seeing others code, asking questions in place or receiving suggestions. I expect utility of code review by a newbie/newcomer to the project to hover slightly over zero. Perhaps it's best to dedicate some time to proper onboarding instead.
- SpaghettiX 5y ago
  I would think that GP meant review of the new joiners code, not the new joiner reviewing other peoples code. But even a new joiner reviewing existing code can be beneficial (to the new joiner definitely). A way to learn how to code well is to read (good) code.
- NikolaeVarius 5y ago
  I'm always amazed by the arrogance of some coders. Experience and competent does not mean perfect.
  - varjag 5y ago
    Code review also does not mean perfect; in fact noone here has said anything about perfection.
- makoz 5y ago
  If the code review is routine, the approval will be quick and straight forward. There's barely any friction in my experience. I'd like to believe I'm competent, doesn't mean I'm infallible. You can dedicate time to onboarding, doesn't mean it's realistic that they're going to ramp up on all code areas during that time. > I expect utility of code review by a newbie/newcomer to the project to hover slightly over zero. Perhaps it's best to dedicate some time to proper onboarding instead. I disagree. If the commit isn't understandable to people, including junior engineers, I think it's problematic. I want to write code that is maintainable and not have to worry about deciphering my reasoning was for certain decisions down the line. If it's not clear to junior engineers, chances are it might not be clear to me, or someone else 3 years later. Something that makes sense to me at the moment because I have context, might not be clear to others. Reviews are a great way to call that out.
NortySpock 5y ago
My current team has very few code reviews, and recently we discovered we can recover a fair amount of missing learning opportunities with weekly or every-two-weeks having an (optional) 1 hour knowledge sharing session. It's sort of a cross between a lightning talk, a "greatest hits of last week" session, or a demo. "Last month I worked on X, and I had to do this hacky workaround. Here's why, here's how, here's the result, here's what you need to know if you need to work in this code soon. Questions? No? Bob, you're up next with your work on Z..."
CipherThrowaway 5y ago
When OP's approach is implemented effectively code review does not disappear but becomes more of a continuous process. Developers review each others changes and become proactive about seeking review of their own code. Teams that take this approach will typically review all code changes between releases before code makes it into production.

varjag 5y ago

What if most of the team are already competent, experienced programmers? Sure there's always something to learn but perhaps not as much on a routine code review. > Are extremely useful for onboarding new members on a project. You can learn a lot seeing others code, asking questions in place or receiving suggestions. I expect utility of code review by a newbie/newcomer to the project to hover slightly over zero. Perhaps it's best to dedicate some time to proper onboarding instead.

SpaghettiX 5y ago
I would think that GP meant review of the new joiners code, not the new joiner reviewing other peoples code. But even a new joiner reviewing existing code can be beneficial (to the new joiner definitely). A way to learn how to code well is to read (good) code.
NikolaeVarius 5y ago
I'm always amazed by the arrogance of some coders. Experience and competent does not mean perfect.
- varjag 5y ago
  Code review also does not mean perfect; in fact noone here has said anything about perfection.
makoz 5y ago
If the code review is routine, the approval will be quick and straight forward. There's barely any friction in my experience. I'd like to believe I'm competent, doesn't mean I'm infallible. You can dedicate time to onboarding, doesn't mean it's realistic that they're going to ramp up on all code areas during that time. > I expect utility of code review by a newbie/newcomer to the project to hover slightly over zero. Perhaps it's best to dedicate some time to proper onboarding instead. I disagree. If the commit isn't understandable to people, including junior engineers, I think it's problematic. I want to write code that is maintainable and not have to worry about deciphering my reasoning was for certain decisions down the line. If it's not clear to junior engineers, chances are it might not be clear to me, or someone else 3 years later. Something that makes sense to me at the moment because I have context, might not be clear to others. Reviews are a great way to call that out.

NortySpock 5y ago

My current team has very few code reviews, and recently we discovered we can recover a fair amount of missing learning opportunities with weekly or every-two-weeks having an (optional) 1 hour knowledge sharing session. It's sort of a cross between a lightning talk, a "greatest hits of last week" session, or a demo. "Last month I worked on X, and I had to do this hacky workaround. Here's why, here's how, here's the result, here's what you need to know if you need to work in this code soon. Questions? No? Bob, you're up next with your work on Z..."

CipherThrowaway 5y ago

When OP's approach is implemented effectively code review does not disappear but becomes more of a continuous process. Developers review each others changes and become proactive about seeking review of their own code. Teams that take this approach will typically review all code changes between releases before code makes it into production.