Code with me – Pair Programming

Das 4-Augenprinzip in der Softwareentwicklung hat klare Vorteile und ist in der agilen Welt inzwischen stark verbreitet. Welche unterschiedlichen Pair-Programming-Modelle gibt es und bei welchen profitierst Du beim Berufseinstieg besonders vom Programmieren im Tandem? Mit diesem Artikel bekommst Du als IT-Berufseinsteiger:in einen kleinen Guide, der Dich nicht nur sicher durch Deine ersten Pair-Programmierung führt, sondern Dir auch Vorteile und Herausforderungen aufzeigt, die Du als Entwickler:in mit dieser Programmiertechnik bewältigen musst. Aufgeregt? Los geht’s!

Zwei Devs und ein Bildschirm: Pair Programming ist eine Form des Extreme Programming (XP) und stammt aus der agilen Softwareentwicklung. Gemeinsam arbeiten zwei Devs nicht nur an einer Aufgabe und schreiben Code. Sie planen und besprechen ihre Arbeit, diskutieren die unterschiedlichen Herangehensweisen und kommen am Ende zu besseren Lösungen. Inzwischen gibt es einige Studien, die belegen, dass Pair Programming zwar mehr Zeit in Anspruch nimmt (gut 15 %), aber auch weniger Fehler entstehen (auch 15 %). Im Prinzip ist diese Form des kollaborativen Arbeitens eine Code Review in Echtzeit. Hört sich nach DevOps an? Da liegst Du gar nicht so falsch. Tatsächlich sind bei dieser Art der Softwareentwicklung auch Deine Social Skills gefragt.

Es gibt verschiedene Möglichkeiten, bzw. Rollenmodelle nach denen Du mit Deiner Dev-Kolleg:in gemeinsam an besserem Code arbeiten kannst.

1. Driver & Navigator

Das ist wahrscheinlich das bekannteste Modell und spielt auf die Rollenverteilung und die Teamarbeit von Fahrer:in und Beifahrer:in bei einer Auto-Rallye an. Beide Entwickler:innen haben bei diesem Modell den gleichen Kenntnisstand. Während der Driver sich auf das Schreiben des Codes konzentriert, hat der Navigator den Überblick und stellt Rückfragen.

Zu einer guten Kommunikation im Pair Programming gehört, dass Du in der Rolle des Driver immer aussprichst, was Du tust. Das hilft dem Navigator Dein Handeln zu verstehen und er muss nicht unnötig oder vorschnell eingreifen.

Als Driver erklärst Du jeden Deiner Schritte:

• Du gibst dem Navigator einen Ausblick auf Dein Handeln (“Ich werde als nächstes den Zugriff auf die Datenbank implementieren.”)
• und einen Einblick in Deine Denkweise (“Ich beginne mit der Implementierung von A, dann kann ich dies danach bei B benutzen.”).
• Du formulierst Deine Erwartungen (“Der Test sollte jetzt funktionieren.”)
• und sprichst auch Offensichtliches aus (“Das können wir so committen.”).
  

Als Navigator unterstützt Du den Driver aktiv in seinem Handeln, indem Du

• Annahmen bestätigst,
• nach Gründen fragst, z.B. wenn der Driver plötzlich von Konventionen abweicht und eine Variable anders deklarierst.
• nach einer Lösung Ausschau hältst, wenn Du ahnst, dass Ihr in einer Sackgasse landet.
  

Bei der Driver-Navigator-Rollenverteilung tauscht Ihr regelmäßig die Rollen. Weil Du selbst weißt, wie tief Du beim Programmieren abtauchst, hat sich eine Timebox bewährt, damit das Pair alle 10 Minuten an den Rollentausch erinnert wird.

Vielleicht begegnen Dir auch diese Variationen des Driver & Navigator-Modells: Als Junior-Enwickler:in mit vergleichsweise wenig Erfahrung profitierst Du bei der Variation Tour Guide & Tourist von einem erfahrenen Developer als Tandempartner:in. Der Tour Guide sitzt an der Tastatur und übernimmt die Aufgaben. Dabei erklärt er oder sie die Vorgehensweise. Als Tourist verfolgst Du alles und hast die Möglichkeit Fragen zu stellen. In der Rolle des Drivers bei dem Modell Driver & Backseat Navigator bist Du als Junior derjenige, der programmiert, aber Du musst immer damit rechnen, dass vom Rücksitz eine korrigierende Anweisung kommt. Beide Rollenverteilungen bieten sich an, wenn der Wissensstand beider Developer sehr unterschiedlich ist und sind nützliche Methoden des Onboardings.

2. Ping-Pong-Pairing

Bei der testgetriebenen Softwareentwicklung (Test driven Development TDD) wird häufig die Ping-Pong-Methode eingesetzt. Anders als beim Driver & Navigator-Modell sind hier beide Rollen aktiv. Abwechselnd schreibst und implementierst Du und Dein Pair Tests:

• “Ping”: Person A schreibt einen fehlgeschlagenen Test
• “Pong”: Person B schreibt Implementierung, die den Test besteht
• “Ping”: Person B starten den nächsten “Ping”, also fehlgeschlagenen Test
  

Alternativ kann auf jedes “Pong” ein gemeinsames Refactoring folgen, bevor Ihr mit den nächsten Test startet.

