Kunsten å anmelde

Jeg overdriver ikke hvis jeg sier at vi bruker minst én time om dagen på å gå gjennom hverandres arbeid. Hvorfor så mye? Svaret er enkelt. Gjennom fagfellevurdering opprettholder vi kvaliteten på produktene våre. I tillegg lærer vi mye av det, både som mottakere av tilbakemeldinger og som anmeldere. Men det er ingen enkel oppgave å fullføre en anmeldelse. Du må gi konstruktiv kritikk av kollegenes arbeid, som til dels har krevd blod, svette og tårer. Hvordan gjør du tilbakemeldingene konstruktive og tydelige? Vi diskuterer tre metoder for fagfellevurdering, inkludert vår favoritt.

Løsninger, løsninger, løsninger 

For å optimalisere kvaliteten på arbeidet ditt er det nødvendig med grundige tilbakemeldinger. En måte å gjøre fagfellevurdering på er det jeg kaller vet-alt-metoden. Du gjør koden eller teksten til din egen. Du har sett hvert ord, hver setning, hver interpunksjon eller hver streng flere ganger, og foreslår alternativer for deler som ikke oppfyller kvalitetsstandardene. Noen ganger er dette ledsaget av en forklaring på hvorfor du har endret det;

Tidligere har jeg brukt denne metoden. Se hvordan jeg endret innledningen som kollegaen min, Jeroen, skrev til artikkelen "Why we don't do overtime";

Kjenner du deg igjen i dette: Du er i gang med et prosjekt med en stram tidsfrist. Du jobber overtid for å rekke tidsfristen. Etter noen dager med overtid kommer du sent og trøtt hjem, spiser usunt og går rett til sengs. Neste morgen står du opp tidlig, men er fortsatt ikke uthvilt etter den korte natten. Ta deg sammen, vær sterk og heltemodig og få denne fristen i havn. Du lover deg selv at neste gang skal bli annerledes. At du skal planlegge bedre, gjøre de forbedringene du hoppet over denne gangen. Du skal forlate kontoret i tide og spise med familien eller ta en drink med vennene dine. Men neste gang er det et annet viktig prosjekt med en tidsfrist. Og det gjentar seg.

_{Utkast til introduksjon av artikkelen "Why we don't do overtime", skrevet av Jeroen.}

Jeg foreslo å endre det til dette for å gjøre det mer tiltalende som innledning:

I de fleste jobber forventes det ofte overtid. Vi tror ikke at overtid er løsningen for å få arbeidet gjort og overholde tidsfrister. Om og om igjen. Vi mener faktisk at det virker mot sin hensikt. Derfor avslutter vi arbeidet etter en åttetimersdag, som er en vanlig arbeidsdag i Nederland.

_{Sluttinnledningen til artikkelen "Why we don't do overtime", skrevet av Jeroen.} 

Etter min mening var Jeroens innledning for lang og besto av informasjon som ble gjentatt i brødteksten. Jeg brukte en del tid på å komme opp med en ny innledning, og Jeroen godtok den;

Å erstatte eget arbeid med andres arbeid reduserer følelsen av fullstendig eierskap.

Hva gikk galt? Jeg ga umiddelbart løsningen. Denne måten å evaluere på er ikke bedre enn å bare be om godkjenning. Som mottaker av tilbakemeldingen får du selvfølgelig et glimt av årsaken til endringen. Men ved å ikke skrive det om selv, går du glipp av muligheten til å forbedre skriveferdighetene dine. Dessuten reduserer det følelsen av eierskap når du erstatter ditt eget arbeid med andres. Det føles ikke som ditt eget arbeid lenger. Dessuten kan usikkerheten øke, noe som kan føre til dårligere kvalitet på fremtidig arbeid. Å vite alt-metoden kan også legge til rette for noe helt annet: Du tar tilbakemeldingene for gitt og er ikke lenger kritisk til dem. Det ønsker vi heller ikke, for hver eneste tilbakemelding bør også være en mulighet til å lære. Etter vår mening er det å gå gjennom tilbakemeldingene du får, nøkkelen til din egen utvikling som utvikler eller skribent (front-end eller back-end);

Raskt og skittent 

I den andre enden av spekteret har vi den raske og skitne metoden. Denne går ut på å be kollegaene dine om å godkjenne arbeidet du har gjort for å komme videre til neste trinn i prosessen. Egentlig vil du ikke ha tilbakemelding. Du vil bare ha noe på nettet fordi: 

1. Du har utviklet kodestykket sammen (pair programming). 

