Asking questions is often the best part of review IME, at least when the overall review culture is healthy and productive. If nothing else, it’s often a good opportunity to add clarifying comments where something isn’t obvious after it was written. And authors receptive to good review, again IME, often agree that added clarity will help those cases.
“Why did you solve it this way?” is also an excellent question in that context. Not for the big “overall approach”, where the common refrain is that design should come before implementation. But sometimes it helps surface smaller areas of complexity that only become obvious in the trenches, and it can be incredibly helpful to socialize those once discovered. (Also often prompting addition of clarifying comments.)
Asking questions is great if you're genuinely confused or need clarification. But if you have a concern, express it with the question so there is context.
> “Why did you solve it this way?”
"Because it solved the problem."
Why are you asking me this question if you have no concerns? If you have some, why aren't you sharing them with me? If you're not going to, then I will give the minimally correct answer to your question.
Conversations are a 2-way street. If you want me to spend a lot of time explaining it, then reciprocate! Anyone can ask open ended questions. It takes a lot more work to answer them than to ask. Make it worth my time to answer them!
Forcing reviewers to put an effort in the discussions also solves a lot of problems in this submission. People aren't going to waste a lot of their own time playing these kinds of games. Make the barrier high enough to prevent 90% of bad actors from acting.
This all seems very situational to me, starting with level of trust/team cohesion/etc. Like, if I’m on a team that’s functioning poorly together, I almost certainly agree with you without any further nuance.
If I’m on a team that’s functioning well, however—taking the example of “why did you solve it this way?”—I might not always know why I’m being asked, but merely being asked is often good enough for me to come up with some hypotheses. If it’s not, there’s a good chance it’s a learning opportunity: maybe something is missing from my toolbelt, or perhaps some unintended consequence escaped my notice. Being prompted to think about those possibilities without bias may help me learn (or reinforce what I’ll learn) by putting me in a position to retrace my steps and look for other gaps in my understanding.
I say all this also acknowledging that I tend to put a lot more effort into review, and communication in a review context, than many of my peers have throughout my career. And sometimes my tendency to over communicate has had the opposite effect from what I intended.
In any case, I am definitely more inclined toward your position in context of other communication challenges!
> I might not always know why I’m being asked, but merely being asked is often good enough for me to come up with some hypotheses. If it’s not, there’s a good chance it’s a learning opportunity: maybe something is missing from my toolbelt, or perhaps some unintended consequence escaped my notice. Being prompted to think about those possibilities without bias may help me learn (or reinforce what I’ll learn) by putting me in a position to retrace my steps and look for other gaps in my understanding.
I'm not at all disagreeing that these things may happen, with emphasis on may. It can all be achieved by the code reviewer saying "Interesting approach. You could have solved it via X instead, which has these extra benefits. Was there a reason you picked Y over X?"
This is a 2-way conversation. In your paragraph above, you're not giving serious enough consideration that it may really be the reviewer who needs to learn something new, and therefore the conversation should reflect that symmetry.
I've often seen (yes, in low functioning teams), the following pattern:
Reviewer: Why did you solve the problem this way (X)?
Me: Because of (outline a simple reason).
Reviewer: But why not Y?
Me: Why Y?
Reviewer: (50% of the time does not give a good answer and merely insists Y is better because of some random article on the Internet).
Note that:
1. The reviewer can't articulate why his method is superior.
2. The developer had to put in a lot more effort in this exchange than the reviewer.
In a better functioning team, it goes like:
Reviewer: Why did you solve the problem this way (X)?
Me: It worked. Why do you ask?
Reviewer: Oh, I thought X would be better. (If I'm lucky he'll explain why).
Me: OK. Moving on...?
Reviewer: (Moves on or sticks to the topic but gives more context).
Both of these are "poor" interactions, compared to the reviewer simply stating up front what his concerns are.
“Why did you solve it this way?” is also an excellent question in that context. Not for the big “overall approach”, where the common refrain is that design should come before implementation. But sometimes it helps surface smaller areas of complexity that only become obvious in the trenches, and it can be incredibly helpful to socialize those once discovered. (Also often prompting addition of clarifying comments.)