5 ms·

I was really hoping for more advice on letting the team members appreciate code reviews, and not take it too personally. We've just recently introduced code re

I was really hoping for more advice on letting the team members appreciate code reviews, and not take it too personally. We've just recently introduced code reviews on our 3-4 person team. We're working in a particular environment, and most people have no production level experience in that environment. These people have gotten used to _just getting it to work_. We've clearly stated that we will be going with Google's style guide, but we can always divert, as long as everyone is in agreement. When pointing out that the changes are not according to the style agreed (frankly, it's not so much about style, as it is about using patterns from other programming languages, that are not applicable), the response is: - it works - I don't think you understood what this does (note: no comments or attempt to explain) - In the future, please do not waste more time with pull requests. Desktop sharing and a call is the most efficient way to work in remote teams. It's getting more and more hard to keep an open mind and not take things personally. We're at a point now, where there's a intermediary person refactoring the code. Does anyone have any practical advice on people understand the importance of structure code, and to limit the _personal factor_?

fourneau 10y ago
As for people taking things too personally (you or otherwise): talk to your team members. Let them know that you perceive their comments as harsh. If you can't come to a consensus about tone, content and voice, then code reviews will always be a friction point between you and your team. Work it out with them, they're all just people with emotions too, after all. As for the appreciation of code reviews: developers absolutely hate doing things without reason. For what reason does your team do code reviews in the first place? Is that reason unanimously understood? If not, then you'll face a lot of resistance. In short, get everyone on the same page as to /why/ you want to use this tool (code reviews) and on the same page as to /how/ to use it. -- also general code review advice: - Don't make it all about style, and if you do, preface that you're nitpicking. automate everything you can when it comes to style. - Use unambiguous questions, with detail. Set a high bar of quality for reviews by leading the charge yourself and holding others to that standard. Don't be afraid to preface questions with: "I don't think I understand how this works." - Don't be afraid to applaud really cool things as well. Code reviews don't have to be negative comments only.
- rak00n 10y ago
  These are good advice. In a lot of companies you cannot submit a code without an approval from the reviewer. That puts the reviewer in a high ground when it comes to asking for explanation.
nsfyn55 10y ago
>Does anyone have any practical advice on people understand the importance of structure code, and to limit the _personal factor_? I'd take a step back. When people "don' t understand the importance of ...." the issue is almost always a breakdown of bi-directional communication. I like to start by assuming the person offering resistance has a valid point. Start by telling them they are right. If their approach is causing a problem then describe the problem in objective terms. Present your analysis to the resistance leader and ask for their help in solving it. When you do this the person offering resistance can often become your biggest advocate. Recently I have become a convert of the retrospective with a focus on incremental improvements. Start with the process you have and commit to making it better with 1-3 concrete action items per cycle. It can be surprising where you land.

fourneau 10y ago

As for people taking things too personally (you or otherwise): talk to your team members. Let them know that you perceive their comments as harsh. If you can't come to a consensus about tone, content and voice, then code reviews will always be a friction point between you and your team. Work it out with them, they're all just people with emotions too, after all. As for the appreciation of code reviews: developers absolutely hate doing things without reason. For what reason does your team do code reviews in the first place? Is that reason unanimously understood? If not, then you'll face a lot of resistance. In short, get everyone on the same page as to /why/ you want to use this tool (code reviews) and on the same page as to /how/ to use it. -- also general code review advice: - Don't make it all about style, and if you do, preface that you're nitpicking. automate everything you can when it comes to style. - Use unambiguous questions, with detail. Set a high bar of quality for reviews by leading the charge yourself and holding others to that standard. Don't be afraid to preface questions with: "I don't think I understand how this works." - Don't be afraid to applaud really cool things as well. Code reviews don't have to be negative comments only.

rak00n 10y ago
These are good advice. In a lot of companies you cannot submit a code without an approval from the reviewer. That puts the reviewer in a high ground when it comes to asking for explanation.

nsfyn55 10y ago

>Does anyone have any practical advice on people understand the importance of structure code, and to limit the _personal factor_? I'd take a step back. When people "don' t understand the importance of ...." the issue is almost always a breakdown of bi-directional communication. I like to start by assuming the person offering resistance has a valid point. Start by telling them they are right. If their approach is causing a problem then describe the problem in objective terms. Present your analysis to the resistance leader and ask for their help in solving it. When you do this the person offering resistance can often become your biggest advocate. Recently I have become a convert of the retrospective with a focus on incremental improvements. Start with the process you have and commit to making it better with 1-3 concrete action items per cycle. It can be surprising where you land.