Part 4: Best Practices and Pitfalls

Part of the Pair Programming 101 Series

The Argument That Taught Me Everything

Three hours into a pairing session with Jake. Building the payment processing service.

Me: "We should use Stripe's webhook for payment confirmations." Jake: "No, polling is more reliable. We control the timing." Me: "Webhooks are real-time. Polling has delay." Jake: "What if the webhook fails? We miss the payment." Me: "Stripe retries webhooks. It's more reliable than polling." Jake: "I've built this before. Polling works better."

Silence. Tension. Both frustrated.

Then Jake said: "Let's take a 10-minute break."

We came back. Different approach.

Jake: "Show me the Stripe webhook documentation." Me: "Here. They retry up to 3 days with exponential backoff." Jake: "Okay, that's actually more reliable than I thought. But what about our monitoring?" Me: "Good point. We need alerting if webhooks fail." Jake: "And a fallback check. Polling every hour as backup." Me: "Perfect. Best of both approaches."

Result: Better solution than either of us had alone.

Lesson: Disagreements in pairing are valuable. How you handle them matters.

Communication Best Practices

1. Think Out Loud

Bad pairing:

// Driver types in silence for 10 minutes
export async function processPayment(orderId: string) {
  const order = await getOrder(orderId);
  const amount = calculateTotal(order);
  const payment = await stripe.charges.create({
    amount: amount * 100,
    currency: 'usd',
    source: order.paymentToken
  });
  return payment;
}

// Navigator has no idea what's happening
// Misses the bug (amount * 100 should handle cents already)

Good pairing:

// Driver narrating while typing
// "Getting the order first..."
const order = await getOrder(orderId);

// "Now calculating the total... wait, does this return cents or dollars?"
const amount = calculateTotal(order);

// Navigator catches it: "Good question. Let's check calculateTotal"
// We look at the function:
function calculateTotal(order: Order): number {
  // Returns amount in cents
  return order.items.reduce((sum, item) => sum + item.priceInCents, 0);
}

// "Ah, it's already in cents. No need to multiply by 100"
const payment = await stripe.charges.create({
  amount: amount, // Correctly using cents
  currency: 'usd',
  source: order.paymentToken
});

Narrating catches bugs before they happen.

2. Ask Questions, Not Commands

❌ Bad communication:

// Navigator being bossy
// "Change that to async/await"
// "No, use map instead of forEach"
// "That's wrong, do it this way"

// Driver feels micromanaged and frustrated

✅ Good communication:

// Navigator asking questions

// "What if we used async/await here instead of .then()?"
export async function getUsers() {
  // Driver: "Yeah, that's more readable. Let me refactor..."
  const response = await fetch('/api/users');
  return response.json();
}

// "Should we use map instead of forEach since we're transforming data?"
const userEmails = users.map(u => u.email);
// Driver: "Good point, map is better for transformations"

// "I'm wondering if we're handling the null case here?"
if (user) {
  // Driver: "Oh right, we should add that check"
  processUser(user);
}

Questions encourage thinking. Commands shut down collaboration.

3. Celebrate Small Wins

My pairing sessions always include:

// Tests passing after fixing a bug
async function validateUser(user: User) {
  if (!user.email) {
    throw new Error('Email required');
  }
  
  if (!isValidEmail(user.email)) {
    throw new Error('Invalid email format');
  }
  
  return true;
}

// Run tests
npm test

// ✓ should validate correct email
// ✓ should reject missing email  
// ✓ should reject invalid email format

// Me: "Nice! All tests passing."
// Partner: "Great catch on the format validation."

Positive reinforcement keeps energy high during long sessions.

4. Regular Check-ins

Every 25-30 minutes:

// Me: "This is working well. Should we keep going or switch roles?"
// Partner: "Let's switch. I want to try implementing the next part."

// Or:
// Me: "How are you feeling about this approach?"
// Partner: "Makes sense so far. I'm a bit unclear on the caching strategy though."
// Me: "Good point. Let me explain my thinking..."

Check-ins prevent misalignment and catch confusion early.

Role Switching Best Practices

When to Switch

My switching schedule:

1. Time-based (Most common):

// Switch every 25 minutes (Pomodoro style)
// Set a timer

// Session 1 (Me driving): Implement user validation
// 25 min timer goes off
// "Your turn to drive"

// Session 2 (Partner driving): Write tests
// Switch again after 25 minutes

2. Task-based:

// Switch when completing a logical unit

// Me driving: "User service is done. Your turn."
// Partner driving: "Auth middleware complete. Switching back."

// Natural breakpoints feel better than arbitrary timers

3. Stuck-based:

// Stuck on a problem for 10 minutes?
// Switch drivers

// Me: "I can't figure out why this test is failing..."
// 10 minutes pass
// Partner: "Let me drive and try a different approach"
// Fresh eyes often solve it immediately

How to Switch Smoothly

Bad switch:

