Async Pair Programming Workflow Using Recorded Walkthroughs and GitHub

Pair programming has long been celebrated as a powerful technique for knowledge sharing, code quality improvement, and team cohesion. But for distributed teams spread across time zones, traditional synchronous pair programming sessions can feel impossible to schedule. Enter async pair programming—a methodology that captures the benefits of pairing while respecting everyone’s timezone, focus time, and work style.

This guide walks you through implementing an async pair programming workflow using screen recordings and GitHub that maintains the collaborative spirit of traditional pairing while eliminating the scheduling headaches.

Why Async Pair Programming Matters

Traditional pair programming requires two developers to be online simultaneously, typically using screen sharing tools like Zoom, VS Code Live Share, or Tuple. While effective, this approach creates several challenges for distributed teams:

Timezone coordination becomes a nightmare when team members span multiple continents
Deep focus work gets interrupted by the need to join pairing sessions
Introvert team members may feel drained by constant video collaboration
Travel or offline work completely disrupts scheduled pairing sessions

Async pair programming solves these problems by replacing live screen sharing with recorded walkthroughs that reviewers can watch on their own schedule. The key is structuring these recordings to maximize their effectiveness.

Setting Up Your Async Pair Programming Framework

The Core Workflow

The async pair programming workflow consists of four main phases:

Driver creates a recorded walkthrough of their implementation approach
Navigator reviews the recording and provides feedback
Driver addresses feedback through additional recordings or code changes
Final review and merge after both parties agree

This cycle can repeat as needed until the code meets quality standards.

Required Tools

For an effective async pair programming setup, you’ll need:

Screen recording tool: Loom, OBS, or similar
Version control: GitHub (using PRs and comments)
Documentation: A shared wiki or Notion for guidelines
Video hosting: Loom embeds or YouTube (unlisted)

Step 1: Driver Creates the Implementation Walkthrough

When you’re driving (implementing), start by recording a walkthrough before or during your coding session. This isn’t about showing every keystroke—it’s about explaining your thought process.

What to Include in Your Recording

Your walkthrough should cover:

The problem: What issue are you solving? Reference any related issues or PRs.
Your approach: Walk through the overall strategy before diving into code.
Key decisions: Explain why you chose this implementation over alternatives.
Potential concerns: Be transparent about tradeoffs or areas of uncertainty.
Specific code sections: Highlight the most important or complex parts of your implementation.

Example Recording Script

"Hey team, I'm working on the user authentication refactor (issue #123).
My approach is to extract the auth logic into a separate service class.

Here's my thinking:
1. First, I'm adding a new `AuthService` that handles all token operations
2. I'm updating the controllers to call this service instead of directly accessing tokens
3. The main change is in lines 45-78 where I've added the refresh token logic

One concern: I noticed we might have a race condition when tokens refresh
simultaneously. I've added a basic lock but would love feedback on whether
this is sufficient.

Key files to review:
- `src/services/auth_service.dart` (new file)
- `src/controllers/user_controller.dart` (modified)
- `tests/auth_service_test.dart` (new tests)

Link to the PR: [URL]
Let me know if you have questions!"

Step 2: Creating Effective PR Descriptions for Async Review

Since your navigator won’t be able to ask live questions, your PR description needs to be enough to stand alone.

PR Template for Async Pair Programming

## Overview
Brief description of what this PR implements and why.

## Changes Made
- [ ] Change 1: Description
- [ ] Change 2: Description

## Approach
Explain the overall implementation strategy.

## Recording
[Embed Loom/video link here]

## Questions for Reviewer
- Specific question 1
- Specific question 2

## Testing
- [ ] Unit tests added/updated
- [ ] Manual testing completed
- [ ] Edge cases considered

Closes #issue-number

Step 3: Navigator Reviews and Provides Feedback

As the navigator, your job is to watch the recording carefully and provide constructive, specific feedback through GitHub comments.

How to Give Effective Async Feedback

Watch the entire recording before commenting—don’t jump to conclusions
Be specific: Reference line numbers, function names, or timestamps
Distinguish between blocking and non-blocking feedback
Ask questions instead of making demands when you’re uncertain
Acknowledge good decisions alongside areas for improvement

Feedback Template

## Review Summary
[1-2 sentence overall impression]

### Strengths
- What works well in this implementation

### Concerns
1. **Line 45 - Potential race condition**: I noticed...
   - Suggestion: Consider adding a lock here...

2. **Design consideration**: The current approach...

### Questions
- What happens when the API returns an error in this scenario?

### Nitpicks (non-blocking)
- Minor style preferences that aren't worth blocking on

Step 4: Addressing Feedback and Iterating

When you receive feedback, address it systematically:

Clarify questions through PR comments if you need more context
Make requested changes and explain what you changed
Record a follow-up walkthrough if the changes are significant
Request re-review once you’ve addressed all blocking feedback

Example Response to Feedback

Thanks for the review! I've addressed your feedback:

1. **Race condition (line 45)**: Added a mutex lock as suggested.
   See commit `abc123`.

2. **Design consideration**: I considered a separate class but decided
   to keep it in the service for now to minimize code churn. Happy to
   revisit in a follow-up if needed.

3. **Error handling**: Added proper error propagation in the updated
   recording: [new link]

Requesting re-review. Let me know if the new recording answers your
questions!

Integrating with GitHub Features

Using GitHub Actions for Async Workflow

Automate parts of your async pair programming with GitHub Actions:

name: Async Pair Programming
on: [pull_request]

jobs:
  check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - name: Check PR has recording
        run: |
          if ! grep -q "recording\|loom\|video" ${{ github.event.pull_request.body }}; then
            echo "Error: PR must include a recording link"
            exit 1
          fi

Using GitHub Discussions for Deeper Discussions

For complex decisions that go beyond code comments, create a GitHub Discussion linked to your PR. This keeps the conversation organized and searchable.

Best Practices for Success

Set Clear Expectations

Response time SLA: Agree on how quickly navigators should respond (e.g., 24-48 hours)
Recording length: Aim for 5-15 minute recordings—concise but
Feedback format: Standardize how feedback is structured

Maintain Human Connection

Include brief personal updates at the start of recordings
Celebrate completed work in team channels
Consider occasional live pairing sessions for relationship building

Iterate and Improve

Gather team feedback on the process monthly
Adjust time expectations based on timezone distribution
Document what’s working and what’s not

Common Pitfalls to Avoid

Recordings without context: Don’t just show code—explain your thinking
Vague feedback: “This seems wrong” isn’t helpful; be specific
Skipping follow-up recordings: If changes are significant, record them
Ignoring timezones entirely: Check when your reviewer is likely to be online
Perfectionism: Async pair programming is about collaboration, not getting everything perfect on the first try

Built by theluckystrike — More at zovo.one