Effektives Pair Programming: Muster, die wirklich funktionieren

// Example: Navigator spots an edge case as Driver writes
// Driver typing:
async function getUserOrders(userId: string): Promise<Order[]> {
  const user = await db.user.findUnique({ where: { id: userId } });
  const orders = await db.order.findMany({
    where: { userId },
    orderBy: { createdAt: 'desc' },
  });
  return orders;
}
 
// Navigator: "We're fetching user but not using it.
// Were you planning to check permissions?
// Also — what happens if userId doesn't exist?
// We should add a null check on user."
 
// Driver revises:
async function getUserOrders(userId: string): Promise<Order[]> {
  const user = await db.user.findUnique({ where: { id: userId } });
 
  if (!user) {
    throw new NotFoundError(`User ${userId} not found`);
  }
 
  return db.order.findMany({
    where: { userId },
    orderBy: { createdAt: 'desc' },
  });
}

// Round 1: Person A writes a failing test
describe('PasswordValidator', () => {
  it('rejects passwords shorter than 8 characters', () => {
    expect(validatePassword('abc')).toEqual({
      valid: false,
      errors: ['Password must be at least 8 characters'],
    });
  });
});
 
// Round 2: Person B makes it pass with minimal code
function validatePassword(password: string): ValidationResult {
  const errors: string[] = [];
 
  if (password.length < 8) {
    errors.push('Password must be at least 8 characters');
  }
 
  return { valid: errors.length === 0, errors };
}
 
// Round 3: Person A writes the next test
it('requires at least one uppercase letter', () => {
  expect(validatePassword('abcdefgh')).toEqual({
    valid: false,
    errors: ['Password must contain at least one uppercase letter'],
  });
});
 
// Round 4: Person B extends the implementation
function validatePassword(password: string): ValidationResult {
  const errors: string[] = [];
 
  if (password.length < 8) {
    errors.push('Password must be at least 8 characters');
  }
 
  if (!/[A-Z]/.test(password)) {
    errors.push('Password must contain at least one uppercase letter');
  }
 
  return { valid: errors.length === 0, errors };
}
 
// Continue alternating...

## Hier paaren:
- Komplexe Geschäftslogik (der Navigator erkennt Logikfehler)
- Systemdesign-Diskussionen (zwei Perspektiven finden bessere Abstraktionen)
- Bug-Untersuchungen (einer liest Code, einer bildet Hypothesen)
- Onboarding (Neuer drives, erfahrener Dev navigiert)
- Unbekannte Codebases (kollektive Erkundung ist schneller)
- Sicherheitskritischer Code (vier Augen auf Auth und Crypto)
 
## Hier nicht paaren:
- Einfache, gut verstandene CRUD-Operationen
- Routine-Konfigurationsänderungen
- Dokumentation schreiben
- Aufgaben, die tiefe Konzentration und individuellen Flow erfordern
- Mechanisches Refactoring (Rename, Extract Method)

// This benefits from pairing — complex state machine with edge cases
function processPayment(order: Order, payment: Payment): PaymentResult {
  // Multiple states, retries, partial failures, compensating actions
  // Navigator catches: "What if the charge succeeds but inventory
  // reservation fails? We need a compensation step."
}
 
// This does NOT benefit from pairing — straightforward CRUD
async function updateUserEmail(userId: string, email: string) {
  return db.user.update({ where: { id: userId }, data: { email } });
}

// .vscode/settings.json — Live Share configuration for pairing
{
  "liveshare.autoShareServers": true,
  "liveshare.autoShareTerminals": true,
  "liveshare.focusBehavior": "prompt",
  "liveshare.guestApprovalRequired": false,
  "liveshare.shareExternalFiles": false
}

## Remote-Pairing-Checklist:
1. Beide Teilnehmer haben VS Code Live Share installiert
2. Nutzt einen dedizierten Sprachkanal (Discord, Slack, Teams)
3. Teilt das Terminal — beide müssen Commands ausführen können
4. Nutzt die "Follow"-Funktion, um in derselben Datei zu bleiben
5. Rollenwechsel laut ansagen: "Ich drive jetzt"
6. Alle 50 Minuten Pause machen — Bildschirmmüdigkeit ist real

