The value of reading code depends somewhat on the language and context. Some languages are so expressive and low friction that they read as easily as we breath

The value of reading code depends somewhat on the language and context. Some languages are so expressive and low friction that they read as easily as we breathe air. And some contexts are so well understood that we already know what is going to happen in the code, assuming there are no bugs. Therefore, I would argue that a lot of code simply doesn't need to be read. If the problem it solves is understood and documented, and various approaches to testing prove that it does what it should do, then chances are the details of how it accomplishes that goal are largely uninteresting. What is interesting to read is more organizational approaches that can be used when solving a problem. For example, at the architectural level a solution can be a monolith or some collection of coordinated pieces (services). Here, the interest is in the decisions made and how they were implemented at a conceptual level. At the code level, things only get interesting when we want to take an uncommon approach (such as functional Ruby). Then the code can illustrate tradeoffs of the approach taken, and we can learn by studying and debating it. Lastly, performance constraints can make code "odd", and that can be worth studying. The standard boring ways of solving problems may not have been possible in a given situation, so some new or complex or novel approach was taken. But even here, the magic isn't really in the code; the code just implements that solution. It's probably more valuable to understand what implementation decisions were made and why. This is not to say that doing code reviews is a waste of time; it very likely will make you a better programmer. But time could be spent at a slightly higher level and make you a much better developer/problem solver. (Unfortunately it's not often possible to read at that level since a lot of that information never gets documented!)