Part 2: Pair Programming Techniques

Part of the Pair Programming 101 Series

The Day I Learned There Are Different Styles

I thought pair programming was one thing: Driver types, navigator watches.

Then I joined a new team. First day, morning standup.

Tech lead: "Today we're doing ping-pong TDD on the auth service."

Me: "Wait... what?"

Turns out: There are multiple pair programming techniques. Each serves different purposes.

Let me show you the four techniques I actually use in production.

1. Driver-Navigator (Classic Pairing)

Most common approach. One person drives (types), the other navigates (thinks ahead).

How It Works

Driver responsibilities:

• Write code

• Think tactically (syntax, implementation)

• Voice your thinking process

• Ask questions when unclear

Navigator responsibilities:

• Think strategically (architecture, edge cases)

• Review code as it's written

• Suggest improvements

• Keep the big picture in mind

Rotation: Switch roles every 15-30 minutes.

Real Example: Building a User Service

My teammate Jake and I building user authentication:

// Jake driving, me navigating

// src/services/user.service.ts
import { hash, compare } from 'bcrypt';
import { UserRepository } from '@/repositories/user';
import { generateToken } from '@/utils/jwt';

export class UserService {
  constructor(private userRepo: UserRepository) {}
  
  // Jake typing this out
  async register(email: string, password: string) {
    // Me (navigator): "Check if user already exists first"
    const existing = await this.userRepo.findByEmail(email);
    
    // Me: "Throw a descriptive error"
    if (existing) {
      throw new Error('User already exists with this email');
    }
    
    // Jake: "Hashing the password..."
    // Me: "Use 12 rounds for bcrypt, good security/performance balance"
    const hashedPassword = await hash(password, 12);
    
    const user = await this.userRepo.create({
      email,
      password: hashedPassword,
      createdAt: new Date()
    });
    
    // Me: "Don't return the password hash"
    const { password: _, ...userWithoutPassword } = user;
    
    return userWithoutPassword;
  }
}

Navigator caught:

• Missing duplicate check

• Security concern (bcrypt rounds)

• Data leak (returning password hash)

All in real-time. No code review needed later.

When to Use Driver-Navigator

✅ General development work ✅ Learning new codebase ✅ Complex business logic ✅ Code refactoring

My team uses this 70% of the time. Versatile and effective.

2. Ping-Pong Programming (TDD-Focused)

Developer A writes test. Developer B makes it pass. Switch.

Perfect for test-driven development.

How It Works

1. Developer A: Write a failing test

2. Developer B: Write minimal code to pass the test

3. Both: Refactor together

4. Switch roles

5. Repeat

Real Example: Building Validation Logic

My pairing session with Maria on user input validation:

// Round 1: Maria writes test, I make it pass

// maria.spec.ts (Maria writing)
import { validateEmail } from '@/utils/validation';

describe('Email Validation', () => {
  it('should accept valid email', () => {
    // Maria's test
    expect(validateEmail('[email protected]')).toBe(true);
  });
});

// validation.ts (Me writing to make it pass)
export function validateEmail(email: string): boolean {
  // Simplest code to pass the test
  return email.includes('@');
}

// Round 2: I write test, Maria makes it pass

// validation.spec.ts (Me writing)
it('should reject email without domain', () => {
  expect(validateEmail('user@')).toBe(false);
});

// validation.ts (Maria improving the implementation)
export function validateEmail(email: string): boolean {
  const emailRegex = /^[^\s@]+@[^\s@]+\.[^\s@]+$/;
  return emailRegex.test(email);
}

// Round 3: Maria writes test, I make it pass

// validation.spec.ts (Maria writing)
it('should reject email with spaces', () => {
  expect(validateEmail('user @example.com')).toBe(false);
});

// Already passes! The regex handles it.

// Round 4: I write edge case test

it('should handle empty string', () => {
  expect(validateEmail('')).toBe(false);
});

// Passes! We're done.

Result: Thoroughly tested validation function. Both developers understand the code completely.

