--- title: "What should a good code review look and feel like?" url: "https://www.5whys.com/articles/what-should-a-good-code-review-look-and-feel-like.md" canonical: "https://www.5whys.com/articles/what-should-a-good-code-review-look-and-feel-like.html" published: "2012-05-02T11:06:56+00:00" updated: "2014-05-22T21:51:06.277000+00:00" tags: ["First Steps during chaos", "Growing People", "Learning Phase"] author: "Roy Osherove" description: "The way I see code reviews, is that they are a great cover for learning, mentoring _and_ finding interesting quality issues in your code. If our main goal as leaders is to grow our teams, then code reviews are a great way to grow team…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # What should a good code review look and feel like? The way I see code reviews, is that they are a great cover for learning, mentoring \_and\_ finding interesting quality issues in your code. If our main goal as leaders is to grow our teams, then code reviews are a great way to grow team members, by helping them gain many skills: how to mentor others, how to communicate better, Not being shy about asking questions, stopping hoarding knowledge and much more. You should leave a code review either feeling like you've learned something new, or that you've shared something new, or that you've caught something stupid, or too smart, and you're more proud of the codebase. To achieve all these great benefits there are some important points you can't neglect: - **To increase learning on many levels from each other**, code reviews are always between at least two people (sometimes a third person can join in to learn how to review), sitting side by side. Not in different work stations, not in different offices and not in different buildings. Those learnings can be as simple as "how did you do that with the keyboard?" to "why would you even do that?" to "I didn't even imagine that's something you could do" - **To increase code quality and remove the chance of forgetting to implement them**, code review comments are taken care of either \_during\_ or right after the code review has ended - **To increase focus and energy**, code reviews should be short. 30 min. is almost too long. 5-15 min. is good. To do that you'll need to make sure that code reviews cover smaller parts of the codebase. One way to achieve that is by _reviewing on every check-in_, so that the batches to review are smaller. - **To increase overall team proficiency and share knowledge**, code reviews are done by all members of the team to all other members. At least, that's the long term goal (within 2 months it's possible to achieve for a team of 10). If you want to get started with code reviews, and read how I'd recommend teaching everyone to review each other's code, [I expand on those things here.](https://www.5whys.com/articles/step-4-start-doing-code-reviews-seriously.html) What about all those code review tools out there? I don't use them and never have. If you use them, you're missing out on the most important part of code reviews, the interaction with other people to learn and teach something. Remove that interaction, and you're left with a dead, boring feeling of having to look through someone else's list of boring things they think you got wrong. Who has time for that? --- ## About the author **Roy Osherove**: Senior Solutions Architect at AWS working on AI for production and AI-driven development; author of The Art of Unit Testing and Elastic Leadership, with about 20 years of consulting and training on unit testing, TDD, team leadership and continuous delivery. ### Sites - [RobotPaper](https://robotpaper.ai/): This blog: AI patterns and anti-patterns, AI and coding agents, and engineering leadership. - [osherove.com](https://osherove.com): Roy's personal site. Author of The Art of Unit Testing and Elastic Leadership; consulting and training on unit testing, TDD, team leadership and continuous delivery, plus about 20 years of blog posts. - [The Art of Unit Testing](https://www.artofunittesting.com): The Art of Unit Testing, 3rd Edition (Manning): readable, maintainable, trustworthy unit tests, plus TDD workshops in C#, JavaScript, Java and Kotlin. - [5whys.com](https://www.5whys.com): Roy's writing on software team leadership: self-organizing teams, surviving chaos, learning mode and the Elastic Leadership model. - [Pipeline Driven](https://pipelinedriven.org): Continuous delivery and DevOps practices: build patterns, pipeline-friendly testing, DevOps metrics and enterprise DevOps. - [Elastic Leadership](https://www.elasticleadership.com): Elastic Leadership, Roy's framework for software team leaders (survival, learning and self-organizing modes). ### Social - X: https://x.com/royosherove - LinkedIn: https://www.linkedin.com/in/osherove/ ### Contact - Contact form: https://forms.gle/jQSx5KoXvrVA1JCK7 ### License Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page). License: https://creativecommons.org/licenses/by/4.0/