3 ms·
It's not about trust. It's about: * Catching errors more quickly. * Increasing the bus factor my having each bit of code read by at least two developers. * G
by microtherion 8y ago
It's not about trust. It's about:
* Catching errors more quickly.
* Increasing the bus factor my having each bit of code read by at least two developers.
* Getting everybody on the same page, both by disseminating information, and by holding each other to a consistent coding style.
- adrianmonk 8y agoTo me, the coordination thing is the biggest unexpected benefit. Sure, you can do coordination offline as an asynchronous thing. But making it a blocking part of the commit process just gives you so much higher confidence that it's going to actually happen. Though really, you're even better off if, as much as possible, you do the coordination and communication before the code review. If you have agreement on basic approach before then, you can reduce the amount of last-minute stuff to minor style changes, fixing errors, and cleanup. Code review, as a business process, tends to push things this direction. If you don't do reviews, you might skip coordination and communication. If you do reviews, you know it's happening at some point, and it only takes a few bad experiences of having to redo all your work to clue in that maybe those discussions (which you are now definitely having) should be started earlier.