Psykologisk trygghet på arbeidsplassen er avgjørende for en organisasjon sin evne til å nå ambisiøse mål. Dette temaet gjentas ofte i den moderne litteraturen innen alt fra ledelse av teknologiorganisasjoner til devops.
En annen kritisk suksessfaktor er en organisasjon sin evne til kontinuerlig læring. Og én måte ansatte i teknologiorganisasjoner lærer av hverandre, er gjennom kritikk av hverandres kode gjennom pull request (PR) reviews.
«Mer kritiske tilbakemeldinger kan føre til mer omfattende forbedringer.»
Rull request review
PR er en viktig del av mange utvikleres hverdag. En sentral egenskap ved PR-er er å muligheten til å få tilbakemeldinger og godkjenning (review) på en PR før den legges til i hovedgrenen av programvarens kode (merge).
Slike reviews er en unik mulighet til å forbedre kode før den merges, og også til å lære av sine med-utviklere og diskutere fordeler og ulemper med de valgene man tar.
Samtidig, i en organisasjon, kan PR reviews også bidra til ansatte sin psykologiske trygghet ved å sørge for at tilbakemeldingene gis på en hyggelig, trygg og selvtillit-byggende måte.
Guide: - Dette gir raskere utvikling
Akademisk peer review
I akademiske kretser finnes det en lignende praksis som brukes til å godkjenne artikler for publisering i journaler og konferanser. Denne praksisen kalles peer review.
I en peer review-prosess gis artikkelen til et lite antall eksperter innen feltet. Disse går igjennom artikkelen uavhengig av hverandre og bedømmer om den har høy nok kvalitet til å bli antatt.
En typisk akademisk peer review vil gjerne ha disse attributtene:
- Anonymiserte reviewers ("Reviewer 1", "Reviewer 2"...)
- Ofte dobbelt blinde reviews
- Oppsummering av bidraget
- Litt om det som taler for godkjenning (“[The tool] seem to be working and the effort does seem to have longer term benefit.”)
- Detaljert beskrivelse om alt som er feil og mangelfullt ("Proposal: strong reject. Detailed review: see attached PDF")
- Lang liste over redaksjonelle feil og mangler
Mens en typisk PR review kan inneholde disse elementene:
- Navn til original utvikler, alle bidragsytere og reviewer
- Automatisk genererte rapporter om kvalitet og tester
- Endringshistorikk
- Noen forslag til mindre redaksjonelle endringer som ofte kan automatisk inkorporeres
- En godkjenning som "Ser bra ut, bare merge når du er klar :)" eller en kommentar som "lgtm”
«En annen viktig forskjell er mengden arbeid som legges i både forslagene og reviewerne.»
Grundigere, ærligere
Begge review-formene har som mål å øke kvalitet ved å introdusere et godkjenningsledd.
De viktigste forskjellene kommer fra avstanden mellom den som sender inn et forslag og de som godkjenner det. En annen viktig forskjell er mengden arbeid som legges i både forslagene og reviewerne.
I min erfaring ligger de største forskjellene mellom PR og akademiske peer reviews i detaljnivået og tonen i tilbakemeldingene.
En PR review består gjerne av en kjapp godkjennelse av typen "lgtm" eller et avsnitt eller to med tekst, sammen med noen inline-kommentarer i koden (vanligvis om kode-stil).
Samtidig, i en peer review, vil minst én av reviewerne gå grundig til verks, liste ut alle store og små forbedringspunkter over flere avsnitt og ofte sider. Peer reviewer er også like grundige for bidrag som til slutt både blir godkjent og avvist.
Vil vekk fra korte, strenge Jira-oppgaver, til mer prat om behov og følelser
Hyggelig tone vs. læring
Det kan være sammenheng mellom en hyggelig tone i PR reviews og tapte muligheter for grundig læring og enda høyere kvalitet i endringer.
Mer kritiske tilbakemeldinger kan føre til mer omfattende forbedringer. Kommentaren under, som et eksempel, førte ikke til forbedret kode eller læring for den som sendte inn endringen:
"Testet lokalt, virker fint så langt! ✨"
Denne PR reviewen førte til at informasjon om endringen ble spredd og gav også en viss sjekk av kvaliteten. Den var altså langt fra meningsløs, men kunne kanskje vært enda nyttigere.
Reviews fra akademiske peer reviews er sjeldent like hyggelige å motta. Under er et par eksempler på dette:
- "The analysis is too biased"
- "The experimental setup is not described clearly"
- "The paper has several weaknesses and the work presented here is immature for publication"
- "However, this is not a strong technical paper"
Slike reviews kan være særlig tunge å få når man har brukt opptil 6 måneder på å utføre og beskrive forskningen etter beste evne. Likevel gir det motivasjon til å forbedre kvaliteten på både det skriftlige og innholdet til neste forsøk.
Hygge må ikke overskygge
Mange vil argumentere for at en hyggelig tone i PR reviews er avgjørende for å opprettholde et positivt arbeidsmiljø og unngå konflikter i teamet.
Dette er gode og viktige poeng.
Likevel bør ikke hensynet til hygge på jobben overskygge behovet for læring og kvalitet.
En mulig måte å oppnå balanse mellom behovet for å beholde hyggelig arbeidsmiljø og kvalitet, kan være å eksperimentere med metoder for å øke avstanden mellom den som foreslår en endring og reviewer. Mulige metoder for dette kan være anonyme reviewere, bruke LLM-modeller eller personer utenfor teamet som "Reviewer 2".
