De første 90 dage: En trin-for-trin-guide for softwareingeniører

Du har været ude i skyttegravene.

Du pudsede dit CV, indtil det skinnede. Du styrkede dine færdigheder og certificeringer.

Du finjusterede din GitHub, studerede spørgsmål om systemdesign, indtil de flød sammen, og trykkede på »ansøg« flere gange, end du har lyst til at tælle.

Du stod igennem interviewmaratonet – whiteboardtavler, hjemmeopgaver, akavede pauser og det hele. Du opgraderede dine færdigheder og bevarede roen.

Og så … kom jobtilbuddet. Du fik jobbet! Nu begynder det virkelige arbejde.

For selvom det er svært at ansætte, er det endnu sværere at integrere effektivt. Det er her, du går fra kandidat til bidragyder, og hvor det første indtryk bliver varigt. Dine første 90 dage vil lægge grundlaget for alt det, der følger.

I denne guide gennemgår jeg, hvordan du kommer godt fra start som ny softwareingeniør, med praktiske råd fra to erfarne teknologiprofessionelle, som har prøvet det før, ved hvad der virker, og selv har stået i situationen. Men først skal vi se nøgternt på, hvad det faktisk betyder at være softwareingeniør i dag.

Hvad er en softwareingeniør?

Åh, hvor skal vi begynde? Seriøst, man kunne skrive en hel bog om dette emne, blandt andet fordi betegnelsen nogle gange bruges som en samlebetegnelse for flere mulige roller, der spænder over alle faser af softwareudviklingens livscyklus. Derfor kan andre titler også være relevante her, såsom udvikler eller programmør. Vi bruger »softwareingeniør« som en overordnet betegnelse.

Her er en kortfattet definition af softwareudvikling fra Michigan Technological University, så vi holder kursen: »Softwareudvikling er den gren af datalogi, der beskæftiger sig med design, udvikling, test og vedligeholdelse af softwareapplikationer. Softwareingeniører anvender ingeniørprincipper og viden om programmeringssprog til at opbygge softwareløsninger for slutbrugere.«

Hvis man reducerer det til de enklest mulige termer, lyder det nogenlunde sådan her: softwareingeniører bygger digitale ting, som mennesker og maskiner kan bruge. I stedet for hammer og søm bruger de kode sammen med et udvalg af værktøjer som Git og andre komponenter. 

Vi bør også nævne en af grundene til, at mange overhovedet ønsker at arbejde som softwareingeniører: Jobbet kan være vellønnet. Karrierewebstedet Glassdoor vurderer den samlede medianløn for softwareingeniører til $147,000 om året (senest tjekket: 28. april 2025), selvom de faktiske tal varierer afhængigt af faktorer som erfaring, geografisk placering og branche.

Lad os nu dykke ned i nogle konkrete tips og idéer til at komme godt fra start.

De første 30 dage

I vores relaterede artikel om karrierer inden for cybersikkerhed bemærkede vi, at de første 30 dage i sidste ende handler om at lære. Det betyder alt fra kodebaser og værktøjer til nye ansigter og nye steder. Og det gælder stadig her, om end med nogle justeringer.

Tip nr. 1: Ikke alle teknologistakke er skabt ens

At finde sig til rette i din nye rolle skal i lige så høj grad handle om at lære mennesker og processer at kende som om at lære kodebasen eller teknologistakken at kende.

»Ud fra min erfaring fra store virksomheder er det vigtigere at forstå menneskerne [og] processerne end kodens arkitektur,« siger Justin Garrison, produktchef hos Sidero Labs. Før sin nuværende rolle arbejdede Justin som seniorfortaler for udviklere hos AWS og i flere ingeniørroller hos Disney, herunder som senior softwareingeniør. 

Tip nr. 2: Forstå, hvordan virksomheden skaber indtjening

For at maksimere din værdi skal du forstå, hvordan organisationen skaber sin værdi.

