Du har vært gjennom skyttergravene.
Du finpusset CV-en til den skinte. Du styrket ferdighetene og sertifiseringene dine.
Du finjusterte GitHub-profilen din, studerte spørsmål om systemdesign til de gikk i ett, og trykket på «søk» flere ganger enn du har lyst til å telle.
Du trosset intervjurunden – whiteboard-oppgaver, hjemmeoppgaver, pinlige pauser og alt som hører med. Du hevet ferdighetsnivået ditt og beholdt roen.
Og så … kom jobbtilbudet. Du fikk jobben! Nå begynner det virkelige arbeidet.
For selv om det er vanskelig å ansette, er det enda vanskeligere å gjennomføre en god onboarding. Det er her du går fra kandidat til bidragsyter, og hvor førsteinntrykk blir varige inntrykk. De første 90 dagene legger grunnlaget for alt som følger.
I denne veiledningen går jeg gjennom hvordan du kommer godt i gang som ny programvareingeniør, med praktiske råd fra to erfarne teknologer som har vært der, gjort det før og vet hva som fungerer. Men først skal vi se nøkternt på hva det faktisk innebærer å være programvareingeniør i dag.
Hva er en programvareingeniør?
Å, hvor skal vi begynne? Seriøst, du kunne skrevet en hel bok om dette emnet, blant annet fordi begrepet noen ganger brukes som en samlebetegnelse for flere mulige roller som dekker alle faser av programvareutviklingslivssyklusen. Derfor kan andre titler også være relevante her, som utvikler eller programmerer. Vi bruker «programvareingeniør» som en samlebetegnelse.
Her er en kortfattet definisjon av programvareteknikk, hentet fra Michigan Technological University, slik at vi holder kursen: «Programvareteknikk er den grenen av informatikk som omhandler design, utvikling, testing og vedlikehold av programvareapplikasjoner. Programvareingeniører bruker ingeniørprinsipper og kunnskap om programmeringsspråk til å bygge programvareløsninger for sluttbrukere.»
Hvis du koker dette ned til de enkleste ordene, høres det omtrent slik ut: Programvareingeniører bygger digitale ting som mennesker og maskiner kan bruke. I stedet for hammer og spiker bruker de kode, sammen med et utvalg verktøy som Git og andre komponenter.
Vi bør også nevne én av grunnene til at mange ønsker å jobbe som programvareingeniører i utgangspunktet: Jobben kan være godt betalt. Karriere-nettstedet Glassdoor anslår den samlede medianlønnen for programvareingeniører til $147,000 per år (sist kontrollert: 28. april 2025), selv om de faktiske tallene varierer basert på faktorer som erfaring, sted og bransje.
La oss nå se nærmere på noen praktiske tips og ideer for å komme godt i gang.
De første 30 dagene
I vår tilhørende artikkel om karrierer innen cybersikkerhet påpekte vi at de første 30 dagene i bunn og grunn handler om læring. Det omfatter alt fra kodebaser og verktøy til nye ansikter og nye steder. Og det gjelder fortsatt her, om enn med noen justeringer.
Tips nr. 1: Ikke alle teknologistakker er like
Å finne seg til rette i den nye rollen handler like mye om å lære menneskene og prosessene som om å lære kodebasen eller teknologistakken.
«Basert på erfaringen min fra store selskaper er det viktigere å forstå menneskene [og] prosessene enn arkitekturen i koden», sier Justin Garrison, produktsjef i Sidero Labs. Før sin nåværende rolle jobbet Justin som seniorutvikler innen utviklerrelasjoner hos AWS og i flere ingeniørroller hos Disney, blant annet som senior programvareingeniør.
Have an account? Log In
Tips nr. 2: Forstå hvordan virksomheten skaper inntekter
For å maksimere din verdi må du forstå hvordan organisasjonen skaper sin verdi.
«I tillegg til å lære den tekniske stakken og kravene bør ingeniører finne ut hvordan virksomheten skaper verdi og får betalt», forteller Chris Carter, ledende produktansvarlig hos NetApp Instaclustr. Før han tok på seg sin nåværende rolle, begynte Chris i selskapet som senior utviklingsingeniør og leder for et ingeniørteam. Han fortsetter:
«Direkte abonnementer? Feltsalgsteam og skreddersydde avtaler? Oppmerksomhet og annonsering? Finn ut hvordan virksomheten måler seg selv, og hvordan den går fra kode til KPI.»
Bygg denne forståelsen tidlig. Programvareingeniører som kan knytte forbindelsen mellom koden sin og selskapets økonomi, går neppe av moten.
«Ved å forstå hvordan selve virksomheten måler suksess, kan du posisjonere deg slik at du blir en del av arbeidet med å skape denne suksessen og bidra til resultatet», sier Chris.
Tips nr. 3: Klon repositoriet, men ikke forhast innleveringen
Klart du gleder deg til å lage den første PR-en. Men behandle kodebasen som en levende organisme: observer mønstrene, forstå anatomien, og still spørsmål før du opererer. Bruk IDE-ens funksjoner for kodenavigering, grep-kommandoer eller søk i repositoriet for å følge hvordan data og logikk flyter gjennom systemet.
Og hvis du står fast? Prøv å gjenskape atferden lokalt, og følg den deretter trinn for trinn. Feilsøkingsverktøy er undervurdert, og det fungerer fortsatt å forklare problemet til en gummiand.
Proff-tips: Se på nylig sammenslåtte PR-er for å forstå kodestil, kulturen rundt kodegjennomganger og hvordan «ferdig» egentlig ser ut.
De første 60 dagene
En av de beste måtene å komme raskt inn i arbeidet på er å være nysgjerrig, ikke bare på hva koden gjør, men hvorfor den gjør det på den måten.
Tips nr. 4: Spør: «Hvorfor ble dette bygget slik?»
Eldre kode kan se ut som spaghetti, men ofte finnes det faktisk kjøtt i sausen. Begrensninger fra en tjeneste som nå er avviklet, et kompromiss for bedre ytelse, et forretningskrav fra en produktfunksjon som er faset ut – disse valgene har en historie. Når du lærer denne historien, unngår du å foreslå noe som allerede er prøvd (og mislyktes), og du bygger troverdighet.
Begynn med intern dokumentasjon (selv om den er utdatert). Be deretter en kollega om å gå gjennom noe forvirrende sammen med deg, og se på vedkommende som en medforfatter av systemets historie.
«Hvilke beslutninger er kodet inn i denne koden?» er et bedre spørsmål enn «Hvorfor er denne koden så dårlig?»
Tips nr. 5: Finn teamets «uskrevne regler»
Alle teknologiorganisasjoner har slike regler. Kanskje foretrekker teamet RFC-er i Notion fremfor Jira-saker, kanskje distribuerer alle på torsdager, eller kanskje enhetstester er valgfrie – mens ende-til-ende-tester er hellige.
Disse normene står ikke alltid i en håndbok, men de vil påvirke hvor godt du lykkes, akkurat like mye som kodeferdighetene dine. Følg med på mønstre i Slack, studer Git-commitmeldinger, og spør kollegene hva de skulle ønske de visste da de begynte.
Tips nr. 6: Fortsett å møte mennesker – og lære av dem
Justin fra Sidero Labs hevder at møter med mennesker hjelper utviklere med å forstå hvordan systemer fungerer sammen, utover selve koden: «Etter disse møtene var det mye enklere å forstå hvorfor systemene ser ut som de gjør.»
Dette gir alle mulige positive ringvirkninger, blant annet lavere blodtrykk når du leser kode som ikke ser ut til å gi mening ved første øyekast. Hvis et menneske skrev den, hadde vedkommende sannsynligvis en grunn til å skrive den slik, og disse grunnene kan omfatte organisatoriske variabler, tidspress og så videre.
Denne helhetlige forståelsen er nyttig for teamkultur og kommunikasjon, men også for empati og diplomati når tiden kommer for å finne og foreslå forbedringer.
De første 90 dagene
Nå er du blitt helt varm i trøya: «Etter 90 dager bør du ha funnet deg til rette og forhåpentligvis være i stand til å ta eierskap til større oppgaver», sier Chris fra NetApp Instaclustr.
Denne siste fasen handler i stor grad om planlegging og om å begynne å gjennomføre. Hvor kan
du begynne å skape en reell effekt?
More Articles
Tips nr. 7: Begynn å optimalisere med mål og effekt
Etter 90 dager er du ikke lenger bare «den nye utvikleren» – du er i ferd med å bli en bidragsyter. Det betyr at det er på tide å se etter muligheter for å gjøre ting bedre. Men det finnes en hake: Ikke alle forbedringer er verdt å forfølge, og ikke alle feil er verdt å rette.
«Det handler ikke om å lage en lang liste over alt som er ødelagt», sier Chris. «Det handler om å forstå virksomheten, kunden og konteksten – og deretter bruke denne kunnskapen til å finne meningsfulle måter å forbedre på.»
Slik går Chris og teamet hans frem for å ha denne innstillingen:
- Tenk oppstrøms: Ikke hopp rett til løsninger – begynn med å skrive tydelige saker som beskriver problemet.
- Prioriter klokt: Lær hvordan teamet vurderer effekt, innsats og hvor mye det haster. En ubetydelig brukergrensesnittfeil på en utdatert skjerm? Sannsynligvis ingen krise.
- Kunden først: Spør alltid: «Vil dette ha betydning for en faktisk bruker?» Hvis ikke, arkiver saken og gå videre.
Når du har lært systemene og kulturen å kjenne, kan du begynne å se etter oppgaver med større effekt – ting som reduserer friksjon, forbedrer leveransene eller styrker kundeopplevelsen.
«Ved å levere arbeid som konsekvent bringer virksomhetens mål fremover, vil du raskt bli anerkjent som en som «forstår det» – og som kan betros større oppgaver», sier Chris.
Tips nr. 8: Lever noe. Hva som helst. Men ta fullt eierskap til det.
Innen dag 90 trenger du ikke å ha skrevet om en kjernetjeneste eller lansert en ny funksjon på egen hånd. Men du bør kunne peke på én ting, uansett hvor liten den er, som du har levert og hatt fullt eierskap til fra start til slutt.
Det kan være:
- En feilretting som reduserte friksjonen for brukerne
- En justering av en CI/CD-pipeline som gjorde bygging raskere
- En fullstendig gjennomgang av en README som hjalp den neste nyansatte
- En optimalisering av backend som reduserte en vanlig spørring med 50ms
Det trenger ikke å være prangende – det må være nyttig. Effekt handler ikke om å vise seg frem, men om funksjon.
Ingeniørens mantra: «Gjorde jeg teamets hverdag 1 % bedre denne uken?»
Tips nr. 9: Opprett en personlig læringsliste
Du kommer ikke til å mestre hele kodebasen, infrastrukturen og forretningslogikken på 90 dager. Det er helt greit. Det som betyr noe, er hva du gjør videre.
Opprett en personlig «liste» over ferdigheter og kunnskapshull. Skriv ned:
- Områder i systemet du fortsatt ikke forstår
- Verktøy eller rammeverk du ønsker å lære mer om (f.eks. Kubernetes, gRPC, Terraform)
- Teknisk gjeld eller merkelige forhold du ønsker å se nærmere på
Prioriter deretter én ting per sprint, og kryss den av. Du lærer ikke bare systemet – du utformer også planen for din egen utvikling.
Abonner på nyhetsbrevet til The CTO Club for å få flere spillebøker for de første 90 dagene i enhver teknologirelatert rolle!
