+1 to "Ask Questions". Not only from the perspective of giving the author a chance to explain why they chose the path they took, but also from the perspective of a reviewer trying to learn, as well as a mechanism for prompting discussion.
I've learned a ton asking questions in PR (ex: "oh, so you can define a nested class in this language?", etc), but I've also used it with great effect to guide a more junior dev to realize ways they could improve their code and understand the "why" of one approach to solving a problem being better than another (ex: "so if we had to change this value here, what else would have to change?" or "if this value was null here, what would happen in the subsequent lines that follow?", etc) Ie "ask don't tell" can be an effective review technique for avoiding putting the author on the defensive.
+1 to "Ask Questions". Not only from the perspective of giving the author a chance to explain why they chose the path they took, but also from the perspective of a reviewer trying to learn, as well as a mechanism for prompting discussion.
I've learned a ton asking questions in PR (ex: "oh, so you can define a nested class in this language?", etc), but I've also used it with great effect to guide a more junior dev to realize ways they could improve their code and understand the "why" of one approach to solving a problem being better than another (ex: "so if we had to change this value here, what else would have to change?" or "if this value was null here, what would happen in the subsequent lines that follow?", etc) Ie "ask don't tell" can be an effective review technique for avoiding putting the author on the defensive.
I actually do that a lot when I am teaching in person but I never thought about doing it on a PR! Good call!