»Ud over at lære den tekniske stak og kravene bør ingeniører finde ud af, hvordan virksomheden skaber værdi og får betaling,« fortæller Chris Carter, ledende produktchef hos NetApp Instaclustr. Før han tiltrådte sin nuværende rolle, begyndte Chris i virksomheden som seniorudviklingsingeniør og leder af et ingeniørteam. Han fortsætter:

»Direkte abonnementer? Feltsalgsteam og skræddersyede aftaler? Øjne og annoncering? Find ud af, hvordan virksomheden måler sig selv, og hvordan den bevæger sig fra kode til KPI.«

Opbyg denne forståelse tidligt. Softwareingeniører, der kan forbinde deres kode med virksomhedens økonomi, går næppe af mode.

“Ved at forstå, hvordan virksomheden selv måler sin succes, kan du positionere dig, så du bliver en del af at skabe denne succes og bidrage til bundlinjen,” siger Chris.

Tip nr. 3: Klon kodearkivet, men skynd dig ikke med dit første bidrag

Du er sikkert ivrig efter at lave din første PR. Men betragt kodebasen som en levende organisme: Observer dens mønstre, forstå dens anatomi, og stil spørgsmål, før du går i gang. Brug dit IDE's funktioner til kodenavigation, grep-kommandoer eller søgning i kodearkivet for at følge, hvordan data og logik flyder gennem systemet.

Og hvis du går i stå? Prøv at genskabe adfærden lokalt, og følg den derefter trin for trin. Debuggere bliver undervurderet, og det virker stadig at forklare problemet til en gummiand.

Eksperttip: Se på nyligt sammenflettede PR'er for at forstå kodestil, reviewkultur og hvad “færdigt” egentlig ser ud som.

De første 60 dage

En af de bedste måder at komme hurtigt ind i arbejdet på er at være nysgerrig – ikke kun på, hvad koden gør, men også hvorfor den gør det på den måde.

Tip nr. 4: Spørg: “Hvorfor blev dette bygget på denne måde?”

Legacykode kan ligne spaghetti, men ofte er der faktisk kød i saucen. Begrænsninger fra en nu udfaset tjeneste, en afvejning af ydeevne, et forretningskrav fra en produktfunktion, der er taget ud af drift – disse valg har en historie. Når du lærer denne historie, undgår du at foreslå noget, der allerede er blevet prøvet (og mislykkedes), og du opbygger din troværdighed.

Begynd med den interne dokumentation (selv hvis den er forældet). Bed derefter en kollega om at gennemgå noget forvirrende med dig, og betragt vedkommende som medforfatter til systemets historie.

“Hvilke beslutninger er indlejret i denne kode?” er et bedre spørgsmål end “Hvorfor er denne kode så dårlig?”

Tip nr. 5: Identificer dit teams “uskrevne regler”

Alle udviklingsorganisationer har dem. Måske foretrækker teamet RFC'er i Notion frem for Jira-sager, eller måske implementerer alle om torsdagen, eller også er enhedstests valgfri – men e2e-tests er hellige.

Disse normer står ikke altid i en håndbog, men de former din succes mindst lige så meget som dine programmeringsfærdigheder. Hold øje med mønstre i Slack, studér Git-commitbeskeder, og spørg dine kolleger, hvad de ville ønske, de havde vidst, da de begyndte.

Tip nr. 6: Bliv ved med at mødes med – og lære af – mennesker

Justin fra Sidero Labs mener, at møder med mennesker hjælper udviklere med at forstå, hvordan systemer fungerer sammen ud over selve koden: “Efter de møder var det meget lettere at forstå, hvorfor systemerne ser ud, som de gør.”

Det har alle mulige afledte fordele, herunder at sænke dit blodtryk, når du læser kode, der ikke ser ud til at give mening i første omgang. Hvis et menneske har skrevet den, havde vedkommende sandsynligvis en grund til at skrive den på den måde, og det kan blandt andet have været organisatoriske forhold, tidspres og så videre. 