// Abrupt mid-thought
// Driver is typing...
export async function processOrder(orderId: string) {
  const order = await getOrder(orderId);
  // Timer goes off
  // Partner: "Time to switch!"
  // Driver: "Wait, I'm in the middle of—"

Good switch:

// Wait for natural pause
export async function processOrder(orderId: string) {
  const order = await getOrder(orderId);
  const validated = await validateOrder(order);
  
  // Driver: "Validation is done. Good place to switch?"
  // Partner: "Perfect. Let me take over for the payment processing."
}

Switch at logical boundaries. Not mid-thought.

Handling Disagreements

Framework for Resolving Conflicts

When we disagree, we follow this process:

1. State both positions clearly

// Payment processing approach disagreement

// Position A (Me): "Use Stripe webhooks"
interface WebhookApproach {
  pros: [
    "Real-time updates",
    "Stripe handles retries",
    "Industry standard"
  ];
  cons: [
    "Requires webhook endpoint",
    "Need to verify signatures",
    "Depends on Stripe's delivery"
  ];
}

// Position B (Jake): "Poll Stripe API"
interface PollingApproach {
  pros: [
    "We control timing",
    "Simpler implementation",
    "No webhook infrastructure"
  ];
  cons: [
    "Delays in updates",
    "API rate limits",
    "More API calls = higher costs"
  ];
}

2. Look at data/documentation

// Me: "Let's check Stripe's documentation on reliability"
// Jake: "And let's look at our monitoring needs"

// Found in docs:
// - Webhooks: 99.99% delivery rate with retries
// - Polling: Rate limit of 100 requests/second
// - Our scale: 1000+ payments per hour peak

// Jake: "At our scale, polling would hit rate limits"
// Me: "And webhooks have better reliability than I thought"

3. Find hybrid solution

// Combined approach:
export class PaymentProcessor {
  // Primary: Webhook handling (real-time)
  async handleWebhook(webhookData: StripeWebhook) {
    const payment = await this.processWebhook(webhookData);
    await this.updateOrder(payment);
  }
  
  // Backup: Polling job (runs hourly)
  async reconcilePayments() {
    const pending = await this.findPendingOrders();
    
    for (const order of pending) {
      const payment = await stripe.charges.retrieve(order.chargeId);
      
      if (payment.status === 'succeeded') {
        await this.updateOrder({ orderId: order.id, status: 'paid' });
      }
    }
  }
}

// Best of both:
// - Real-time updates via webhooks
// - Safety net via polling
// - Monitoring for both paths

Both of us happier with the solution.

Real Disagreement Examples

Example 1: Error Handling Strategy

Disagreement:

// My approach: Throw errors, let global handler catch
export async function createUser(data: UserInput) {
  if (!data.email) {
    throw new Error('Email required');
  }
  // ...
}

// Partner's approach: Return error objects
export async function createUser(data: UserInput): Promise<Result<User>> {
  if (!data.email) {
    return { success: false, error: 'Email required' };
  }
  // ...
}

Resolution:

// Checked our codebase conventions
// Found: We already use exceptions everywhere
// Decision: Stay consistent with existing patterns

export async function createUser(data: UserInput): Promise<User> {
  if (!data.email) {
    throw new ValidationError('Email required');
  }
  
  // Use custom error classes for type safety
  return this.userRepository.create(data);
}

Consistency won. Both felt good about the decision.

Example 2: TypeScript strictness

Disagreement:

// Me: "Let's enable strict mode"
{
  "compilerOptions": {
    "strict": true,
    "noImplicitAny": true,
    "strictNullChecks": true
  }
}

// Partner: "Too many changes needed. Let's do it gradually"
{
  "compilerOptions": {
    "strict": false, // Enable later
    "noImplicitAny": true // Start with this
  }
}

Resolution:

// Checked: 15,000 lines of code, 200+ files
// Enabling strict mode = 500+ errors

// Agreed: Gradual migration
{
  "compilerOptions": {
    "strict": false,
    "noImplicitAny": true, // Week 1
    // "strictNullChecks": true, // Week 2 (planned)
    // "strict": true // Week 4 (goal)
  }
}

// New code must be strict-compliant
// Legacy code migrated incrementally

Pragmatism won. Set realistic timeline.

Avoiding Fatigue

Pair programming is mentally exhausting. Here's how I stay fresh.

Time Management

My sustainable schedule:

interface DailySchedule {
  morning: {
    "9:00-9:30": "Solo: Check emails, plan day";
    "9:30-11:00": "Pair programming session 1";
    "11:00-11:15": "Break";
    "11:15-12:00": "Solo: Follow-up tasks";
  };
  afternoon: {
    "12:00-13:00": "Lunch (NO SCREENS)";
    "13:00-14:30": "Pair programming session 2";
    "14:30-14:45": "Break";
    "14:45-17:00": "Solo: Code review, documentation, async work";
  };
}

// Maximum pairing: 3 hours per day
// Prevents burnout
// Keeps quality high

Never pair for more than 2 hours straight. Quality drops dramatically.

Taking Breaks

My break rules:

// Every 25-30 minutes: Mini break
// - Stand up
// - Stretch
// - Look away from screen
// - 2-3 minutes

// Every 2 hours: Real break
// - Walk outside
// - Get coffee
// - Chat about non-work stuff
// - 10-15 minutes

// Implementation:
setInterval(() => {
  console.log("⏰ Time for a break!");
  console.log("Stand up, stretch, rest your eyes");
}, 25 * 60 * 1000); // 25 minutes

Breaks maintain focus and prevent mental fatigue.

Recognizing Burnout Signs

Warning signs I watch for:

interface BurnoutIndicators {
  driver: {
    typingSlowly: boolean;          // Motor fatigue
    lotsOfTypos: boolean;           // Mental fatigue
    notNarrating: boolean;          // Disengagement
    quickToAgree: boolean;          // Giving up
  };
  navigator: {
    notSpeaking: boolean;           // Checked out
    missesObviousBugs: boolean;     // Attention drifting
    lookingAtPhone: boolean;        // Distraction
  };
  both: {
    silenceFor5Minutes: boolean;    // Communication breakdown
    frustrated: boolean;            // Energy depleted
  };
}

// When I notice these:
function handleBurnout() {
  // Option 1: Take a break
  console.log("Let's take a 15-minute break");
  
  // Option 2: End session
  console.log("We've made good progress. Let's continue tomorrow");
  
  // Option 3: Switch to async work
  console.log("Let's split up - I'll work on X, you work on Y");
}

Don't push through fatigue. Quality suffers and frustration builds.

Common Pitfalls to Avoid

1. Dominating the Session

Bad:

// One person driving 90% of the time
// Navigator barely speaks
// Session becomes "watching someone code"

// Signs:
// - One person types for hours
// - Limited role switching
// - Navigator scrolling their phone

// Impact:
// - Disengaged navigator
// - Missed bugs
// - Resentment builds

Fix:

// Forced rotation with timer
const SWITCH_INTERVAL = 25 * 60 * 1000; // 25 minutes

setInterval(() => {
  console.log("🔁 Time to switch roles!");
}, SWITCH_INTERVAL);

// Intentional engagement
// Navigator: "I notice we haven't switched in a while"
// Driver: "You're right, want to take over?"

2. Not Speaking Up

Bad:

// Navigator sees a bug but doesn't say anything
// "They probably know what they're doing..."

export async function calculateTotal(items: Item[]): Promise<number> {
  let total = 0;
  
  for (const item of items) {
    total += item.price;  // Bug: Should be item.price * item.quantity
  }
  
  return total;
}

// Bug ships to production
// Navigator feels guilty: "I saw that but didn't want to interrupt"

Fix:

// Speak up immediately!
// Navigator: "Wait, shouldn't that be price times quantity?"

export async function calculateTotal(items: Item[]): Promise<number> {
  let total = 0;
  
  for (const item of items) {
    total += item.price * item.quantity;  // Fixed!
  }
  
  return total;
}

// Driver: "Good catch! Thanks."

Your job as navigator is to catch bugs. Always speak up.

3. Rushing Through Without Understanding

Bad:

// Driver typing fast, navigator lost
export class PaymentService {
  async process(orderId: string) {
    const order = await this.getOrder(orderId);
    const token = await this.tokenize(order.card);
    const charge = await this.charge(token, order.total);
    await this.update(orderId, charge.id);
    await this.notify(order.userId);
    return charge;
  }
}

// Navigator: "Um... what just happened?"
// Didn't understand but afraid to ask

Fix:

// Navigator stops the driver
// "Hold on, can you explain what tokenize does?"

// Driver slows down:
export class PaymentService {
  async process(orderId: string) {
    // "First, we get the order details"
    const order = await this.getOrder(orderId);
    
    // "Then we tokenize the card to avoid handling raw card data"
    // "This converts card details to a secure token"
    const token = await this.tokenize(order.card);
    
    // "Now we can charge using the token"
    const charge = await this.charge(token, order.total);
    
    // "Update order with charge ID for reference"
    await this.update(orderId, charge.id);
    
    // "Finally notify the user"
    await this.notify(order.userId);
    
    return charge;
  }
}

// Navigator: "Got it! That makes sense now."

Both developers must understand the code. Slow down when needed.

My Pair Programming Checklist

Before starting:

• Both have stable internet connection

• Audio setup tested

• VS Code Live Share ready

• Clear goal for the session

• Timer set for switching roles

• Git branch created

During the session:

• Driver narrating their thinking

• Navigator asking questions

• Switching roles every 25-30 minutes

• Taking breaks every hour

• Committing regularly

• Both engaged and focused

After the session:

• Code committed with co-author

• Next steps documented

• Both understand what was built

• Quick retro: What worked? What didn't?

What's Next

In Part 5, we'll cover implementing pair programming at the team level:

• Introducing pairing to skeptical teams

• Scheduling pairing sessions

• Measuring effectiveness

• Building a pairing culture

• Scaling across distributed teams

Real experiences from introducing pairing to a 15-person team.

---

Previous: Part 3 - Tools and Remote Setup Next: Part 5 - Team Implementation → 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.