In my experience there is a scale of how thorough the review can be. The scale is continuous, but most reviews fall into one of three buckets: informational "he

In my experience there is a scale of how thorough the review can be. The scale is continuous, but most reviews fall into one of three buckets: informational "hey this is what I am doing", light guidance "hey can you check out broad outlines without getting bogged down in details", and coauthors aka "one person writes the code, but all are responsible for the outcome". Generally the bucket review falls in depends on code criticality, code simplicity, company culture, how much reviewer cares about the code you are changing, how much reviewer cares about you/your changes (mentorship etc.), and how tired / overwhelmed the reviewer is. It follows, that assigning reviewers that care about the code/author and not reviewing code while tired tends to produce higher quality reviews. In the end author, reviewer, and thoroughness of the review is an engineering call. Both author and reviewers should be able to understand where they are on the scale and be able to substantiate why.