Code Review Dojo

Purpose

A Code Review Dojo brings the whole team together to review a piece of production code collaboratively. It aligns the team on coding standards, teaches review techniques, and normalizes giving and receiving feedback on code.

At a glance

How to run

1. Select the code (before session) — Choose a recent pull request or code module. Pick something representative, not trivial or deeply specialized.
2. Context (5 min) — The author briefly explains the purpose and constraints of the code.
3. Silent reading (10 min) — Everyone reads the code independently and writes down observations.
4. Group review (30 min) — Walk through the code together. Each person shares observations. Discuss: readability, naming, structure, error handling, testability, performance.
5. Agree on standards (10 min) — Capture any new coding standards or patterns the team wants to adopt.
6. Debrief (5 min) — What did we learn about how we review? How can we improve our daily reviews?

Materials needed

• The code to review (printed or on a shared screen)
• Team coding standards document (if it exists)
• Observation template (optional)
• Shared doc for capturing agreed standards

Pitfalls & common mistakes

• Making it personal — Review the code, not the coder. Frame feedback as improvements to the code.
• Only reviewing for bugs — Also consider readability, naming, and design.
• Senior developers dominate — Give juniors space to share observations first.
• No actionable outcomes — End with agreed standards or improvement actions.

Inclusion & accessibility

• Share the code 24 hours in advance so everyone can prepare.
• Ensure font size is large enough on the shared screen.
• Use a round-robin format so everyone contributes.

Variations

• Bug hunt dojo — Intentionally introduce bugs into a code sample; the team finds them.
• Refactoring dojo — The team refactors the code live during the session.
• Architecture review dojo — Focus on system design rather than code-level details.

When NOT to use this

• If the team has no established code review culture — start with pair programming first.
• If the code is too specialized for most team members to understand.

Source & further reading

• Atwood, J. (2006). "Code Reviews: Just Do It." codinghorror.com
• Bacchelli, A. & Bird, C. (2013). "Expectations, Outcomes, and Challenges of Modern Code Review." ICSE.