3 ms·

Is this person working on his own. Why can't people pair and give each other at the moment feedback vs doing code review. Person is already invested in his cod

Is this person working on his own. Why can't people pair and give each other at the moment feedback vs doing code review. Person is already invested in his code by PR review time and doesn't really want to do PR ping pong for their task. What if you come back with more comments after they address your comments. Will they ever get to finish their task or forever be hostage to you subjective comments. Most of it is usually subjective too. you had to explicitly mention 'security issues' which imply that you have a feeling that most of your pr comments were your subjective interpretation . People are more open to suggestions during pair programming because people don't deliver feedback in cutting way ( with or without coffee) and its easy for get a common understanding and move forward.

withinboredom 4y ago
> Why can't people pair and give each other at the moment feedback vs doing code review. That was something we discussed at various points. We never tried it when I worked there. > you had to explicitly mention 'security issues' which imply that you have a feeling that most of your pr comments were your subjective interpretation . Aren't almost all code review comments? I can't think of a single one except ones that point out literal bugs. Most are "do it this way because I think it will be more maintainable" or "do it this way because that is how we do it here." In this case, I mentioned "security issues" because they were literal bugs that introduced new attack surfaces that didn't previously exist. When I read comments on my code, I make sure to read it without any inflection. Some people have really bizarre code review styles, and some are totally straightforward. Some people are lenient on whether or not there actually needs to be a change, while some people will not accept code until changes are made, no matter how little the change request is. Knowing your reviewer is about as important as how you review code, which is why I suggested being consistent. If you're always straightforward, and then suddenly not, the reviewee is going to wonder if something is going on. Vice-versa, if you're suddenly straightforward, people are going to be offended or feel like you are taking something out on them. In my case, reviewing code within 3 minutes of waking up was a terrible idea and I have never done it since because I'm "grumpy-mc-grumpy-pants" for at least 10-15 minutes after waking up and having some coffee. I feel like a lot of the conversation in this thread is about how to review code, but the relationship between the reviewee and the reviewer is more important than any of that and how you review code will affect that relationship whether you want it to or not.
- dominotw 4y ago
  > but the relationship between the reviewee and the reviewer is more important than any of that and how you review code will affect that relationship whether you want it to or not. yes I agree with this 100%. I've gotten nasty reviews from people i like and it didn't bother me at all.

withinboredom 4y ago

> Why can't people pair and give each other at the moment feedback vs doing code review. That was something we discussed at various points. We never tried it when I worked there. > you had to explicitly mention 'security issues' which imply that you have a feeling that most of your pr comments were your subjective interpretation . Aren't almost all code review comments? I can't think of a single one except ones that point out literal bugs. Most are "do it this way because I think it will be more maintainable" or "do it this way because that is how we do it here." In this case, I mentioned "security issues" because they were literal bugs that introduced new attack surfaces that didn't previously exist. When I read comments on my code, I make sure to read it without any inflection. Some people have really bizarre code review styles, and some are totally straightforward. Some people are lenient on whether or not there actually needs to be a change, while some people will not accept code until changes are made, no matter how little the change request is. Knowing your reviewer is about as important as how you review code, which is why I suggested being consistent. If you're always straightforward, and then suddenly not, the reviewee is going to wonder if something is going on. Vice-versa, if you're suddenly straightforward, people are going to be offended or feel like you are taking something out on them. In my case, reviewing code within 3 minutes of waking up was a terrible idea and I have never done it since because I'm "grumpy-mc-grumpy-pants" for at least 10-15 minutes after waking up and having some coffee. I feel like a lot of the conversation in this thread is about how to review code, but the relationship between the reviewee and the reviewer is more important than any of that and how you review code will affect that relationship whether you want it to or not.

dominotw 4y ago
> but the relationship between the reviewee and the reviewer is more important than any of that and how you review code will affect that relationship whether you want it to or not. yes I agree with this 100%. I've gotten nasty reviews from people i like and it didn't bother me at all.