4 ms·

A developer is new, and early on we want code reviews A developer is working on a big (or risky) feature, and wants a one-off code review This implies you d

A developer is new, and early on we want code reviews A developer is working on a big (or risky) feature, and wants a one-off code review This implies you don't normally do code review??

sklivvz1971 11y ago
Yes, we don't normally code review stuff we don't need to. We trust each other.
- scottaj2 11y ago
  I don't think doing code reviews implies a lack of trust. I trust everyone on my team but we code review everything. For that matter, the fact that we trust/have good relationships with everyone makes code reviews more effective because we can be more candid. We often find issues in code reviews like edge cases that weren't thought of, code that could be refactored to use an existing utility or patter the author wasn't aware of, etc.
  - gnaritas 11y ago
    Not a bad practice, but costly in dev time and a trade off many aren't willing to make especially in smaller companies where mistakes aren't as costly as all that extra developer time. Personally I do code reviews mostly to share knowledge and culture rather than looking for bugs. Occasionally a bug is found, but I don't generally have the time to review the logic, just the style.
  - numo16 11y ago
    I work for a company that averages around 50 production deployments per day for our customer-facing ERP, and we only do code reviews for new devs and changes to underlying framework changes for mostly the same reason sklivvz1971 mentions. We rollback very infrequently and a majority of our devs can deploy to prod with the push of a button as needed (this includes both application and database code). Not arguing that code review is unnecessary, just feel that with proper training and having devs with good judgement can help reduce the likely hood of breaking things when deploying small changes frequently.
    - scottaj2 11y ago
      We rarely catch things breaking in code reviews, I agree they are really bad at finding bugs. Automated tests and linters are better at finding stuff like that. The things we usually address in code reviews are architecture and code design issues, and occasionally edge and interaction issues that are outside the scope of what might have been considered when implementing. We also have frequent production deployments that everyone on the team can do, I view that as something that is independent of code review.
  - sklivvz1971 11y ago
    Don't get me wrong, we review code. We simply don't review commits. Reviewing absolutely every commit would feel like a waste of our time and an efficiency issue. I can see where it could be useful, but in our case it's simply a solution to a problem we don't have. We can definitely live with a bug in production for 5 minutes. As a commenter below notes, there are always two pilots in an airplane -- and that is pretty much also a trust issue -- but we don't pilot planes, we don't have actual lives depending on us.
- jacques_chester 11y ago
  The captain trusts the co-pilot on airliner. There are still two people flying a plane.
  - skeletonjelly 11y ago
    Don't forget the role who does most of the work, the autopilot :)
darkhorn 11y ago
Well, it is not an enterprice applucation. It is free web site. Yeah, not a very good practice but not very critical too.
- aalear 11y ago
  I dunno that I'd say an enterprise app is inherently more valuable than Stack Overflow. ;) But to be clear - it's not that we never do reviews. It's more that we have an "ask for it when you need it" type of policy. New hires get regular reviews, so initial architecture/style concerns are addressed then... along with teaching the logistics of our code reviews (push to a branch & submit a merge request).
manigandham 11y ago
Code review is overrated. Over my career I've built 8/9 figure revenue platforms without code review or serious test setups. A lot of this cruft is unnecessary when compared to good domain knowledge and solid coding focus.
- ohitsdom 11y ago
  > Over my career I've built 8/9 figure revenue platforms without code review or serious test setups. This does not diminish code reviews. Would you be a better engineer today if you had regularly participated in code reviews? Would your coworkers?
  - ralmeida 11y ago
    I believe s/he would, and likely knows it. They just said it was overrated, not useless. They just draw the tradeoff line differently.
  - meddlepal 11y ago
    One of the problems with code reviews is they're often done really poorly, for a number of reasons: 1. Reviewers are often poorly trained to provide good design reviews and default to nit-picky stuff a code linter should pickup. Human linting is just a poor use of time and money. 2. Nobody seems to ever have time for them to deep dive into the code. 3. Few engineers seem to ever actually want to do them. 4. Reviews can become hostile. Code reviews are probably really important in some fields, for example, medical equipment, aviation, etc, but for the vast number of projects where we're shoveling A bits to B bucket or transforming C bits into D bits it's overkill and companies would be better off investing the massive amount of wasted time in better CI/CD infrastructure.
  - manigandham 11y ago
    > Would you be a better engineer today if you had regularly participated in code reviews? Would your coworkers? Maybe, but probably not. It's not like I never see someone's code, it's right there when I'm working in the same code base and I can go through commits to see the high-level changes. There are lots of ways to become a better engineer and code reviews are pretty far down on the list in my view. They usually just turn into tedious ordeals that burn up actual productive time.