Denne form for holistisk forståelse hjælper med hensyn til teamkultur og kommunikation, men også med empati og diplomati, når tiden kommer til at finde og foreslå forbedringer.

De første 90 dage

Du er blevet voksen: “Efter 90 dage bør du have fundet dig til rette og forhåbentlig være i stand til at tage ejerskab over større opgaver,” siger Chris fra NetApp Instaclustr.

Denne sidste fase handler i høj grad om at planlægge og begynde at føre planerne ud i livet. Hvor kan
du begynde at gøre en reel forskel?

Tip nr. 7: Begynd at optimere med formål og effekt

Efter 90 dage er du ikke længere bare den “nye udvikler” – du er en medarbejder, der er ved at finde sin rolle. Det betyder, at det er tid til at se efter muligheder for at gøre tingene bedre. Men der er en hage: Ikke enhver forbedring er værd at forfølge, og ikke enhver fejl er værd at rette.

“Det handler ikke om at lave en lang liste over ting, der er ødelagte,” siger Chris. “Det handler om at forstå virksomheden, kunden og konteksten – og derefter bruge denne viden til at identificere meningsfulde måder at forbedre tingene på.”

Sådan arbejder Chris og hans team med denne tilgang:

• Tænk opstrøms: Spring ikke direkte til løsninger – begynd med at skrive tydelige sager, der beskriver problemet.
• Prioritér klogt: Lær, hvordan dit team afvejer effekt, indsats og hast. En ubetydelig UI-fejl på en forældet skærm? Det er sandsynligvis ikke akut.
• Kunden først: Spørg altid: “Vil dette have betydning for en rigtig bruger?” Hvis ikke, så arkivér det, og kom videre.

Når du har lært systemerne og kulturen at kende, skal du begynde at opsøge opgaver med større løftestangseffekt – ting, der reducerer friktion, forbedrer leveringen eller styrker kundeoplevelsen.

“Ved konsekvent at levere arbejde, der bringer forretningsmålene fremad, vil du hurtigt blive anerkendt som en, der ‘forstår det’ – og som kan betros større opgaver,” siger Chris.

Tip nr. 8: Lever noget. Hvad som helst. Men tag ejerskab over det.

På dag 90 behøver du ikke have omskrevet en kernetjeneste eller lanceret en ny funktion alene. Men du bør kunne pege på én ting, uanset hvor lille den er, som du har leveret og haft fuldt ejerskab over fra start til slut.

Det kunne være:

• En fejlrettelse, der reducerede friktionen for brugerne
• En justering af en CI/CD-pipeline, der gjorde byggeprocesserne hurtigere
• En gennemgribende opdatering af en README-fil, der hjalp den næste nyansatte
• En backendoptimering, der fjernede 50 ms fra en almindelig forespørgsel

Det behøver ikke være smart eller imponerende – det skal være nyttigt. Effekt handler ikke om at gøre opmærksom på sig selv, men om funktion.

Ingeniørens mantra: “Gjorde jeg teamets hverdag 1 % bedre i denne uge?”

Tip nr. 9: Opret en personlig læringsopgaveliste

Du kommer ikke til at mestre hele kodebasen, infrastrukturen og forretningslogikken på 90 dage. Det er helt i orden. Det vigtige er, hvad du gør bagefter.

Opret en personlig “opgaveliste” over kompetencer og videnshuller. Skriv følgende ned:

• Områder i systemet, som du stadig ikke forstår
• Værktøjer eller rammeværker, du gerne vil lære mere indgående (f.eks. Kubernetes, gRPC, Terraform)
• Teknisk gæld eller særheder, du gerne vil vende tilbage til

Prioritér derefter én ting pr. sprint, og markér den som afsluttet. Du lærer ikke bare systemet – du designer din egen udviklingsplan.

Tilmeld dig The CTO Clubs nyhedsbrev for at få flere vejledninger til dine første 90 dage i enhver teknologirelateret rolle!