3. Strong-style-Pairing

Das Strong-style-Pairing kombiniert Elemente von Driver & Navigator mit dem Konzept von Driver & Backseat-Navigator. Hier steht vor allem der Wissenstransfer im Fokus, optimal also um IT-Talente wie Dich einzuarbeiten. Der Driver ist ein Newbie (in der Sprache, dem Tool, dem Framework…) und wird vom erfahrenen Navigator angeleitet. Wichtige Basis ist, dass Du als Driver Deinem Pilot voll und ganz vertraust, denn in der Regel werden Fragen erst nach der Implementierung geklärt. Indem Du selbst den Code schreibst, lernst Du meist mehr, als wenn Du nur zuschaust. Diese Methode eignet sich bestens, um Junior-Entwickler einzuarbeiten. Aber sie sollte auch nicht überstrapaziert werden. Denn das Ziel ist es, dass nach einiger Zeit die Rollen getauscht werden können und der Beweis, dass der Wissenstransfer funktioniert hat.

Teamwork = Dreamwork? In dieser engen Zusammenarbeit entscheidet die Art, wie das Tandem kommuniziert darüber, wie gut der Code ist, den Ihr gemeinsam als Team schreibt. Diese Form der Zusammenarbeit ist sehr intensiv und fordert viel Konzentration. Die einzelnen Sessions sollten deshalb nicht länger als 6 Stunden am Tag dauern. Die restlichen 2 Stunden Deines Arbeitstages planst Du für E-Mails und organisatorische Dinge ein.

Im Büro oder remote?

Die ursprüngliche Idee ist, dass Du mit Deiner Dev-Kolleg:in vor einem Bildschirm sitzt und eine:r von Euch die Macht über Maus und Tastatur hat. Durch die Pandemie hat sich seit spätestens 2020 die digitale Version des Pair Programming im Home-Office etabliert. Mit einem stabilen Videodienst, der Möglichkeit die Steuerung zu übergeben und der Benutzung der gleichen IDE ist die Tandem-Programmierung von überall aus möglich – vorausgesetzt die Netzwerkbandbreite stimmt.

Die Gefahr, dass Du Dich in Deinem Code vergaloppierst oder ewig an der elegantesten Lösung feilst, ist viel geringer. Auch wenn zwei Personen scheinbar mit derselben Aufgabe beschäftigt sind, ist das Ergebnis weit mehr, als der fertige Clean Code. Beide Seiten haben viel mehr gelernt. Nicht nur, wie besserer Code entsteht, weil Ihr ihn quasi live refactored habt, sondern auch auf sozialer Ebene. Du setzt Dich sehr intensiv mit einem Teammitglied und dessen Arbeitsweise auseinander und lernst z.B. auch wie Du wertschätzendes Feedback gibst. Im Idealfall werden die Paare immer wieder neu zusammengesetzt, sodass sich das Wissen im gesamten Team verteilt. Die Verantwortung für den Code liegt nicht mehr bei einzelnen Personen, sondern im Sinne von Collective Code Ownership beim ganzen Team.

Durch Pair Programming

• wird die Sozialkompetenz im Team gefördert
• findet Wissenstransfer statt, bzw. werden Wissensinseln im Team vermieden
• verbessert sich Codequalität, z.B. werden Fehler früher erkannt
• haben viele Devs mehr Spaß bei der Arbeit :)

Do’s und Don’t beim Pair Programming

Gerade wenn Du es gewohnt bist, alleine an Deinem Code zu arbeiten, wird es erstmal eine Umstellung sein. Ganz wichtig, damit die Zusammenarbeit gut funktioniert: Lass’ Feedback zu und nimm es Dir nicht zu Herzen, wenn Du Kritik für Deinen Stil bekommst. Siehe Deinen Buddy als Bereicherung und Chance, Deinen Code besser und effizienter zu machen. In der Anfangsphase fühlst Du Dich vielleicht etwas unter Beobachtung. Mach’ Dir bewusst, dass nicht nur Du Fehler machst, die gesehen werden. Auch Dein Gegenüber macht Fehler. Gemeinsam habt Ihr die Chance, euch weiterzuentwickeln und aus den eigenen Fehlern und denen der oder des anderen zu lernen.

Diese Tipps helfen Dir am Anfang:

• Timebox setzen, die an den Wechsel erinnert
  
• 5 Sekunden-Regel einhalten: 5 Sekunden warten, bis Du den Driver auf Typos hinweist
  
• Micro-Management vermeiden
  

Klar, nicht jede kann mit jedem: Wird die Tandemprogrammierung in Teams neu eingeführt, kann es im Team Konflikte geben. In der Eingewöhnungszeit ist der Output erst einmal etwas niedriger. Auch die gemeinschaftliche Verantwortung für den Code kann zu Problemen führen.

Gerade für Dich am Berufsstart ist ein Match mit einem Senior Developer sinnvoll. Der Senior kennt den Code in- und auswendig und kann Dich gut einarbeiten. Für das gesamte Team ist es wichtig, dass Paare nicht beieinander bleiben, sondern immer wieder gewechselt wird. Zum einen fördert ein Wechsel der Pairings die Zusammenarbeit im ganzen Team, zum anderen verbessert es die Codequalität, wenn verschiedene Mindsets zusammen kommen.