It's an important point you bring up about making the review-experience as comfortable as possible for the person receiving the feedback as well.
Personally I've found that people vary greatly on the type of feedback they want:
some people find "Navigation-Style" feedback too vague and un-actionable
they'll say things like "just let me know what you're thinking directly"
others, like you pointed out, find too detailed comments as wresting control from them.
So yea, I'd add the following recommendations:
have a conversation with your reviewee about your review style and set expectations
try and foster a broader culture of psychological safety around code-reviews so that people are willing to engage
for example, if reviews are an after-thought at the end then people will naturally just want to rush through it
if possible, try pair-programming instead; the navigator / driver paradigm is most purely expressed here and the code that comes out in the end is 90% reviewed anyway.
100% agree with your thoughts on this. I espeically agree with 1 and 3. Having a team understood expectation about what happens during a code review can solve (or at least help solve) a lot of the problems in the review process. Same goes for pairing (which our team does currently).
I certianly can't write about every aspect of good reviews or team culture in one article, so I'm glad you added these comments.
Big +1 for pair programming. The quality of the code that came from the pair-programming team I worked with was higher than any other team I've been on.
It isn't just about another pair of eyes to catch mistakes; it's about the fact that two heads are nearly always better than one, and the code/solutions that came from pairs were typically more sound/robust than code/solutions from solo devs.
yea I love the idea of pairing, and haven't gotten to do it as much as I'd like; mostly people feel uncomfortable initially to have someone else look over their thinking-process and would rather work alone and struggle through things instead. 😅
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
It's an important point you bring up about making the review-experience as comfortable as possible for the person receiving the feedback as well.
Personally I've found that people vary greatly on the type of feedback they want:
So yea, I'd add the following recommendations:
Hey Joel! Thanks for reading.
100% agree with your thoughts on this. I espeically agree with 1 and 3. Having a team understood expectation about what happens during a code review can solve (or at least help solve) a lot of the problems in the review process. Same goes for pairing (which our team does currently).
I certianly can't write about every aspect of good reviews or team culture in one article, so I'm glad you added these comments.
certainly a herculean task, but thank you for sharing your thoughts and starting this conversation. ❤️
Big +1 for pair programming. The quality of the code that came from the pair-programming team I worked with was higher than any other team I've been on.
It isn't just about another pair of eyes to catch mistakes; it's about the fact that two heads are nearly always better than one, and the code/solutions that came from pairs were typically more sound/robust than code/solutions from solo devs.
yea I love the idea of pairing, and haven't gotten to do it as much as I'd like; mostly people feel uncomfortable initially to have someone else look over their thinking-process and would rather work alone and struggle through things instead. 😅