I used to love code reviews when I worked for Motorola in 2004, it was doing wonders, we observed showing up "phantom developer" where mix of inputs from different people was causing new look on code. Those were Fagan-like code inspections. A lot of paperwork (we were doing formal reviews on paper, with one person in role of reader), but it was working. This whole paperwork was forcing people to follow rules and it seemed to work (but was sometimes very painful). Latter in other companies I found out that code reviews are in most cases bullshit placeholders, and in many cases are only for making some developers feeling more important, or other devs not loosing contact with code. I saw most stupid things in code moved to position of examples how to write code only because of code reviews... Good code reviews are doing wonders, but as I can see without very strong culture in dev teams and whole company those code reviews don't add anything useful. And this strong culture is difficult. From observations it seems that this is easier to build in team culture to work with "master/main only" without branches and code reviews, than to build culture of code reviews which are working. From my observations most of comments in code reviews are variations on "I would code it in different way", or "why you are doing it in this way/I don't like your variable name" of course usually written in less direct way. Last year problems with Log4J2 showed that even in OpenSource peer reviews don't help. Good developers let to introduce to one of most used libraries something what never should be introduced there. For sure variable names were nice, but somehow whole "why we are adding this" was lost, because devs were looking only for some easy to spot things. So.... yep, good code reviews are important, but my guess is that most of code reviews are only to make some devs happier that they still know what happens in code, and that variables are named in acceptable by them ways....