(Artikkelen ble først publisert 26. april 2022)
Har du noen gang vært i et prosjektmøte som ble litt surt?
Kanskje det ble en krangel om å bruke teknologi X eller teknologi Y (Spring, anyone)? Kanskje noen ble anklaget for å ikke ta sikkerhet, arkitektur eller vedlikeholdbarhet alvorlig?
Det er ikke akkurat snakk om liv eller død, men temperaturen kan bli høy allikevel. Ofte har vi fokuset hva vi skal og bør og det blir en drakamp. Men det finnes bedre innfallsvinkler
I påsken leste jeg en bok om konflikthåndtering. "Non-violent communication" er en innfallsvinkel som har blitt benyttet i konflikter fra samlivsproblemer, til arbeidslivforhandlinger, til kriminalomsorg, til krigshandlinger.
Grunnprinsippene passer for så vidt godt til programmering også.
Årets stemme: - Kodere må delta i samfunnsdebatten
Bruker tvang og skyldfølelse
Teknikken går ut på å omformulere fra å bedømme andres og egne oppførsel til å observere hvilke følelser og behov som kommer til uttrykk. Kjernen går ut på å uttrykke seg i form av observasjoner, følelser, behov og forespørsel.
Et arketypisk uttrykk kan være på formen "når jeg [ser, hører…] så føler jeg [...] fordi jeg trenger [behov]. Vil du være villig til å [...]?"
Et eksempel fra boka er "Når jeg ser at du skriver på telefonen mens vi snakker. Jeg føler meg oversett og har behov for å snakke med noen. Vil du være villig til å legge fra deg telefonen i ti minutter?" En mer instinktiv måte å si det på kunne være "Hvorfor overser du meg alltid?"
Det er lett å se at den ene måten å kommunisere vil ha bedre sjanse for en meningsfull dialog.
Ord som “alltid”, “aldri”, “må” og “burde” er tegn på at vi bruker tvang og skyldfølelse som en ramme for det vi snakker om
«Kodeformatering-regler kan føles vilkårlige, men kommer også fra behov.»
Alle utviklere er voldelige
Hvordan snakker vi til hverandre når vi jobber med programmering?
"Du har fått Jira-oppgaven med å skrive om fra native mobilapp til web" eller "pull requesten din har blitt avvist fordi den ikke følger kodeformatteringsreglene" eller "alle oppgaver skal gå gjennom code review" eller "oppgaven ble ikke godkjent fordi den brukte localstorage i stedet for indexeddb som sto i specen" eller "vi skal skrive om til å kjøre på Kubernetes"
Slik jeg forstår non-violent communication er alle disse utsagnene "voldelige". I filosofien bruker man "violent" som nært beslektet til "coercisive" eller "påtvunget". Utsagnene i forrige avsnitt er alle formulert i form av krav og bedømmelse.
Men alle avsnittene over kommer fra situasjoner der de har gode grunner. Det kunne ha vært sagt med god grunn i mitt nåværende prosjekt. Men når du leser utsagnene, så forstår du neppe hvor de kommer fra.
Det kunne være en interessant øvelse å analysere behovene bak utsagnene:
- Vi må slutte å omtale utviklere som nerder, og programmering som livsstil
#1: Jira-oppgaven
"Du har fått Jira-oppgaven med å skrive om fra native mobilapp til web".
Når jeg får en oppgave tildelt i Jira, føler jeg meg avmektig. Jeg har behov for å være med å sette rammene for mitt arbeid og jeg vil gjerne diskutere og skrive mine egne oppgaver. Denne omskrivingsoppgaven kom fra observasjonen at vi har både brukere i felt og brukere som sitter ved en operasjonssentral på PC (observasjon).
Vi utviklet først en applikasjon for native og en webapplikasjon. Men jeg er redd (følelse) for at funksjonaliteten vil divergere og at vi ikke vil ha nok arbeidskraft til å lage to gode applikasjoner. Vi ønsker at brukerne i felt og på operasjonssentral skal ha tilnærmet lik opplevelse (behov).
Kan vi skrive om native-appen til web? (Forespørsel)
«Ved å fokusere på følelser og behov kan vi ha en bedre samtale»
#2: Pull request-en
"Pull requesten din har blitt avvist fordi den ikke følger kodeformateringsreglene".
Når koden min ble avvist på grunn av vilkårlige regler (observasjon) så følte jeg mangel på mestring (følelse). Jeg vil gjerne at vi finner mekanismer der jeg ikke må gå ekstra runder for å fullføre arbeidet (behov). Kan vi parprogrammere en dag i uka slik at vi får en felles forståelse for hvordan koden bør se ut? (forespørsel).
Kodeformateringsregler kan føles vilkårlige, men kommer også fra behov. Når jeg ser at endringsdiffene blir store fordi vi formaterer den samme koden frem og tilbake (observasjon) så blir jeg frustrert og forvirret for jeg ser ikke om endringen er liten eller stor (følelse). Jeg ønsker at kun linjene som faktisk har en endring blir endret (behov).
Kan vi bruke prettier til å formatere koden vår så den blir konsistent? (forespørsel)
- Vi hadde alle tjent på å senke tempoet et par hakk
#3: Indexeddb
Vi tar en til, et typisk arkitekturkrav:
“Frontend-kode skal bruke Indexeddb og ikke localstorage”.
Om vi omformulerer dette til “non-violent communication” kan det kanskje høres noe slikt ut: Localstorage i browseren kan skalere dårlig når det blir mye data (observasjon). Jeg er redd for at brukerne skal oppleve programmet som tregt (følelse). Dersom vi bruker indexeddb kan vi oppnå bedre ytelse (observasjon).
Dette eksempelet avdekker noen viktig poeng: Er det virkelig sånn at localStorage er tregt? Hvor mye data må til for at det skal bli tregt? Det må man ofte teste for å finne ut. Kanskje kravet bare er av akademisk karakter? Kanskje noe data hører bedre hjemme i localStorage mens annen data hører best hjemme i Indexeddb? Når vi fokuserer på observasjonene og behovene kan vi ha en bedre samtale.
Som arkitekt opplever jeg at når det er mange teknologier i bruk, så mister jeg og andre kontrollen og føler oss bare kompetente på deler av koden (observasjon og følelse). Jeg har lyst til å standardisere på færre teknologier, så kanskje vi kan bruke Indexeddb hele tiden så vi slipper å ha to? (behov og forespørsel)
Synes kontekstbytting er belastende: - Må være lov å be om å få kode uforstyrra
Kan få til en bedre samtale
Ved å fokusere på følelser og behov kan vi ha en bedre samtale.
Hvor mye innsats trenger en programmerer som kan Indexedb for å mestre localStorage? Er det egenskaper ved localStorage som gjør hjelper oss mer enn denne lærekostnaden og når?
Det å observere, lytte og uttrykke seg med fokus på observasjoner, følelse, behov og forespørsler er lett i teorien, men en konstant jobb i praksis. Selv om jeg har lest om dette flere ganger nå havner jeg stadig i klammeri på hjemmefronten og det hender debattene på jobben får litt hardere tone.
Da er det nyttig å ha et verktøy å gripe etter for å se situasjonen på andre måter, selv om det ikke alltid lykkes. Eksemplene jeg har beskrevet her er naturligvis uperfekte og ufullstendige for å forstå “non-violent communication”, men jeg håper det gir rom til ettertanke.
Også på jobben bør vi omfavne innsikt i behovene bak oppgavene vi løser og ta hensyn til våre egne og våre kollegaers behov som vil gjøre jobben mest meningsfull. Å lytte etter språk preget av tvang fra seg selv og andre kan gi oss en arbeidsmåte som vi kunne kalle “ikke-voldelig software-arkitektur”.
