I lys av det tidligere fokuset på “imposter syndrom” og hvor stressa utviklere er fra før, vil jeg bare kaste inn et par andre nyanser på hele Code Review-debatten. Fra en utvikler som selv har følt seg superdust etter rare former for code reviews, og som nå selv prøver å balansere kvalitet på kode med et godt arbeidsmiljø.
Mattis har selvsagt helt rett; ja takk gode og utfyllende code reviews (CR), og ja takk par- og mob-programmering. Så lenge CR-ene blir gjort på riktig måte.
Kent Inge Fagerland Simonsen starta jo faktisk innlegget sitt med å skrive litt om “psykologisk trygghet”, og hele innlegget er egentlig veldig godt:
Man burde klare å både ha et positivt og hyggelig arbeidsmiljø, samtidig som man er ærlig i tilbakemeldinger i pull requests (PR).
Jeg tror bare ikke, som Tone Hopsdal skriver, det skjer med mer avstand mellom den som foreslår en endring og reviewer.
Etterlyser mer kritiske PR reviews
Trygghet først
Hopsdal skriver det godt:
“Vi trenger ikke mer avstand. Det vi trenger er trygge team, der alt av endringsforslag er lov å komme med og der alle tørr å si sin mening”.
Men det burde være fullt mulig å komme med helt nye forslag til hvordan en oppgave skal løses i en PR, selv om utvikleren har brukt mange dager på å løse oppgaven. Og det er mulig, uten større avstand eller mindre kritiske code reviews.
Men da må den psykologiske tryggheten i teamet allerede være til stede. For vi har en altfor stor andel utviklere som hver dag sliter med “imposter syndrom”, og det er folk som regelrett gruer seg til Code Reviews.
Korte, kritiske tilbakemeldinger kan fort føles som kjeft, og det kan gå på selvtilliten løs. Da er det ikke bare å kjøre på med masse tilbakemeldinger uten å ha snakket sammen først litt først.
«Det er ikke verre enn å bare være litt hyggelig med hverandre.»
«Rister på hodet» av forslag om mer kritikk
Snakk med hverandre
Det er ikke verre enn å bare være litt hyggelig med hverandre. Bygg hverandre opp, kommenter det som er spesielt bra, gi tilbakemeldinger på en hyggelig måte om du ikke vet hvordan vedkommende du code reviewer tar det.
Det er ikke en motsetning mellom å være hyggelig og å ha utfyllende tilbakemeldinger.
Har du spesielt mye pirk og kommentarer er det faktisk mulig å sende en liten “heads up” på Slack eller Teams, eller nevne det fysisk, at “hey, nå kommer det kanskje til å se ut som jeg kjefter fælt, men det er bare litt forslag til forbedringer jeg fant 😊”.
Se selvfølgelig an personen du skal code reviewe, men det har jeg selv hatt god erfaring med.
Og hvis du ser en helt ny måte å løse en oppgave på og endringsforslagene blir veldig omfattende, så skriv gjerne en liten “Skulle vi diskutert en alternativ løsning jeg har funnet?”.
Review-debatten: - Du må tåle kritikk fra kollegaer!
Ikke alt skal tåles
Holdningen om at to dager utvikling vil være bortkastet fordi man finner en alternativ løsning etter fullført oppgave, er heller ikke nødvendigvis god. To dager utvikling som resulterer i en løsning, så en god teknisk diskusjon og så en ny løsning som er enda bedre vil aldri være bortkastet.
Selvsagt må man være pragmatisk og se an kunden, men det viktigste er jo at oppgaven blir løst best mulig ut i fra de forutsetningene man har.
Man skal ikke kimse av hvor hardt det treffer en utvikler som allerede er dypt nede i impostersyndromet å få kritikk av typen "Ehh? Hva er dette?" eller bare "Stryk hele denne" uten at man allerede har en tone der det er ok. Den verste jeg har fått var av typen “? 😛” uten noe mer kontekst (geipefjesemojien er en av mine største hat-emojis).
Disse eksemplene bidrar hverken til læring og kvalitet eller den psykiske helsen til utvikleren. Det får en bare til å føle seg dum og teit. Det er ikke all form for kritikk man bare skal lære seg å tåle.
Så vær snill og grei, men bruk CR-er til det de er verdt: Et par ekstra øyne som kan oppdage ting som den andre ikke la merke til og komme med nye innfallsvinkler.