Waarom wil Carl niet pairen?

Spelers: Alice, Bob, Carl.

Decor: Flip-over, post-its, stiften, speelkaarten met de fibbonaccireeks erop.

Scenario: Alice en Bob bespreken hun positieve ervaringen met pair programming in de Sprint Retrospective. Ze stellen voor het vaker te doen. Carl is defensief. “Ik vind het niet fijn als een ontwikkelaar op mijn vingers meekijkt hoe ik code typ.”

– Leg uit, wat is hier aan de hand?

*

Carl wil iets verbergen. – Wat? – Zijn persoonlijke ontwikkelproces. – Of: het gebrek eraan?

Hoe ziet het magische moment eruit waarop requirements worden omgezet in functionaliteit? Doorloop je altijd bepaalde stappen? Laat je je leiden door een richtinggevend idee? Of is elke feature uniek? – je prutst je elke keer richting werkende software.

Dat is een intiem moment, het is iets van jezelf. – Zo denkt Carl, wellicht.

Bob
Wat denk je dat we dan zullen zien?

Alice (sussend)
Ik snap dat het ongemakkelijk is.

*

Carl wil niet laten zien dat hij fouten maakt.

Een junior wil niet constant eraan herinnerd worden hoe weinig hij weet. Een senior wil niet laten merken dat hij het ook niet weet. – Niet willen pairen is ook: sociaal ongemak vermijden.

Natuurlijk, daarmee berooft hij zich van de ervaring zijn collega te zien worstelen. Elke ontwikkelaar maakt fouten. Ik heb mezelf vaak genoeg dood gestaard op een falende test die het gevolg was van gekopieerde code.

“De beste manier om te groeien als softwareontwikkelaar is door Het Bureau te lezen, van J.J. Voskuil. (– Ik kan me niet herinneren dat er in die roman veel samen werd gewerkt overigens.)” — Bob

*

– Of dit: Carl ziet programmeren als een essentieel eenzame bezigheid. Programmeren hoor je in je eentje te doen.

(Hoe is het voor Carl om een GitHub Copilot te gebruiken? Voelt dat als samenwerken of als een tool? Wat zegt dat over zijn kijk op AI – en wat over de onze?)

*

Programmeren, coderen is als schrijven (opnieuw die boekmetafoor!) – dat doe je ook alleen.

Tenzij je een komedie schrijft, dan werkt het samenspel.

Bob
Oftewel: coderen is geen komedie. (De broncode is geen blijspel.)

*

Het is waar dat pair programming iets verandert in de manier waarop je code schrijft. Sommige delen blijven hetzelfde (het typen), andere veranderen (nadenken – hardop nadenken, je gedachtegang communiceren en expliciteren).

*

Sinds ik regelmatig pair, zie ik programmeren niet meer als een eenzame bezigheid. Er zijn nog wel momenten waarop je alleen schrijft, maar ze maken niet de essentie van het werk uit.

*

Nadenken, het probleem begrijpen, is een groter deel van het werk. Het risico bestaat dat dat deel in zuivere eenzaamheid weggedrukt raakt.

De meesten van ons hebben een ander nodig om te kunnen nadenken – goed te kunnen nadenken.

Alice
De aanwezigheid van de ander helpt, niet omdat je dom bent, maar omdat je hersencapaciteit beperkt is.

*

Carl wil niet laten zien dat hij fouten maakt, dat hij zich richting een oplossing klungelt. De uitweg is: fouten, klungelen te omarmen. Je pair inlichten: “Ik ga dit eerst lelijk doen” – en het dan lelijk doen.

Red – green: dat is nog niet het moment waarop je je druk maakt over de integriteit van de code. Dat komt straks, in de refactor. (Zie ook deze blog.) Het is een gewoonte die je je al TDD’end eigen hebt gemaakt: scheid het aanpassen van het gedrag (green) van het aanpassen van de structuur (refactor).

Klungelen is onderdeel van het proces. Het is de stap die voorafgaat aan opruimen.

*

Ik heb nooit (echt?) gepaird zonder Test-Driven Development (TDD), het is een fijne manier om de ontwikkelwerkzaamheden te structureren. Als ik hardop na moet (!) denken, dan heb ik een raamwerk nodig, een verhaal dat mijn gedachten op het juiste spoor houdt.

Woorden alleen zijn niet genoeg, klanken vervliegen maar.

TDD structureert het (samenwerkings)proces. TDD geeft het paar een duidelijk pad: (1) verhelder het probleem met testcases, (2) schrijf een falende test; (3) laat de test slagen, (4) refactor de code – (5) terug naar (1).

*

De eerste implementatie moet de verkeerde implementatie zijn. Anders was ofwel ’t probleem triviaal, ofwel hebben we aan ’t eind niets geleerd.

Fouten maken betekent ook: leren – voor degene die bereid is van fouten te leren.

Alice & Bob (in koor)
Hoe leer je sneller van fouten: alleen of samen?

*

Vergeet nooit dat ontwikkelaars ook mensen zijn.

Carl
ChatGPT is geen ontwikkelaar.

*

Epiloog

Pair programmen is ook: het probleem van samenwerking (Voskuil), de kruising van verschillende gezichtspunten (Arendt) – het moment waarop je ermee geconfronteerd wordt dat jouw blik op de zaken maar een perspectief vertegenwoordigt.

Dat soort reflectie is niet voor iedereen weggelegd – Socrates werd het fataal.

Bob
Stel je voor: pair programmen met Socrates.

Zo’n zweterige ouwe vent. In een toga. Griekse dingen te zeggen. “Ja Socrates!” knikken.

Wat voor code levert dat aan ‘t eind van de dag op?

Carl
De Idee van Goede Code.

Alice
Maar toch: ik garandeer je dat je aan ‘t eind van zo’n sessie met Socrates wijzer bent geworden – al was het maar omdat je weet dat je minder weet dan je dacht.

(Opeens kickt het besef in: dat de vroege dialogen van Plato in een aporie eindigen is een literaire verbeelding van het Idee dat ik weet dat ik niets weet. Einde.)

pair programming · software ontwikkelaar (rol) · sprint retrospective · test-driven development