[carefulfungi]

As a manager, code review has two benefits that typically matter to me: (a) cost: it's cheaper to fix a defect that hasn't shipped (reading tests for missing cases is a useful review, in my experience); (b) bus-factor: make sure someone else has a passing familiarity with the code. And some ancillary (and somewhat performative benefits) like compliance: your iso-27001, soc-2 change control processes likely require a review.

It's hard, though, to keep code reviews from turning into style and architecture reviews. Code reviewing for style is subjective. (And if someone on the team regularly produces very poor quality code, code review isn't the vehicle for fixing that.) Code reviewing for architecture is expensive; settle on a design before producing production-ready code.

My $0.02 from the other side of the manager/programmer fence.

[bArray]

Out of interest, how are you using code reviews to be ISO-27001 compliant?

[carefulfungi]

ISO-27001's change management process requires that [you have and a execute a change management policy that requires that] changes are conducted as planned, that changes are evaluated for impact, and are authorized. In my experience, auditors will accept peer-review as a component of your change management procedure as a meaningful contributor to meeting these requirements.

"All changes are reviewed by a subject matter expert who verifies that the change meets the planned activity as described in the associated issue/ticket. Changes are not deployed to production environments until authorized by a subject matter expert after review. An independent reviewer evaluates changes for production impact before the change is deployed..."

If you are doing code review already, might as well leverage it here.