10 ting jeg skulle ønske noen fortalte meg da jeg begynte å jobbe som utvikler

Systemutvikling er et erfaringsbasert yrke. I utdanningen vil en utvikler tilegne seg mye teoretisk kunnskap, som absolutt er verdifull, men dessverre samsvarer den ikke alltid med arbeidslivet. Dermed er det ikke uvanlig at ferske utviklere får seg en skikkelig overraskelse når man endelig skal ta på seg voksen-buksene og ut i sin første jobb. Fra oss til deg, for å gjøre overgangen fra skolebenk til jobb litt enklere; her er 10 ting vi skulle ønske noen fortalte oss da vi begynte å jobbe som systemutviklere

av Kristine Helle-Andresen, Mathias Hartveit, Malin Milford og Martin Andersen

Photo by Alex Kotliarskyi on Unsplash

1. Å stille spørsmål betyr ikke at du er dum
Utviklere har ofte et ønske om å “kunne alt”. Som ny i en bedrift er det lett å føle at en aldri vil bli god nok i visse teknologier eller fagområder. Da er det viktig å tidlig innse at man blir ikke bedre uten å stille “dumme” spørsmål.

Finn en god kollega, enten i utviklingsteamet eller i konsulentfirmaet ditt, som du føler du kan spørre. Husk at alle har vært der du er nå, og vil kjenne igjen de problemene du nå støter på. For dem vil det jo bare være en påminnelse om hvor langt de har kommet, og for deg er det mye hyggeligere å sitte sammen med noen og løse problemer.

2. Du kommer til å gjøre feil. Det er en del av hverdagen til en utvikler.
Systemutvikling er vanskelig. I større bedrifter er det ofte mange små bevegelige programvare-deler som skal fungere i harmoni, og da er det lett å gjøre feil. Det viktigste er å danne seg rutiner for å lære av feilene sine. Har du introdusert en ny bug i kodebasen? Skriv en test som reproduserer feilen og du vil være sikker på at dette ikke skjer igjen.

Mange team praktiserer også retrospektiv-møter hvor medarbeiderne gjennomgår arbeidsmetoder og hvordan teamet kan forbedre seg fra uke til uke. Dette er en ypperlig arena for å ta opp utfordringer du har støtt på.

3. Du kommer aldri til å forstå hele kodebasen.
Som konsulent og nyutdannet er det ofte man kommer inn i et eksisterende prosjekt, og det kan fort bli overveldende å sette seg inn i kodebasen. Det kan være fristende å studere så mye som mulig av koden for å oppnå forståelse, men dette er feil bruk av tid.

Fokuser på å opparbeide en forståelse av systemet og hva det utfører. Hvilke behov skal systemet dekke for brukerene? Hvorfor har vi en “DTO-Service-Bus” modul og hvorfor er den koblet til API-et? Snakk med seniorutviklere og få dem til å tegne eller vise deg grafiske representasjoner av hvordan systemet henger sammen. Dette gjør det enklere å opparbeide seg kontekstuell informasjon til den gangen du må gjøre en endring. Det er mye enklere å forstå koden i en spesifikk klasse når man på forhånd vet hva den skal oppnå.

4. Google og stack overflow er enhver utviklers aller beste venn

Photo by Christina @ wocintechchat.com on Unsplash

Det er urealistisk å forvente at du skal huske svaret på hvert eneste problem du noen gang har truffet på. Ikke vær redd for å lene deg på andre folks løsninger, hvis det sparer deg for mye tid og hodebry. Likevel bør du tenke deg litt om før du kopierer kode direkte fra en nettside. Forstår du hva koden gjør og hvordan den påvirker systemet ditt?

5. Kommuniser med medarbeiderene dine
Det er utrolig viktig å ha god kommunikasjon og arenaer hvor utviklere (deg) kan få oversikt over hva produkteier og bruker har som behov, hva designere ønsker å formidle og hvordan ønsker kan løses teknisk.

Prat og avklar så mye som mulig om en oppgave før du begynner. Dermed unngår du mange tidkrevende iterasjoner når du eller andre medarbeidere misforstår hva som egentlig skal gjøres. Iterasjoner vil det bli, men desto flere avklaringer dere gjør i forkant, desto større er sannsynligheten for at dere holder antallet nede. Det er alle tjent med!

6. Tør å komme med innspill og ideer, selv om du er ny!
Perspektivene til nye utviklere er ofte gull verdt for et team; kanskje har man gjort noe unødvendig komplisert? Kanskje kunne man løst noe på en annen eller ny måte?
Teknologien kan bevege seg raskere enn mange i arbeidslivet får med seg. Nye personer med erfaring fra andre teknologier kan ofte gi nye muligheter man ellers ville gått glipp av.

7. Perfect is the enemy of done
I smidig utvikling har du som utvikler et mål om å fullføre en spesifikk oppgave innen en gitt tid. Da er det er fort gjort med scope creep. Enten det er at du finner bugs underveis, innser at noe burde omskrives, eller at en variabel burde hete noe annet og du finner ut at du skal endre dette i hele kodebasen. Det vil alltid være noe som kan gjøres bedre. Det er alltid noe som kan perfeksjoneres. Husk hva oppgaven din opprinnelig var og lag forbedringsoppgaver på det du finner underveis. Om du skal gjøre alt perfekt så blir du nemlig aldri ferdig.

8. Noen dager vil se slik ut:

1. Du stanger hodet i veggen fordi du ikke klarer å løse et problem
2. Du tråler internett og stack overflow for å se om NOEN andre i hele verden har hatt samme problemstilling…
3. Før du går for dagen pusher du tre linjer med kode, som knekker hele bygget, og det var det du gjorde den dagen… Happy times.
4. Det du må gjøre da, er: gå hjem, sov, løp deg en tur, og la underbevisstheten jobbe. 9/10 dager kommer du på jobb dagen etter og bruker 10 minutter på å fikse det som ikke fungerte.

9. … Men, andre dager skriver du tre linjer med kode som fikser alt!
Faktum er at størstedelen av tiden som utvikler går med til å fikse feil, som du noen ganger selv har introdusert. Så, når du fikser feilene er det desto viktigere å nyte suksessen før du kaster deg over neste feil. Ta en kort pause og vær stolt over hva du har fått til!

10. Ikke vær redd for å si “nei”
Som utvikler i en bedrift er det din jobb å kjenne til mulighetene med teknologien, men også begrensningene. En medarbeider vil sette pris på at du som fagperson stiller kritiske spørsmål til utvikling av systemer og løsninger. I teorien er alt mulig innen IT, men det er din jobb å vite hva kostnaden av å utføre det blir. Det er like viktig at man ikke sier ja til alt, akkurat som at man ikke sier nei til alt.

60% av utviklere rapporterer at de jobber overtid. Du kan ofte bli spurt om du “bare kan fikse denne lille ekstra tingen?”. Kvaliteten på det du skal gjøre kan fort bli dårlig dersom du alltid påtar deg ekstra arbeid eller jobber for raskt. Det er viktig å sette grenser for deg selv når det kommer til ansvar og overtid.

11. Å sprekke på et estimat er ikke verdens undergang ;)
Å bomme på estimat er noe både nye og erfarne utviklere opplever hele tiden. Det viktige er å tilegne deg verktøy og erfaring som lar deg melde ifra tidlig. Jo tidligere et team melder i fra om at en leveranse overgår estimatet, jo større spillerom har alle involverte i prosjektet.

… Og med dette gjenstår det bare å ønske deg masse lykke til i arbeidslivet!