Hvorfor ble du utvikler? 👶
Mitt første møte med koding skjedde rundt 4-årsalderen. Mamma tok kveldskurs i programmering og hadde i lekse å lage et yatzyspill. Jeg hadde allerede rukket å bli ganske så bevandret i yatzyverdenen, så når jeg sier at det var noe av det kuleste jeg hadde sett, så sier det sitt.
Jeg levde de neste 15 årene av livet mitt som en egosentrisk kodekonsument og hadde lite interesse av å bidra med egen kode til samfunnet. Så kom det skjebnesvangre øyeblikket der jeg måtte bestemme hva jeg skulle bli når jeg ble voksen.
Interessen min for realfag trakk meg i retning ingeniørfeltet, og beslutningsvegringen min gjorde at jeg landet på datateknologi. Jeg hadde hørt at “kan man jobbe med IT, kan man jobbe med hva som helst”.
Til min store lettelse hadde jeg ikke latt meg villede av yatzyens sjarm, det viste seg at koding var noe for meg. Måten å dele opp og strukturere problemer resonnerte godt med hvordan jeg likte å tenke. Jeg ble raskt fan.
Hva jobber du med? 💪
Jeg jobber som backendutvikler på et produktteam hos NAV som jobber med å bygge en ny vedtaksløsning for beregning og utbetaling av sykepenger. Dette innebærer blant annet å tolke et regelverk slik at en maskin kan forstå og automatisere mye av saksbehandlingen.
Dette krever mye tverrfaglig samarbeid med både jurister, designere, saksbehandlere og domeneeksperter.
Det nye systemet vi jobber med er i produksjon og fatter millioner av vedtak i året. Det står for å utbetale ca. 65 % av alle sykepenger som utbetales i Norge (som etter naive grovestimater tilsvarte ca. 34 milliarder kroner i 2023).
Den tekniske riggen jeg jobber med er en mikrotjenestebasert, hendelsesorientert arkitektur og jeg jobber stort sett i Kotlin og med Kafka.
Hvordan ser uka ut for deg? 📆
Vanligvis er jeg på kontoret 2-3 dager i uken, mandager og fredager blir stort sett tilbragt på hjemmekontor. På teamet mitt jobber vi OKR-basert og arbeidsmetodikken vår er veldig inspirert av boken Radical Focus. Hele teamet møtes mandag morgen for Monday Commits, her plukker vi 4 hovedmål vi ønsker å oppnå i løpet av uken.
Hver dag deler vi oss inn i par, vi prøver å parprogrammere så mye som mulig. Uken min bærer derfor preg av veldig mye samarbeid og jeg jobber sjeldent alene. Det er en intens måte å jobbe på, men man lærer utrolig mye.
Parprogrammering åpner opp for å droppe pull requests ettersom kodegjennomgangen skjer underveis innad i paret. Vi pusher derfor alt rett på main (trunk-based development), som ikke er like cowboy som det høres ut som når det kombineres med testdrevet utvikling, hyppige commits og parprogrammering.
På fredager samles vi for Friday Wins der vi sjekker (og feirer) om vi klarte å nå målene vi satte oss på mandagen.
«Hver dag deler vi oss inn i par, vi prøver å parprogrammere så mye som mulig.»
Hva er det neste du har lyst til å lære deg eller bli bedre på? 🧠
Det hadde vært gøy å klare én pullup.
I tillegg har jeg lyst til å lære meg WebGL. Da kan jeg iterere på slektsarbeidet og lage familiens første tredimensjonale yatzyutgave.
Hva er den mest utfordrende situasjonen du har stått i? 👀
På teamet mitt har vi en regel at alle applikasjoner må starte på “sp” (for sykepenger). Nå har vi 119 repositories og det begynner å bli utfordrende å finne beskrivende navn på nye apper.
Men fra SPøk til revolver. Tverrfaglig samarbeid er noe av det viktigste, mest krevende og gøyeste jeg gjør.
Som utvikler er jeg så klart lidenskapelig opptatt av smidig utvikling og raske deploy pipelines. Men tidvis har det vært vanskelig å løfte blikket og se forbi mine hippe teknologiverdier i samarbeid med andre fagdisipliner.
Spørsmål jeg kan gruble over:
- Er refaktorering av gammel kode det viktigste for produktet akkurat nå?
- Hvordan klare å jobbe smidig når man utvikler noe innen et domene som har lav endringsevne?
- Er jeg nødt til å respektere at det tar lengre tid å endre en lov enn min hjemmesnekra algoritme? (Det viser seg at hvis jeg ikke respekterer dette når jeg jobber med lovverk så er jeg en indirekte tilhenger av styreformen diktatur, derfor har jeg konkludert med at jeg respekterer det).
Jeg har dessverre ikke mange svar å by på, men jeg tror man kommer utrolig langt med å være inkluderende og å jobbe sammen med andre fagdisipliner på konkrete oppgaver. I produktteam er man ofte et flertall utviklere, og jeg mener derfor det faller et ekstra ansvar på oss for å sørge for at de andre fagdisiplinene føler seg hørt.
«Hvis du ikke er redd for å fremstå “dum”, blir du raskere mindre “dum”.»
Hva er ditt beste tips til andre utviklere? 🤖
Hvis du ikke er redd for å fremstå “dum”, blir du raskere mindre “dum”.
Still masse spørsmål og vær nysgjerrig på andres fagområder. Det er vanskelig å vite at du løser riktig problem, om du ikke har forstått hva problemet du skal løse er.
