3 ms·

If you think that code review is “management” then that’s very very concerning.

• swiftcoder 2y ago
  Well, it certainly isn't "development". It's a hoop we jump through so that management can tick a box labelled "all commits were reviewed by another engineer" on the SOC2 audit...
  • akerl_ 2y ago
    That’s a really weird way to view code review. Everywhere I’ve been part of development, code review is part of ensuring code quality, catching bugs, and avoiding silos.
    • swiftcoder 2y ago
      If a non-trivial percentage of your code review feedback is about code quality and bugs, you are severely underinvesting in autoformatters/linters/strong type systems/testing/continuous-integration. It's not a cost-effective use of (expensive) software engineers to have them scanning every PR on the off-chance they notice a typo. I'll grant you they can help break down silos, but the question you should be asking, is why your codebase is so convoluted that silos are developing in the first place?
    • danielvf 2y ago
      Just going to second this. Good code reviews (not just typo nitpicking) can be a great way to simplify down code, and spread knowledge horizontally across the org. Not to mention catching bugs. Unit test aren't a substitute because unit tests check that the success paths are good. That's a good start, but it's not the same as verifying all the possible ways code could go wrong in a complex system, and one of the cheapest ways to spot those problems is with people familiar with complex system looking at new code. Code review give you the double benefit of building more people who understand the whole system, and having the code looked at by people who understand the whole system.