# Screen sharing with audio — for teams without VS Code
# tmux allows both participants to use the same terminal
# On host machine:
tmux new -s pairing
 
# On remote machine (via SSH):
tmux attach -t pairing
 
# Both see the same terminal, both can type
# Pair with any terminal-based editor (vim, nano, emacs)

## Kommunikationsmuster des Navigators:
 
✅ "Bevor wir das implementieren — können wir den Ansatz
   für 2 Minuten durchsprechen? Ich will sicherstellen, dass wir beim Datenfluss auf einer Linie liegen."
 
✅ "Ich glaube, da ist ein Off-by-One-Fehler in Zeile 15.
   Soll der Index bei 0 oder 1 anfangen?"
 
✅ "Diese Funktion wird lang. Willst du die Validierung
   vor dem Weitermachen in eine eigene Funktion extrahieren?"
 
✅ "Ich würde hier lieber ein Map statt eines Objekts verwenden —
   wir brauchen geordnete Iteration."
 
❌ Schweigend sitzen und Slack checken
❌ "Mach einfach, wie du willst, ich reviewe den PR später"
❌ Die Tastatur ohne Fragen greifen
❌ Jeden Tastendruck diktieren: "Tippe const, Leerzeichen, user, equals..."

## Kommunikationsmuster des Drivers:
 
✅ "Ich probiere zuerst den rekursiven Ansatz.
   Sag Bescheid, wenn du einen einfacheren Weg siehst."
 
✅ "Ich hänge bei diesem Type-Fehler. Kannst du die
   Generic-Constraint lesen, während ich die Call Site anschaue?"
 
✅ "Lass mich das erst refactoren — gib mir 3 Minuten, um
   das zu extrahieren, dann schauen wir uns das Design an."
 
❌ 20 Minuten lang still coden, ohne die Absicht zu erklären
❌ Vorschläge des Navigators ignorieren

## Metriken, die effektives Pairing anzeigen:
 
1. Defect-Rate in gepaartem Code vs. Solo-Code
   → Bugs tracken, die im Code Review oder in Production gefunden wurden; tagge gepaart vs. solo
   → Ziel: 30-50% weniger Defekte in gepaartem Code
 
2. Wissensverteilung
   → Bus Factor: Wie viele Leute können jedes Modul ändern?
   → Ziel: Kein Modul hängt an nur einer Person, die es versteht
 
3. Onboarding-Dauer
   → Tage bis ein New Hire seinen ersten Solo-PR einreicht
   → Ziel: 50% schneller mit Pairing-Onboarding
 
4. PR-Review-Durchlaufzeit
   → Gepaarter Code bekommt leichtere Reviews (bereits in Echtzeit geprüft)
   → Ziel: PRs aus Paaren werden 40% schneller gemergt
 
5. Entwicklerzufriedenheit
   → Umfrage: "Hilft Pairing bei [Aufgabentyp] deiner Meinung nach, die Qualität zu verbessern?"
   → Ziel: >70% positive Rückmeldungen

## Woche 1-2: Einführung
- Pro Person einmal pro Sprint paaren
- Driver-Navigator mit 25-Minuten-Wechseln nutzen
- Nach jeder Session debriefen: was hat funktioniert, was war unbeholfen
 
## Woche 3-4: Rhythmus finden
- Bei komplexen Aufgaben automatisch paaren
- Ping-Pong Pairing für TDD-Aufgaben einführen
- Debrief auf ein schnelles "Gibt es etwas anzupassen?" reduzieren
 
## Woche 5+: Selbsttragend
- Entwickler initiieren Pairing, wenn sie auf Komplexität stoßen
- Kein erzwungenes Pairing bei einfachen Aufgaben
- Partner rotieren, um Wissen zu verteilen