Complete User Validation Example

Full session with Sarah building user input validation:

// user-validation.spec.ts
import { validateUser, ValidationError } from '@/utils/user-validation';

describe('User Validation', () => {
  // Sarah's test
  it('should validate correct user data', () => {
    const user = {
      email: '[email protected]',
      password: 'SecurePass123!',
      username: 'testuser'
    };
    
    expect(() => validateUser(user)).not.toThrow();
  });
  
  // My test
  it('should reject weak passwords', () => {
    const user = {
      email: '[email protected]',
      password: '123',
      username: 'testuser'
    };
    
    expect(() => validateUser(user)).toThrow(ValidationError);
  });
  
  // Sarah's test
  it('should require password minimum length', () => {
    const user = {
      email: '[email protected]',
      password: 'short',
      username: 'testuser'
    };
    
    const error = () => validateUser(user);
    expect(error).toThrow('Password must be at least 8 characters');
  });
  
  // My test
  it('should require username alphanumeric characters', () => {
    const user = {
      email: '[email protected]',
      password: 'SecurePass123!',
      username: 'test@user!'
    };
    
    expect(() => validateUser(user)).toThrow('Username must be alphanumeric');
  });
});

// user-validation.ts (Built together through ping-pong)
export class ValidationError extends Error {
  constructor(message: string) {
    super(message);
    this.name = 'ValidationError';
  }
}

interface UserInput {
  email: string;
  password: string;
  username: string;
}

