De kunst van het recenseren

Ik overdrijf niet als ik zeg dat we minstens een uur per dag besteden aan het nakijken van elkaars werk. Waarom zoveel? Het antwoord is duidelijk. Door collegiale toetsing behouden we de kwaliteit van onze producten. Bovendien leren we er veel van als feedbackontvanger en -beoordelaar. Maar het voltooien van een review is geen sinecure. Je moet constructieve kritiek leveren op het werk van je collega's, en dat heeft soms bloed, zweet en tranen gekost. Hoe maak je feedback constructief en duidelijk? We bespreken drie peer review methoden, waaronder onze favoriet. 

Oplossingen, oplossingen, oplossingen 

Om de kwaliteit van je werk te optimaliseren, is diepgaande feedback nodig. Een manier om peer review te doen is wat ik de weet-allesmethode noem. Je maakt je de code of tekst eigen. Je hebt elk woord, elke zin, elke interpunctie of elke string meerdere keren gezien en stelt alternatieven voor voor delen die niet aan de kwaliteitseisen voldoen. Soms gaat dit gepaard met een uitleg waarom je het hebt veranderd. 

In het verleden heb ik deze methode gebruikt. Kijk eens hoe ik de inleiding van mijn collega Jeroen voor zijn artikel "Waarom we niet overwerken" heb veranderd;

Herken je dit: je zit in een project met een strakke deadline. Je maakt extra uren om de deadline te halen. Na een paar dagen overwerken kom je laat en moe thuis, eet je ongezond en ga je meteen naar bed. De volgende ochtend sta je vroeg op, nog steeds niet fris van de korte nacht. Verman jezelf.  Wees sterk en heldhaftig en haal deze deadline. Je belooft jezelf dat het de volgende keer anders zal gaan. Dat je beter zult plannen, die verbeteringen zult aanbrengen die je deze keer hebt overgeslagen. Dat je op tijd het kantoor verlaat en met je gezin gaat eten of iets gaat drinken met je vrienden. Alleen de volgende keer is er weer een belangrijk project met een deadline. En het herhaalt zich.

_{Ontwerptekst van het artikel "Waarom we niet overwerken", geschreven door Jeroen.}

Ik stelde voor om het zo te veranderen om het aantrekkelijker te maken als inleiding:

Bij de meeste banen wordt meestal overwerk verwacht. Wij geloven niet dat overwerk de oplossing is om werk gedaan te krijgen en deadlines te halen. Steeds weer opnieuw. We denken zelfs dat het averechts werkt. Daarom ronden we dingen af na een dag van acht uur, een normale werkdag in Nederland. 

_{Eindredactie van het artikel "Waarom we niet overwerken", geschreven door Jeroen.} 

Naar mijn mening was Jeroen's inleiding te lang en bestond deze uit informatie die herhaald werd in de hoofdtekst. Ik heb veel tijd besteed aan het bedenken van een nieuwe inleiding en Jeroen heeft deze geaccepteerd;

Je eigen werk vervangen door het werk van anderen vermindert het gevoel van volledige eigendom.

Wat ging er mis? Ik heb meteen de oplossing gegeven. Deze manier van reviewen is niet beter dan gewoon om goedkeuring vragen. Natuurlijk krijg je als ontvanger van feedback een glimp te zien van de reden voor de verandering. Maar door het niet zelf te herschrijven, mis je de kans om je schrijfvaardigheid te verbeteren. Bovendien vermindert het vervangen van je eigen werk door andermans werk het gevoel van volledige eigendom. Het voelt niet meer als jouw werk. Bovendien kan hun niveau van onzekerheid toenemen, wat kan leiden tot een slechtere kwaliteit van toekomstig werk. De weet-alles methode kan ook iets heel anders in de hand werken: je neemt de feedback voor lief en bent er niet meer kritisch op. Dit is iets wat we ook niet willen, omdat elk punt van feedback ook een leermoment zou moeten zijn. Naar onze mening is het beoordelen van de feedback die je krijgt de sleutel tot je eigen ontwikkeling als (front-end of back-end) ontwikkelaar of schrijver. 

Snel en vies 

Aan de andere kant van het spectrum heb je de snelle en vuile methode. Deze bestaat uit het vragen aan je collega's om het werk goed te keuren dat je hebt gedaan om naar de volgende stap van het proces te gaan. Eigenlijk wil je geen feedback. Je wilt gewoon iets online hebben omdat: 

1. Jullie hebben het stuk code samen ontwikkeld (pair programming). 

