"Hvordan bli en bedre utvikler" - dette virker kanskje som en click-baity tittel, men jeg lover deg… uansett hva du jobber med som utvikler, eller hvor erfaren du er så kan også du “bli en bedre utvikler med å følge dette enkle tipset”.
Men selv om tipset i seg selv er enkelt, er det ikke nødvendigvis lett å gjennomføre.
Det er også noe jeg selv jobber med hver dag og ønsker å bli kontinuerlig bedre på.
Christian byttet jobb internt: - Jeg tror dette byttet har gjort meg til en bedre utvikler
Hva er kvalitet?
Før vi kan snakke om hva gode utviklere er må vi snakke litt om kvalitet.
Vi utviklere har en tendens til å sette på skylapper når vi snakker om kvalitet og bare se på en del av det. For noen kan det være høy testdektning. For andre er det at koden går igjennom streng linting. Noen vil kanskje si det er kvalitet om koden er DRY og følger SOLID-prinsippene. Eller kanskje hvor gode benchmarks koden gir. Enkelte kjenner rett og slett hvor elegant koden føles.
Noen av disse tingene kan være indikatorer av en type kvalitet. Men selv om kodekvalitet er viktig, glemmer vi ofte den viktigste metrikken: I hvor stor grad greier vi som team hjelpe sluttbrukere å oppfylle deres reelle behov. Å jobbe med å bli bedre på å oppnå dette er den mest effektive måten å bli en bedre utvikler på.
Denne er vanskeligere å oppnå, da vi ikke bare kan se om en test er rød eller grønn. Det involverer ikke bare oss selv, men det forutsetter at hele teamet drar i samme retning.
På samme måte som vi har verktøy og prinsipper for å veilede oss i arkitektonisk, ikke-funksjonell, kvalitet, har vi også en viktig hammer i kassen når det kommer til å jobbe i team og løse reelle brukerbehov: vår evne til å kjenne på andres følelser. Ja, nettopp, empati.
Ok, ok, kjedelig tenker du kanskje, og føler deg lurt for at jeg holdt løsningen nedenfor en scroll i bloggposten. Men jeg lover deg: ved å øve på empati vil du bli en bedre utvikler. Det er ikke bare et definisjonsspørsmål - du kommer også til å forbedre tekniske ferdigheter.
For å se hvordan vil jeg dele inn i to områder: Empati for sluttbrukere og empati ovenfor team. La oss ta det siste først.
«Det er ikke bare et definisjonsspørsmål - du kommer også til å forbedre tekniske ferdigheter.»
Empati for teamet
I de fleste profesjonelle tilfeller er det mange folk å forholde seg til. Alle har ulike tanker, meninger og styrker. For å dra nytte av de styrkene må vi kunne spille sammen for å lage noe som er større enn våre individuelle lokale toppunkt. Vi må bruke innsats og empati.
Det er lett å avfeie andres uenighet som “de vet ikke bedre” eller “de er bare vanskelige”. Om vi går åpent inn i diskusjoner kan vi se situasjonen fra andres ståsted og da få en ny forståelse for hvorfor andre gjør som de gjør.
Å se problemstillinger fra andres synspunkt er vanskelig, men her er noen eksempler på hvordan vi kan gjøre det. Konkrete eksempler kan hjelpe oss gjenkjenne situasjoner hvor empati som verktøy er nyttig:
- "Jeg gidder ikke ta den høyest prioriterte oppgaven for den er kjedelig."
Hvor ofte har du ikke sett en oppgave øverst på TODO-listen og tenkt: “ah, så mye manuelt” eller “det er en bug som er vanskelig å reprodusere”. Oppgaven under er en morsom ny feature. Hvor fristende er det ikke da å hoppe over? En kjedelig oppgave forsvinner ikke av seg selv. Noen andre på teamet må ta den. Det kan godt være noen andre liker oppgaven bedre, men sjansen er stor for at andre syns den er like kjedelig. Med åpen dialog i teamet om slike oppgaver er det enklere å ikke få en skjevfordeling av kjedelige oppgaver. En god utvikler snakker åpent med teamet, og tar sin del av byrden for kjedelige oppgaver. - "Det funker for meg, du får bare lete videre på din side."
Vi vet alle at vi ikke skal ha siloer, men samtidig oppstår de ofte i en eller annen form. I kommunikasjonen mellom ulike lag kan det skje feil. Er det feil på min side eller er det feil på din side? Det er lett å tenke “feilen er på din side, alle mine tester er grønne”. Det er lite som skaper så mye frustrasjon og splid som lite imøtekommende kolleger. Vi må samarbeide om å finne hvor feilen er. Det hjelper ikke om din side er feilfritt, om det feiler en annen plass. Oppgaven er ikke ferdig før den er ute i produksjon. En god utvikler vet at vi er ansvarlig for leveransen sammen og at en leveranse er først komplett når det gir effekt hos en sluttbruker. - Jeg har ikke tid til dette akkurat nå, du får klare deg selv".
Enten det er hjelp til feilsøking, gjennomgang av en PR, eller å svare på spørsmål. Det er lett å ha skylapper på å gjennomføre “egne” oppgaver på bekostning av andres–i en vrangforestilling om at det våre egne oppgaver er viktigere. Dette kjenner vi også igjen fra den myteomspunnede 10x utvikleren. Utvikleren som tilsynelatende gjør 10 ganger så mye arbeid som oss andre. Ofte ser vi heller at 10x utvikleren er et produkt av skjevfordelt byrde i et team. De må fikse feil de selv har innført som en del av cowboyvirksomhet som igjen får de til å se produktive ut. 10x utvikleren fokuserer mer på å gjøre ting selv enn å få andre til å kunne være effektive. 10x utvikleren er ofte en usynelig flaskehals maskert som produktivitet. En god utvikler vet at det er teamets totale leveranse og flyt som gjelder, ikke individets. - Jeg vil sikre mitt eierskap til oppgavene, slik at jeg blir uunværlig".
Dette er åpenbart en klisje. Men det er klisjeer for en grunn. Enten det skjer ufrivillig eller frivillig er det et stort problem for både team og sluttbrukere. Ingen er garantert til å alltid være tilgjengelig. Vi kan bli syke, bytte jobb, være opptatte eller bli “truffet av trikken”. Hvis eierskapet ikke er godt nok delt med andre vil konsekvensene være store, og både teamet og sluttebrukere må ta kostnaden. De må betale for vår egosime. Dersom vi blir borte må teamet ta over oppgaver som vi må holde i. En god utvikler sørger for kontinuerlig delt eierskap på tvers av teamet.
- Et team skal fungere som "we, not me"
Empati for sluttbruker
Alle har brukere. Enten de er ute i samfunnet eller som konsumenter av tjenester og API-er. Både interne og eksterne sluttbrukere. Brukere er hele grunnen til at programvare eksisterer. Derfor må vi ta brukerens perspektiv inn i måten vi jobber på.
Ofte sier vi “eat your own dogfood”. Dette som en metafor for at vi bruker våre egne løsninger og derfor representerer sluttbrukere på en bedre måte. Jeg syns ikke dette er nok. Folk er forskjellige. Har forskjellige begrensninger, tankesett, bakgrunner, hverdager og hva enn det skal være. Å bruke oss selv, IT-kyndige utviklere med intrikat kjennskap til både domenet og løsningen, som representanter er en sikker metode for å ende opp med forutinntatt programvare. Vi må ta inn over oss hele bildet av målgruppen.
En måte å danne seg et bedre bilde, er å bygge empati for brukere ved å aktivt delta på brukertester, være koblet på support, eller observere bruk i ekte situasjoner. Det kan være smertefullt, men uvurderlig. Noen ganger liker jeg også å gjøre en øvelse hvor teamet beskriver personer de lager løsninger for. Ikke personas (hypotetiske personer), men ekte personer som får en ekte påvirkning av det vi gjør. Da blir det enklere å mane frem empati ved behov.
«Utvikling handler om kommunikasjon. Hver dag. Hele tiden.»
Selv om dette er abstrakt, utartes det som konkrete tilfeller i hverdagen. Dette er eksempler på situasjoner hvor jeg har erfart at empati med brukeren har økt kvaliteten på løsningen og gjort meg til en bedre utvikler i samme slengen:
- "Jeg slurver i feilhåndtering fordi det er kjedelig".
I alle former for utvikling er det en ting vi må forholde oss til, uansett hvilket språk eller plattform du bruker. Vi må forholde oss til uventet utfall eller feil. Da står vi ovenfor et valg: Håndtere det med god brukerinvolvering og recoverability eller bare ignorere det. Brukerorientert feilhåndtering er tidkrevende og krever ofte mye tilpasning og testing, men å forbedre det noe kan være enkelt. Vi klarer ikke nødvendigvis å gjøre det perfekt, men med litt innsats og empati for brukeren kan vi gjøre det mye bedre enn Ukjent feil oppsto, prøv igjen eller bare logging. En god utvikler setter seg inn i sluttbrukers situasjon og hjelper de igjennom uventede situasjoner. - "Jeg tar for lett på kommunikasjon".
Utvikling handler om kommunikasjon. Hver dag. Hele tiden. Enten vi kommuniserer med team, sluttbrukere, organisasjon eller oss selv i fremtiden. Vedlikeholdbarhet er et resultat av god kommunikasjon med tydelig kode eller god dokumentasjon. En god utvikler bruker ekstra tid på å sikre god kommunikasjon. - "En god utvikler fokuserer ikke på egne preferanser, men tilpasser seg andre og fokuserer på verdien til brukere".
Vi kjenner igjen det. Følelsen av å skrive elegant kode. Når du ser brikkene falle på plass og det bare kjennes digg ut. Men følelsen er høyst subjektiv, og følelsen kommer ofte når vi føler oss smarte. Men smarhet og kløkt kan gjøre det vanskeligere for andre og for oss selv i fremtiden. Dette handler også om kommunikasjon. Verre er det når bruker tid på å refaktorisere fungerende kode som allerede gir verdi for sluttbrukere. Bare for at vi selv skal føle oss bedre. Selv om refaktorisering er en viktig oppgave for vedlikeholdbarhet er refaktoriseringer for egen subjektiv vinning busy-work. Refaktorisering av egen kode i en Pull Request er selvfølgelig fint, men å gå inn og totalt skrive om andres pull requests for at de ikke er på sin egen stil er ikke like bra. Det har ringvirkninger som gjør at vi får mye og gjøre og det har negative konsekvenser på å levere faktisk kvalitet og bistå team. En god utvikler fokuserer ikke på egne preferanser men tilpasser seg andre og fokuserer på verdien til brukere. - "Jeg tar snarveier på feil grunnlag".
Snarveier kan være nyttige og vi hører ofte om fordelene av en “lazy developer”. Eksempler på positiv lathet kan være å ikke fokusere på vedlikeholdbarhet om vi snakker om en midlertidig løsning. Noen ganger kan vi derimot ende opp med å ta snarveier for vår egen del, eksempelvis kun kjører deploys lokalt fremfor å dokumentere eller sette opp automatisk utrulling eller kommenterer ut tester som ikke henger med på refaktorisering. Det kan også være at du kommer over kode som er feil i koden du er innom. Her er det nasjonalpark-regler som gjelder: vi etterstreber å etterlate kode i bedre forfatning enn vi fant den. Dette har innvirkning på sluttbrukere og team. Selv om noe latskap kan være bra vil en god utvikler identifisere når snarveier er til andres vinst, ikke for sin egen feilslåtte latskap. - "Jeg slurver når jeg implementerer ting".
Det er så lett. Å bare stole på en grønn happy-path test. Å ikke dobbeltsjekke design med faktisk implementasjon. Å ikke teste på ulike plattformer i ulike nettlesere. Det er en sannhet i uttrykket at “assume makes an ass out of u and me”–hvor u er sluttbrukere og me er utvikleren. Vi optimaliserer for rask utrulling og feilfiks for vi vet at vi ikke lager perfekte løsninger. Fremdeles kan vi ikke overlate ansvaret om å fange opp våre slurvefeil til andre. Ting som å sjekke paddingen som er i designet, se at typografien stemmer, eller kontrollere at API-et gir rett feilmeldinger. Mye av feil vi gjør kan sjekkes om vi bare tar oss tid til å faktisk validere. En god utvikler validerer arbeidet sitt for å unngå slurvefeil fremfor å overlate det til andre til å fange opp.
Rolfs beste tips for god dokumentasjon: - I dag er dette ekstremt viktig
En god utvikler kjenner brukeren og teamet
For å kjenne på konsekvensene av sine egne feil og mangler, er empati et nyttig verktøy. Vi må tenke på reell kvalitet som sluttbrukeres evne til å gjøre ønsket oppgave med ønsket effekt. Vi må tenke på reell kvalitet som teamets evne til å levere dette på en god måte.
For å oppnå dette må vi se ting fra andres perspektiv, kommunisere godt og bygge relasjoner. Det er enkelt på papiret, men krever kontinuerlig arbeid. Samtidig er return of investment stor. Dette er en sikker måte å skape kvalitet over tid.
Med å fokusere på empati vil du også opparbeide deg mer tekniske ferdigheter. Om du tar i oppgaver som kan være mer gravearbeid så lærer du nye ting, om du håndterer feil bedre blir koden bedre, og om du jobber med slurvefeil så blir det mer tid til å levere faktisk nytte.
En god utvikler fokuserer på outcome fremfor output. Bedre outcome får vi med brukerfokus og samskaping. Og empati er verktøyet og prinsippet som skal drive oss til å oppnå det.
Hvilke tilfeller har du tatt deg selv i å enten slurve, ta feil snarveier, nedprioritere andre, nedprioritere brukeren, eller bare fokusere feil? Når tenker du empati kunne ha gjort deg til en bedre utvikler? Send en respons eller send en tweet på @mikaelbrevik.
Takk til Christian Brevik, Nikolai Norman Andersen, og Anders Njøs Slinde.