export function validateUser(user: UserInput): void {
  // Email validation
  const emailRegex = /^[^\s@]+@[^\s@]+\.[^\s@]+$/;
  if (!emailRegex.test(user.email)) {
    throw new ValidationError('Invalid email format');
  }
  
  // Password validation
  if (user.password.length < 8) {
    throw new ValidationError('Password must be at least 8 characters');
  }
  
  const hasUpperCase = /[A-Z]/.test(user.password);
  const hasLowerCase = /[a-z]/.test(user.password);
  const hasNumber = /[0-9]/.test(user.password);
  const hasSpecial = /[!@#$%^&*]/.test(user.password);
  
  if (!hasUpperCase || !hasLowerCase || !hasNumber || !hasSpecial) {
    throw new ValidationError(
      'Password must contain uppercase, lowercase, number, and special character'
    );
  }
  
  // Username validation
  const usernameRegex = /^[a-zA-Z0-9]+$/;
  if (!usernameRegex.test(user.username)) {
    throw new ValidationError('Username must be alphanumeric');
  }
  
  if (user.username.length < 3 || user.username.length > 20) {
    throw new ValidationError('Username must be 3-20 characters');
  }
}

Ping-pong led to:

• Comprehensive test coverage

• Edge cases discovered naturally

• Both developers fully engaged

• High-quality validation logic

When to Use Ping-Pong

✅ Test-driven development ✅ Building utilities and helpers ✅ Algorithm implementation ✅ Security-critical code

I use this when test coverage is essential.

3. Strong-Style Pairing (Learning-Focused)

"For an idea to go from your head to the computer, it must go through someone else's hands."

Navigator has the idea. Driver implements exactly what navigator says.

Perfect for knowledge transfer.

How It Works

Navigator: Expert with the knowledge Driver: Learner who needs to understand

Navigator instructs, driver types. Driver can't implement their own ideas - only navigator's instructions.

Forces navigator to explain clearly. Forces driver to understand before typing.

Real Example: Teaching API Design

I'm teaching junior dev Tom about REST API design:

// src/routes/products.ts

// Me (navigator): "Import Router from express"
import { Router } from 'express';

// Me: "Import the product service we built yesterday"
import { ProductService } from '@/services/product';

// Me: "Import the authenticate middleware"
import { authenticate } from '@/middleware/auth';

// Me: "Create a new router"
const router = Router();

// Me: "Let's build a GET endpoint for listing products"
// Me: "Start with router.get, path is /products"
router.get('/products', async (req, res) => {
  // Me: "We need try-catch for error handling"
  try {
    // Me: "Get pagination params from query - page and limit"
    const page = parseInt(req.query.page as string) || 1;
    const limit = parseInt(req.query.limit as string) || 10;
    
    // Me: "Call ProductService.list with page and limit"
    const products = await ProductService.list({ page, limit });
    
    // Me: "Return 200 with the products"
    res.status(200).json(products);
  } catch (error) {
    // Me: "Log the error first"
    console.error('Error listing products:', error);
    // Me: "Return 500 with error message"
    res.status(500).json({ error: 'Failed to fetch products' });
  }
});

// Me: "Now a POST endpoint for creating products"
// Me: "This one needs authentication, add authenticate middleware"
router.post('/products', authenticate, async (req, res) => {
  try {
    // Me: "Extract product data from request body"
    const { name, price, description } = req.body;
    
    // Me: "Validate required fields"
    if (!name || !price) {
      // Me: "Return 400 for missing fields"
      return res.status(400).json({ 
        error: 'Name and price are required' 
      });
    }
    
    // Me: "Call ProductService.create"
    const product = await ProductService.create({
      name,
      price,
      description
    });
    
    // Me: "Return 201 for created resource"
    res.status(201).json(product);
  } catch (error) {
    console.error('Error creating product:', error);
    res.status(500).json({ error: 'Failed to create product' });
  }
});

// Me: "Export the router"
export default router;

Tom (driver): "Why do we return 201 instead of 200?" Me (navigator): "201 means 'Created' - it's the semantic HTTP status for resource creation. 200 is generic success." Tom: "And we always need try-catch?" Me: "In async route handlers, yes. Otherwise unhandled promise rejections crash the server."

Tom learned:

• REST conventions

• HTTP status codes

• Error handling patterns

• Middleware usage

• Request validation

All by typing it out while I explained.

When to Use Strong-Style

✅ Onboarding new developers ✅ Teaching unfamiliar technology ✅ Sharing domain knowledge ✅ Mentoring sessions

I use this 2-3 times per week when mentoring.

4. Mob Programming (Team Collaboration)

Entire team (3-7 people) working on one problem together.

One driver, multiple navigators.

How It Works

1. One person drives (types code)

2. Everyone else navigates (discusses approach)

3. Rotate driver every 10-15 minutes

4. Decisions made by consensus

Real Example: Architecture Decision

Our team mob session deciding on microservices communication:

// Team: Me, Sarah, Jake, Tom, Maria
// Problem: How should our services communicate?

// Round 1: Sarah driving

// Sarah: "Starting with HTTP REST approach"
// services/order-service/src/clients/inventory.client.ts

interface InventoryClient {
  checkStock(productId: string): Promise<number>;
  reserveStock(productId: string, quantity: number): Promise<void>;
}

// Jake (navigator): "What about failure cases?"
// Maria: "We need retry logic"
// Me: "And circuit breakers for when inventory service is down"

export class HttpInventoryClient implements InventoryClient {
  private baseUrl: string;
  
  constructor(baseUrl: string) {
    this.baseUrl = baseUrl;
  }
  
  async checkStock(productId: string): Promise<number> {
    // Tom: "Should we add timeout?"
    // Everyone: "Yes, 5 seconds"
    const response = await fetch(
      `${this.baseUrl}/api/inventory/${productId}`,
      { 
        method: 'GET',
        headers: { 'Content-Type': 'application/json' },
        signal: AbortSignal.timeout(5000)
      }
    );
    
    if (!response.ok) {
      throw new Error(`Inventory check failed: ${response.status}`);
    }
    
    const data = await response.json();
    return data.quantity;
  }
}

// Round 2: Jake driving, reconsidering approach

// Jake: "What if we used message queues instead?"
// Sarah: "More reliable for async operations"
// Me: "But adds complexity"
// Maria: "Let's prototype both approaches"

// services/order-service/src/clients/inventory.queue.ts
import { EventEmitter } from 'events';

interface StockCheckMessage {
  productId: string;
  correlationId: string;
}

interface StockCheckResponse {
  correlationId: string;
  quantity: number;
}

export class QueueInventoryClient implements InventoryClient {
  private eventBus: EventEmitter;
  private pendingRequests: Map<string, (value: number) => void>;
  
  constructor(eventBus: EventEmitter) {
    this.eventBus = eventBus;
    this.pendingRequests = new Map();
    
    // Listen for responses
    this.eventBus.on('inventory.stock.response', this.handleResponse.bind(this));
  }
  
  async checkStock(productId: string): Promise<number> {
    return new Promise((resolve, reject) => {
      const correlationId = crypto.randomUUID();
      
      // Store resolver
      this.pendingRequests.set(correlationId, resolve);
      
      // Publish request
      this.eventBus.emit('inventory.stock.check', {
        productId,
        correlationId
      } as StockCheckMessage);
      
      // Timeout after 10 seconds
      setTimeout(() => {
        if (this.pendingRequests.has(correlationId)) {
          this.pendingRequests.delete(correlationId);
          reject(new Error('Stock check timeout'));
        }
      }, 10000);
    });
  }
  
  private handleResponse(response: StockCheckResponse): void {
    const resolver = this.pendingRequests.get(response.correlationId);
    if (resolver) {
      resolver(response.quantity);
      this.pendingRequests.delete(response.correlationId);
    }
  }
}

// Team discussion:
// Sarah: "Queue approach is more resilient"
// Tom: "But HTTP is simpler and easier to debug"
// Me: "What about using HTTP with a message queue fallback?"
// Jake: "That's overengineering for our scale"
// Maria: "Let's start with HTTP, add queues when we need them"
// Everyone: "Agreed"

Team decision: Start with HTTP REST, plan for message queue migration if needed.

Mob programming gave us:

• Multiple perspectives

• Consensus on approach

• Shared understanding

• No knowledge silos

When to Use Mob Programming

✅ Architecture decisions ✅ Complex problem solving ✅ Critical infrastructure changes ✅ Team alignment on approach

I use this once or twice per month for big decisions.

Choosing the Right Technique

My decision framework:

type PairingContext = {
  teamSize: number;
  experienceGap: 'similar' | 'learning' | 'teaching';
  taskType: 'tdd' | 'feature' | 'architecture' | 'learning';
  urgency: 'low' | 'medium' | 'high';
};

function chooseTechnique(context: PairingContext): string {
  // Mob for architecture with full team
  if (context.taskType === 'architecture' && context.teamSize > 2) {
    return 'Mob Programming';
  }
  
  // Strong-style for teaching
  if (context.experienceGap === 'teaching') {
    return 'Strong-Style Pairing';
  }
  
  // Ping-pong for TDD
  if (context.taskType === 'tdd') {
    return 'Ping-Pong Programming';
  }
  
  // Default to driver-navigator
  return 'Driver-Navigator';
}

Real usage breakdown from my team:

• Driver-Navigator: 70% of pairing sessions

• Ping-Pong: 20% of pairing sessions

• Strong-Style: 8% of pairing sessions

• Mob Programming: 2% of pairing sessions

My Pairing Technique Evolution

Year 1: Only knew driver-navigator. Used it for everything.

Year 2: Discovered ping-pong TDD. Code quality improved dramatically.

Year 3: Learned strong-style for mentoring. Onboarding became 10x easier.

Year 4: Tried mob programming. Game-changer for architecture decisions.

Today: Use the right technique for each situation.

What's Next

In Part 3, we'll explore the tools that make pair programming effective:

• VS Code Live Share setup

• Remote pairing best practices

• Communication tools

• Git workflow for pairing

With real configuration examples and lessons from distributed teams.

---

Previous: Part 1 - Introduction to Pair Programming Next: Part 3 - Tools and Remote Setup → Series Home: Pair Programming 101

This article is part of the Pair Programming 101 series. All examples based on real pair programming experiences using TypeScript, Node.js, and modern development tools.