Lightning Talk: Pair Code ReviewDan Levenson

Who’s Speaking?

● dlevenson.com

● dleve123 on twitter, github, etc.

● CTO @ healthify.us

The Problem

The Problem

Development Workflow

1. Start story in Pivotal Tracker2. Implement story3. Open pull request4. Participate in code review (CR)5. Merge PR6. QA on staging and manually deploy to

production

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

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

Pair Code Review: Motivation

● Old process intuitively inefficient

● Scrum → Kanban○ minimize cycle time

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)

Some Progress

Some Progress

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