2. Het is zo'n kleine wijziging dat er niets mis kan gaan. 

   Je voelt tijdsdruk en opmerkingen zorgen voor vertraging.

   Je hebt de oplossing besproken met een collega en daarna geïmplementeerd.

In het geval van reden A en B is de snelle en vuile manier toegestaan. In ons dagelijks werk doen we dat heel vaak. Het hoort gewoon bij ons proces. Maar dit geldt niet voor reden C, D en andere complexe taken. In feite is een extra paar ogen best nodig, want de duivel zit in de details. 

Ontmoet elkaar in het midden 

De twee genoemde peer review methodes zijn niet ideaal als het gaat om leren. Daarom zit onze geliefde methode ergens in het midden. Naar onze mening is waardevolle peer feedback:  

• Is constructief. We behandelen collega's en hun werk met respect. 

• Zet je aan het denken. Het helpt je na te denken over je werk en zet je aan tot het bedenken van andere oplossingen. 

• bestaat uit vragen. Waarom heb je het op deze manier gedaan? Wat is de reden voor deze opstelling? Heb je aan optie X en Y gedacht in plaats van alleen Z?

• Maakt het mogelijk voor mensen om het zelf te verwerken. Het wijst ze in de juiste richting, zonder de hele oplossing te geven. Hoewel het soms erg moeilijk is om je in te houden, vooral als het om kleine fouten gaat. Bijvoorbeeld: onhandig benoemde functies en variabelen (code) of grammaticafouten (inhoud). 

Wij zien feedback van collega's als een conversatiestarter. Joan, een Back-End Developer bij Easy LMS, legt uit: "Ik onthul niet de hele oplossing, soms slechts een deel, maar ik bespreek vooral hoe een alternatief kan worden bereikt door te refactoren. En dit betekent soms gewoon letterlijk naast iemand gaan zitten om ze er doorheen te leiden, in plaats van pingpong te spelen via GitHub of BitBucket, de tools die we gebruiken voor code-reviews."

"Wat ik soms ook doe: Ik bied meerdere alternatieven aan en laat het aan de feedbackontvanger over om te beslissen welk alternatief het beste bij hem of haar past. Het is een hersenkraker omdat meerdere opties zorgvuldig moeten worden overwogen."

_{Voorbeelden van een code review gesprek in GitHub.}

Volgens Joan is conversational feedback niet altijd nodig. Het hangt af van het type code. "Stel dat iemand per ongeluk een (beveiligings)kwetsbaarheid in de code heeft gezet, dan is het duidelijk dat die verwijderd moet worden. Natuurlijk zal ik uitleggen waarom het verwijderd moet worden en hoe je het voortaan kunt vermijden, maar het is geen ideaal moment voor een groot gesprek. Dan past de weet-alles methode beter."

Anna, onze implementatieconsultant en native speaker Engels, controleert alle Engelse teksten voordat ze online gaan en past ook de conversation method  toe. Een paar weken geleden corrigeerde ze zelf nog grammaticafouten. Nu verwijst ze vaker naar onze Stijlgids, zodat mensen het zelf kunnen oplossen. "En als iemand steeds van tijd wisselt, vraag ik gewoon welke tijd er gebruikt moet worden."

Kost meer tijd, maar het loont uiteindelijk 

Hoe meer je zelf feedback verwerkt, hoe beter je wordt en hoe minder tijd het kost om de volgende keer de juiste kwaliteit te leveren.

Deze laatste methode van peer review kost veel tijd, vooral in het begin. Dat is waarschijnlijk een van de redenen waarom we soms terugvallen in onze oude, comfortabele gewoontes. Maar we zeggen steeds weer tegen onszelf: hoe meer de feedback je aan het denken zet en hoe meer je zelf verwerkt, hoe beter je wordt in je werk. Dan kost het minder tijd om de volgende keer de juiste kwaliteit te leveren. De voordelen zijn tweeledig. Uiteindelijk zal het de beoordelaar ook minder tijd kosten om te beoordelen. Zelfs dan is het belangrijk om kritisch te blijven en waardevolle feedback te geven omdat het helpt bij:

• Het betrekken van je collega's bij je dagelijkse werk. Er zijn geen geïsoleerde werkeilanden. 

• Het vertrouwen vergroten in het werk dat je maakt omdat iemand anders het de moeite waard vindt om ernaar te kijken.

• De kwaliteit van het werk verbeteren. Het is een langetermijninvestering die (kostbare) fouten voorkomt. 

Dit artikel werd besproken op de conversatiemanier?