Great talk that I thought would benefit the DEV community.
Main Argument
“I love code reviews in theory. In practice, they are only as good as the group that's responsible for conducting them in the right manner.”
This quote, eloquently sums up how many of us feel about code reviews.The major thing I took away from this talk, is that to have better code reviews we need to proactively build a healthier developer culture/behaviors around them.
According to Vaidehi the largest factors that contribute to better code reviews are social. Reviewing everyone pushes for a culture that values vulnerability. It's important for other developers to see that even senior developers can make mistakes and that it's ok. She advises us to develop empathy by also highlighting what was done well. Also, code reviews don't have to be rooted in negatives, but instead in shared ownership and responsibility of what we’re building together. And finally, that we need to initiate more conversations about code reviews, whether you feel your team code review process isn't where it needs to be or about what's working (if you're proud of it).
Let’s Discuss
How do you currently practice code reviews? What does this version do well or what could it do better?
Top comments (2)
We have a Jira workflow Open - In Progress - To Be Reviewd - In Review - Done. That means every subtask of a story must be reviewed by a second team member. As you've mentioned, during review positive things should be highlighted. Negative things should be expressed as "thst could be improved like that" but leaving it open to the implementer to actually do it because most often there is more than one way to do it and there is no wrong. If we're doing pair programming, we skip task based reviews. Juniors review code of seniors and the other way around. Next to TDD, this improved quality a lot and reduced bugs to a minimum.
Similar Jira workflow here, just add "in test", "tested" states if you have dedicated test / QA team ;)