Dan Levenson presented on improving code review workflows through pair code reviews. Traditional stepwise code reviews can lead to dead time between reviews and large pull requests going unreviewed. Pair code reviews aim to minimize this by having the developer and reviewer schedule a one hour block to conduct the review together through conversation. This allows questions to be asked and issues addressed in real-time rather than through comments. While it can introduce bias, pair reviews have led to less dead time between reviews and a more collaborative culture at Healthify.us where Dan is CTO.

1. Lightning Talk:
Pair Code
Review
Dan Levenson

2. Who’s Speaking?
● dlevenson.com
● dleve123 on twitter, github, etc.
● CTO @ healthify.us

4. The Problem

5. The Problem

6. Development Workflow
1. Start story in Pivotal Tracker
2. Implement story
3. Open pull request
4. Participate in code review (CR)
5. Merge PR
6. QA on staging and manually deploy to
production

7. Stepwise Code Review Protocol
1. Developer assigns a reviewer using Github’s
pull request (PR) assignee functionality
2. Developer explicitly requests CR via Github
comment
3. Reviewer reviews via Github comments,
developer performs revisions, and repeat
4. Reviewer merges PR

8. Stepwise CR: Takeaways
● Not “Agile”: No face to face conversation
● “This is so simple. I’ll review it later”
○ later → much too late.
● Dead time due to lack of CR scheduling
○ Large PRs are daunting → even longer dead time

9. Pair Code Review: Motivation
● Old process intuitively inefficient
● Scrum → Kanban
○ minimize cycle time

10. Pair Code Review: Protocol
1. Developer and reviewer agree on a 1 hour
time period ASAP
2. Reviewer leads review and asks developer
questions
3. Reviewer comments on PR to document
action items generated from CR
4. Developer revises (usually only 1 time)

11. Some Progress

12. Some Progress

13. Pair CR: Takeaways
● Pros
○ Scheduling → less dead time
○ Long comments replaced by quick conversations
○ Breeds pairing culture
● Cons
○ Bias of the developer can affect reviewer