This is a very timely article because I foresee us possibly adopting code reviews soon. At this point we've never had a formal code review process. In fairness to my employer, I've never worked anywhere that had a formal code review process. We're going to a Git based code repository system and each such system I've encountered all have a pull request paradigm built in. I'm both looking forward to it and dreading it at the same time. Your description of how you'd pick someone to review your code made me realize that I'd do the same approach for the same reasons. I'm eager for the chance to learn from others. But I've got more reservations about adopting code reviewing.
The first concern is that only a few people will be stuck reviewing code. One bad habit I've seen around here is people quickly identifying something you do, normally the last thing you did, and then they only assign you the same tasks over and over again. We recently had a training with a Microsoft Developer Advocate on branching and merging Git repos, who insisted that it is best to share the responsibility around everyone, so everyone gets a feel for the whole code base, rather than the portion they work on. This is something I'll push for.
The second concern I have is how do you avoid not being judgmental about the code you review. I know myself, I can be judgmental. And I don't really have an answer to how to review code in a psychologically safe manner.
I'm hoping we adopt code reviews and learn how to do them reasonably well.
Kindest Regards, Rod Connect with me on LinkedIn.