> 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.
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.