DEV Community

loading...

Discussion on: I'm Changing How I Review Code

Collapse
jlouzado profile image
Joel Louzado

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:

  1. have a conversation with your reviewee about your review style and set expectations
  2. 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
  3. 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.
Collapse
dangoslen profile image
Dan Goslen Author

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.

Collapse
jlouzado profile image
Joel Louzado

I certianly can't write about every aspect of good reviews or team culture in one article

certainly a herculean task, but thank you for sharing your thoughts and starting this conversation. ❤️

Collapse
squidbe profile image
squidbe

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.

Collapse
jlouzado profile image
Joel Louzado

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