A developer is new, and early on we want code reviews A developer is working on a big (or risky) feature, and wants a one-off code review This implies you don't normally do code review??

sklivvz1971 11y ago

Yes, we don't normally code review stuff we don't need to. We trust each other.

scottaj2 11y ago
I don't think doing code reviews implies a lack of trust. I trust everyone on my team but we code review everything. For that matter, the fact that we trust/have good relationships with everyone makes code reviews more effective because we can be more candid. We often find issues in code reviews like edge cases that weren't thought of, code that could be refactored to use an existing utility or patter the author wasn't aware of, etc.
- gnaritas 11y ago
  Not a bad practice, but costly in dev time and a trade off many aren't willing to make especially in smaller companies where mistakes aren't as costly as all that extra developer time. Personally I do code reviews mostly to share knowledge and culture rather than looking for bugs. Occasionally a bug is found, but I don't generally have the time to review the logic, just the style.
- numo16 11y ago
  I work for a company that averages around 50 production deployments per day for our customer-facing ERP, and we only do code reviews for new devs and changes to underlying framework changes for mostly the same reason sklivvz1971 mentions. We rollback very infrequently and a majority of our devs can deploy to prod with the push of a button as needed (this includes both application and database code). Not arguing that code review is unnecessary, just feel that with proper training and having devs with good judgement can help reduce the likely hood of breaking things when deploying small changes frequently.
  - scottaj2 11y ago
    We rarely catch things breaking in code reviews, I agree they are really bad at finding bugs. Automated tests and linters are better at finding stuff like that. The things we usually address in code reviews are architecture and code design issues, and occasionally edge and interaction issues that are outside the scope of what might have been considered when implementing. We also have frequent production deployments that everyone on the team can do, I view that as something that is independent of code review.
- sklivvz1971 11y ago
  Don't get me wrong, we review code. We simply don't review commits. Reviewing absolutely every commit would feel like a waste of our time and an efficiency issue. I can see where it could be useful, but in our case it's simply a solution to a problem we don't have. We can definitely live with a bug in production for 5 minutes. As a commenter below notes, there are always two pilots in an airplane -- and that is pretty much also a trust issue -- but we don't pilot planes, we don't have actual lives depending on us.
jacques_chester 11y ago
The captain trusts the co-pilot on airliner. There are still two people flying a plane.
- skeletonjelly 11y ago
  Don't forget the role who does most of the work, the autopilot :)

darkhorn 11y ago

Well, it is not an enterprice applucation. It is free web site. Yeah, not a very good practice but not very critical too.

aalear 11y ago
I dunno that I'd say an enterprise app is inherently more valuable than Stack Overflow. ;) But to be clear - it's not that we never do reviews. It's more that we have an "ask for it when you need it" type of policy. New hires get regular reviews, so initial architecture/style concerns are addressed then... along with teaching the logistics of our code reviews (push to a branch & submit a merge request).

manigandham 11y ago

Code review is overrated. Over my career I've built 8/9 figure revenue platforms without code review or serious test setups. A lot of this cruft is unnecessary when compared to good domain knowledge and solid coding focus.

ohitsdom 11y ago
> Over my career I've built 8/9 figure revenue platforms without code review or serious test setups. This does not diminish code reviews. Would you be a better engineer today if you had regularly participated in code reviews? Would your coworkers?
- ralmeida 11y ago
  I believe s/he would, and likely knows it. They just said it was overrated, not useless. They just draw the tradeoff line differently.
- meddlepal 11y ago
  One of the problems with code reviews is they're often done really poorly, for a number of reasons: 1. Reviewers are often poorly trained to provide good design reviews and default to nit-picky stuff a code linter should pickup. Human linting is just a poor use of time and money. 2. Nobody seems to ever have time for them to deep dive into the code. 3. Few engineers seem to ever actually want to do them. 4. Reviews can become hostile. Code reviews are probably really important in some fields, for example, medical equipment, aviation, etc, but for the vast number of projects where we're shoveling A bits to B bucket or transforming C bits into D bits it's overkill and companies would be better off investing the massive amount of wasted time in better CI/CD infrastructure.
- manigandham 11y ago
  > Would you be a better engineer today if you had regularly participated in code reviews? Would your coworkers? Maybe, but probably not. It's not like I never see someone's code, it's right there when I'm working in the same code base and I can go through commits to see the high-level changes. There are lots of ways to become a better engineer and code reviews are pretty far down on the list in my view. They usually just turn into tedious ordeals that burn up actual productive time.