I implemented a similar process with my team. Daily team code reviews of any work that's in progress.
My reasoning behind it was different though:
Share knowledge with the entire team. Knowledge shared among all members of the team empowers the team members to help each other as needed. It also helps all members learn from each other in terms of patterns and code styles.
Keep review scope small. Code can change a LOT in just 1 day. So reviewing the code daily helps the team keep up with the context and the scope of the review is smaller than if you were to review a "ready" pull request.
Build team trust. Reviewing together and learning how to work with each other opens the door to increase team trust. High team trust = highly performant teams.
Code reviews are a great way to ensure code quality but I love to use them as a tool to build up and enable the team as well. đź‘Ť
Great read! 🙂
I implemented a similar process with my team. Daily team code reviews of any work that's in progress.
My reasoning behind it was different though:
Share knowledge with the entire team. Knowledge shared among all members of the team empowers the team members to help each other as needed. It also helps all members learn from each other in terms of patterns and code styles.
Keep review scope small. Code can change a LOT in just 1 day. So reviewing the code daily helps the team keep up with the context and the scope of the review is smaller than if you were to review a "ready" pull request.
Build team trust. Reviewing together and learning how to work with each other opens the door to increase team trust. High team trust = highly performant teams.
Code reviews are a great way to ensure code quality but I love to use them as a tool to build up and enable the team as well. đź‘Ť
Way to go Cristina. Love your approach.