I think the author is talking about a 'Forced Code review' because it is supposedly a good practice to have a code review before you put something into producti

I think the author is talking about a 'Forced Code review' because it is supposedly a good practice to have a code review before you put something into production (which it is). The current practice is a coder submitting the entire code for review, and getting comments on every aspect that the reviewer feels like. This is not an efficient process as it takes up a lot of time, but reviewer also put in a position as to 'How would he solve the problem the current code has already solved' I feel a good code review process should have two components: 1/ Self-review. A team/company should agree on baselines/conventions that any code shipped by them should have, and ensure that any code not corresponding to that will be rejected. This review should be done by developer himself, rather than a reviewer. 2/ A code review by an experienced dev who needs to check for libraries/custom functions that are used might not break something somewhere else, or wont work because some other change is going somewhere else, that they know of. This way, potentially buggy code can be avoided, and process could be faster as well. Ofcourse, if they want to provide feedback on a better algo, they can, but should be optional