2. Det er en så liten endring at ingenting kan gå galt. 

3. Du føler tidspress og kommentarer forårsaker forsinkelse.

4. Du har diskutert løsningen med en kollega og implementert den i etterkant.

Når det gjelder grunn A og B, er den raske og skitne måten tillatt. I vårt daglige arbeid gjør vi det ganske ofte. Det er bare en del av prosessen vår. Men dette gjelder ikke for grunn C, D og andre komplekse oppgaver. Her er det faktisk nødvendig med et ekstra par øyne, for djevelen ligger i detaljene;

Møtes i midten 

De to nevnte fagfellevurderingsmetodene er ikke ideelle med tanke på læring. Derfor er vår elskede metode et sted midt imellom. Etter vår mening er verdifull tilbakemelding fra fagfeller:  

• Er konstruktiv. Vi behandler kolleger og deres arbeid med respekt. 

• Får deg til å tenke. Det hjelper deg til å reflektere over arbeidet ditt og oppmuntrer deg til å tenke på andre løsninger. 

• Består av spørsmål. Hvorfor gjorde du det på denne måten? Hva er grunnen til dette oppsettet? Tenkte du på alternativ X og Y i stedet for bare Z?

• Gjør det mulig for folk å behandle det selv. Det peker dem i riktig retning, uten å gi hele løsningen. Selv om det noen ganger er veldig vanskelig å holde tilbake, spesielt når det gjelder mindre feil. For eksempel: upraktisk navngitte funksjoner og variabler (kode) eller grammatiske feil (innhold). 

Vi ser på tilbakemeldinger fra kollegaer som en samtalestarter. Joan, en back-end-utvikler hos Easy LMS, forklarer: "Jeg avslører ikke hele løsningen, noen ganger bare en del, men jeg diskuterer hovedsakelig hvordan et alternativ kan oppnås ved å refaktorisere. Og noen ganger betyr det at jeg bokstavelig talt setter meg ved siden av noen for å veilede dem, i stedet for å spille ping pong via GitHub eller BitBucket, verktøyene vi bruker til kodegjennomgang."

"Det jeg også gjør noen ganger: Jeg tilbyr flere alternativer og lar det være opp til mottakeren av tilbakemeldingen å avgjøre hvilket alternativ som passer dem best. Det er en hjernetrim fordi flere alternativer må vurderes nøye."

 _{Eksempler på en kodegjennomgangssamtale i GitHub.}

Ifølge Joan er det ikke alltid nødvendig med dialogisk tilbakemelding. Det kommer an på hva slags kode det er snakk om. "Anta at noen ved et uhell har lagt inn en (sikkerhets)sårbarhet i koden, da er det klart at den må fjernes. Jeg vil selvfølgelig forklare hvorfor den bør fjernes, og hvordan du kan unngå den fra nå av, men det er ikke et ideelt tidspunkt for en stor samtale. Da passer vet-det-alt -metoden bedre."

Anna, vår implementeringskonsulent, som har engelsk som morsmål, sjekker alle engelske tekster før de legges ut på nettet, og bruker også konversasjonsmetoden . For bare noen uker siden rettet hun grammatiske feil selv. Nå henviser hun oftere til stilguiden vår, slik at folk kan rette den selv."Og når noen bytter tempus hele tiden, spør jeg dem bare hvilken tid som skal brukes."

Det tar mer tid, men det lønner seg etter hvert 

Jo mer du selv bearbeider tilbakemeldinger, desto bedre blir du, og desto mindre tid tar det å levere riktig kvalitet neste gang.

Denne siste metoden for fagfellevurdering tar mye tid, spesielt i begynnelsen. Det er nok en av grunnene til at vi av og til faller tilbake til gamle, komfortable vaner. Men vi sier til oss selv om og om igjen: Jo mer tilbakemeldingene får deg til å tenke, og jo mer du bearbeider dem selv, jo bedre blir du i jobben din. Da vil det ta kortere tid å levere riktig kvalitet neste gang. Fordelene er todelt. Til syvende og sist vil det også ta mindre tid for anmelderen å vurdere. Selv da er det viktig å fortsette å være kritisk og gi verdifulle tilbakemeldinger, for det hjelper:

• Involver kollegene dine i det daglige arbeidet. Det finnes ingen isolerte øyer av arbeid. 

• Øker tilliten til arbeidet du skaper fordi noen andre synes det er verdt å se på.

• Øker kvaliteten på arbeidet. Det er en langsiktig investering som forhindrer (kostbare) feil. 

Denne artikkelen ble gjennomgått på samtalevis?