The key thing to me is that everyone on the team should be able to understand what the code is doing. If I am out and a team member can't read my code to troubl

The key thing to me is that everyone on the team should be able to understand what the code is doing. If I am out and a team member can't read my code to troubleshoot a critical issue, I have let my team down. If I change projects and the next programmer can't easily pick up my work, I have let my team down. Approach it from that perspective. If a "rock star" is coding above someone's head and making sweeping changes, that is a liability. The moment you feel out of your depth, that is the heart of the code review. A line-by-line reading from that point is a waste of your time. If the 22-year-old junior on my team said to me, "I tried to review your code, but I don't understand this section with the generic functions," that to me would be the value--not whether I followed our guidelines or made some minor mistake. That's an opportunity for me to improve the maintainability of my code and help my teammate improve their knowledge. You should be able to carry out your code review with this teammate in that way with confidence in my opinion. If you feel like you can't, that seems dysfunctional to me.