I lys av den siste ukas debatt omkring kontroversielle tolkninger av hva “ekte” programmering er har det kanskje vist seg nødvendig å utdype hva man legger i ordet “programmering” før man beveger seg videre.
- Dårlige utviklere tror jobben er ferdig klokka fem
Makter du å få en datamaskin til å gå beep-boop, automatisere noen lys i hjemmet eller få en formel i et regneark til å produsere fornuftige tall er du på et eller annet vis en programmerer i mine øyne.
Programmering har mange formål, hver med tilnærminger som egner seg bedre enn andre. La oss heller vise hverandre hvordan vi effektivt løser problemer slik at vi kan vurdere og ta våre egne valg.
Hva er empati?
Empati handler om innlevelse i andre situasjoner enn ens egen.
Empati er ikke synonymt med forståelse. Empati er bygget på forståelse, men krever også at man anvender forståelsen på noe vis. Man må ikke bare forstå, men også vise forståelse.
Konkrete handlinger kan være empatiske. Valgene vi tar kan basere seg på empatiske vurderinger. Empati kan drive måten vi omgår oss med andre.
Empati er høyst aktuelt innenfor programmering.
«Den beste koden er den vi slipper å skrive.»
Programmering er for mennesker
Programmering en kunst svært vanskelig å mestre. For selv om programmer er til for å instruere maskiner, er strukturerte programmer — før de kvernes i filler av en kompilator — først og fremst et kommunikasjonsmiddel mellom mennesker.
Hjernen vår er en begrenset ressurs. Systemer vokser fort til det punktet der koden i sin helhet ikke lenger får plass i hodet til én person.
Vi lager abstraksjoner ved å gjemme kompleksitet bak en fasade: et variabelnavn, en funksjon, en modul, en mikrotjeneste, et API, et brukergrensesnitt.
Da må vi også reflektere rundt hvem abstraksjonene er bygget for:
- Koder vi kun for rekreasjonell underholdning?
- Bygger vi en tjeneste eller app med et grensesnitt tiltenkt sluttbrukere?
- Tilbyr vi et bibliotek for andre utviklere?
- Bygger vi systemer i felleskap eller alene?
Dette er spørsmål vi bør stille jevnlig.
Forstå problemet først
Jobben vår handler da om å oversette reelle behov til kode. God problemforståelse sørger for at vi utvikler funksjonaliteten med mest verdi for brukere og gjerne ikke mer. Den beste koden er den vi slipper å skrive.
Inkrementelle endringer vi kan validere vil begrense at unødvendig kompleksitet hoper seg opp. Noen ganger kan vi tilpasse eksisterende løsninger til brukernes behov med minimalt med endringer. Er vi heldige kan vi fjerne eller forenkle noe.
Dessverre er det vanskelig å takke seg selv for mangel på kompleksitet unngått over tid.
«Å skrive enkel kode er definitivt ikke lett.»
- Rare, utdaterte og gatekeepende holdninger
Enkelt er ikke lett
Empati er nyttig for utviklere seg i mellom. Vi skriver kode basert på de erfaringene vi har — det som er enkelt for noen kan være komplisert for andre.
Erfarne programmerere blir fristet å bruke avansert teknikker eller spesialiserte biblioteker. Dette kan medføre et betydelig kompleksitets-overhead for nykommere. Uerfarne utviklere i mangel på bedre teknikker kan ha problemer med strukturering av kode som kan virke usammenhengende.
Her må vi tilpasse oss hverandre. Vi må ha tålmodighet til å tolerere løsninger som kan være litt mindre “elegante” enn hva vi hadde sett for oss, samtidig ønsker vi at nykommere møter på komfortabel utfordring som lar dem vokse i tråd med koden.
Å skrive enkel kode er definitivt ikke lett.
Å kode for lesbarhet
Et humoristisk og velkjent sitat føles passende i denne sammenhengen:
"Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. Code for readability."
Å kreve lesbarhet — spesielt med disse usannsynlige forutsetningene — er lettere sagt enn gjort, men jeg liker ordlyden “code for readability”. Man må ha en intensjon om å skrive lesbar kode.
Lesbarhet er subjektivt og krever empati. Eksponering for andres utfordringer hjelper oss finne fellesnevnere som sammen bidrar til økt lesbarhet.
Vil vekk fra korte, strenge Jira-oppgaver, til mer prat om behov og følelser
Å møte seg selv i døra
Empatisk programmering handler også om oss (fremtidige) selv.
Jeg har ved flere anledninger opplevd å stirre i vantro på et stykke kode som umulig kan ha vært skrevet av en oppegående, kvalifisert programmerer.
Et naturlig instinkt for meg vil være å dra frem git blame — et uttrykk som kan ha gått ut på dato, forøvrig — i et forsøk på å avklare hvem som trenger en snarlig innføring i “empatisk” programmering:
Det viser seg å være meg selv … for sånn cirka to uker siden. 🤦
Programmereren du er i dag er ikke nødvendigvis programmereren du er i morgen. Du lærer deg nye triks og de gamle går i glemmeboka. Noen blir med deg livet ut.
«Kodegolfing og esoteriske språk som brainfuck har gjort empatiløs programmering til en kunstform.»
Trenger vi empati?
Empati er ikke en forutsetning for programmering. Disipliner som kodegolfing og esoteriske språk som brainfuck har gjort empatiløs programmering til en kunstform, tross alt.
Allikevel mener jeg at de aller fleste av oss befinner seg i situasjoner hvor vi er tjent med at empati bidrar til å styre valgene vi tar.
Det krever en elementær åpenhet og nysgjerrighet til å bygge en forståelse om tingene og menneskene rundt oss. Det er urimelig å forvente — både av seg selv og av andre — at dette kan foregå uten samhandling eller eksponering.
Ser vi litt av oss selv i koden vi jobber med til daglig blir den mindre skummel og man vil føle et større eierskap. Samtidig vil innflytelsen fra andre sørge for at vi ikke stopper å utvikle oss.
Det kaller jeg en vinn-vinn situasjon.