De första 90 dagarna: En steg-för-steg-handbok för mjukvaruingenjörer
Du har varit nere i skyttegravarna.
Du putsade på ditt CV tills det glänste. Du breddade dina färdigheter och certifieringar.
Du finjusterade ditt GitHub-konto, pluggade systemdesignfrågor tills de flöt ihop och klickade på ”ansök” fler gånger än du vill räkna.
Continue Reading for Free
Create a free account to finish this article, plus get ongoing access to timely insights and practical resources.
Have an account? Log In
Du tog dig an intervjuprocessens alla prövningar – whiteboardtavlor, hemuppgifter, pinsamma pauser och allt annat. Du utvecklade dina färdigheter och behöll lugnet.
Och sedan … kom anställningserbjudandet. Du fick jobbet! Nu börjar det verkliga arbetet.
För även om det är svårt att rekrytera är det ännu svårare att genomföra en effektiv introduktion. Det är här du går från kandidat till medarbetare och där det första intrycket blir bestående. Dina första 90 dagar lägger grunden för allt som följer.
I den här handboken går jag igenom hur du snabbt kommer igång som ny mjukvaruingenjör, med praktiska råd från två erfarna teknikproffs som har varit med om det, gjort det och vet vad som fungerar. Men först börjar vi med en nykter titt på vad det faktiskt innebär att vara mjukvaruingenjör i dag.
Vad är en mjukvaruingenjör?
Oj, var ska vi börja? Du skulle faktiskt kunna skriva en bok om det här ämnet, bland annat eftersom termen ibland används som ett samlingsnamn för flera möjliga roller som sträcker sig över alla faser av programvaruutvecklingens livscykel. Därför kan även andra titlar vara relevanta här, till exempel utvecklare eller programmerare. Vi använder ”mjukvaruingenjör” som ett paraplybegrepp.
Här är en kortfattad definition av mjukvaruutveckling, från Michigan Technological University, som hjälper oss att hålla kursen: ”Mjukvaruutveckling är den gren av datavetenskapen som behandlar design, utveckling, testning och underhåll av programvaruapplikationer. Mjukvaruingenjörer tillämpar ingenjörsprinciper och kunskaper i programmeringsspråk för att bygga programvarulösningar för slutanvändare.”
Om du kokar ner det till de enklaste termerna låter det ungefär så här: mjukvaruingenjörer bygger digitala saker som människor och maskiner kan använda. I stället för hammare och spik använder de kod, tillsammans med en uppsättning verktyg som Git och andra komponenter.
Vi bör också nämna en av anledningarna till att många vill arbeta som mjukvaruingenjörer från första början: jobbet kan vara välbetalt. Karriärsajten Glassdoor uppskattar den totala medianlönen för mjukvaruingenjörer till $147,000 per year (senast kontrollerat: 28 april 2025), även om de faktiska siffrorna varierar beroende på faktorer som erfarenhet, plats och bransch.
Nu går vi igenom några konkreta tips och idéer för att snabbt komma igång.
De första 30 dagarna
I vår tillhörande artikel om karriärer inom cybersäkerhet konstaterade vi att de första 30 dagarna i grunden handlar om att lära sig. Det omfattar allt från kodbaser och verktyg till nya ansikten och nya platser. Och det gäller fortfarande här, om än med vissa justeringar.
Tips nr 1: Alla teknikstackar är inte likadana
Att navigera i din nya roll måste handla lika mycket om att lära känna människor och processer som om att lära sig kodbasen eller teknikstacken.
”Baserat på min erfarenhet av stora företag är det viktigare att förstå människorna [och] processerna än kodens arkitektur”, säger Justin Garrison, produktchef på Sidero Labs. Innan sin nuvarande roll arbetade Justin som senior förespråkare för utvecklare på AWS och i flera ingenjörsroller på Disney, bland annat som senior mjukvaruingenjör.
Tips nr 2: Förstå hur företaget genererar intäkter
För att maximera ditt värde måste du förstå hur organisationen skapar sitt värde.
”Utöver att lära sig den tekniska stacken och kraven bör ingenjörer ta reda på hur företaget skapar värde och får betalt”, berättar Chris Carter, produktchef med huvudansvar på NetApp Instaclustr, för oss. Innan han tillträdde sin nuvarande roll började Chris på företaget som senior utvecklingsingenjör och ledare för ett ingenjörsteam. Han fortsätter:
”Direkta prenumerationer? Fältsäljteam och anpassade avtal? Ögonpar och annonsering? Ta reda på hur företaget mäter sig självt och hur det går från kod till KPI.”
Bygg upp den förståelsen tidigt. Mjukvaruingenjörer som kan koppla ihop sin kod med företagets ekonomi lär inte bli omoderna i första taget.
”Genom att förstå hur verksamheten själv mäter sin framgång kan du positionera dig för att bidra till att skapa den framgången och påverka resultatet”, säger Chris.
Tips nr 3: Klona kodförrådet, men skynda inte med incheckningen
Visst är du ivrig att skapa din första PR. Men behandla kodbasen som en levande organism: observera dess mönster, förstå dess anatomi och ställ frågor innan du börjar operera. Använd IDE:ns funktioner för kodnavigering, grep-kommandon eller sökning i kodförrådet för att följa hur data och logik flödar genom systemet.
Och om du kör fast? Försök återskapa beteendet lokalt och följ det sedan steg för steg. Avlusare underskattas, och det fungerar fortfarande att förklara problemet för en gummianka.
Proffstips: Titta på nyligen sammanslagna PR:er för att förstå kodstil, granskningskultur och hur ”klart” faktiskt ser ut.
De första 60 dagarna
Ett av de bästa sätten att snabbt komma igång är att vara nyfiken, inte bara på vad koden gör, utan också på varför den gör det på just det sättet.
Tips nr 4: Fråga: ”Varför byggdes detta på det här sättet?”
Äldre kod kan se ut som spaghetti, men ofta finns det faktiskt kött i såsen. Begränsningar från en numera avvecklad tjänst, en avvägning för prestandan eller ett verksamhetskrav från en utgången produktfunktion – de här valen har en historia. Genom att lära dig den historien undviker du att föreslå något som redan har provats (och misslyckats), samtidigt som du bygger upp din trovärdighet.
Börja med intern dokumentation (även om den är inaktuell). Be sedan en kollega att gå igenom något förvirrande med dig och behandla personen som en medförfattare till systemets berättelse.
”Vilka beslut finns inbyggda i den här koden?” är en bättre fråga än ”Varför är den här koden så dålig?”
Tips nr 5: Identifiera teamets ”oskrivna regler”
Alla utvecklingsorganisationer har sådana. Kanske föredrar teamet RFC:er i Notion framför Jira-ärenden, eller så distribuerar alla på torsdagar, eller så är enhetstester valfria – men e2e-tester är heliga.
De här normerna finns inte alltid i en handbok, men de påverkar din framgång minst lika mycket som dina programmeringskunskaper. Observera mönstren i Slack, studera Git-incheckningsmeddelanden och fråga kollegorna vad de önskar att de hade vetat när de började.
Tips nr 6: Fortsätt träffa och lära dig av människor
Justin från Sidero Labs menar att möten med människor hjälper utvecklare att förstå hur system fungerar tillsammans bortom koden: ”Efter de mötena var det mycket lättare att förstå varför systemen ser ut som de gör.”
Det ger alla möjliga positiva följdeffekter, bland annat lägre blodtryck när du läser kod som inte verkar begriplig vid första anblicken. Om en människa skrev den har den personen förmodligen haft en anledning att skriva den på det sättet, och dessa anledningar kan omfatta organisatoriska faktorer, tidspress och så vidare.
Den här helhetsförståelsen hjälper när det gäller teamkultur och kommunikation, men också empati och diplomati när det är dags att leta efter och föreslå förbättringar.
De första 90 dagarna
Nu är du varm i kläderna: ”Efter 90 dagar bör du ha landat i rollen och förhoppningsvis kunna ta ansvar för större uppgifter”, säger Chris från NetApp Instaclustr.
Den här sista fasen handlar verkligen om att planera och börja genomföra. Var kan
du börja göra en verklig skillnad?
Tips nr 7: Börja optimera med syfte och effekt
Efter 90 dagar är du inte längre bara den ”nya utvecklaren” – du börjar bidra på riktigt. Det betyder att det är dags att leta efter möjligheter att förbättra saker. Men det finns en hake: alla förbättringar är inte värda att driva igenom, och alla buggar är inte värda att åtgärda.
”Det handlar inte om att skapa en lång lista över saker som är trasiga”, säger Chris. ”Det handlar om att förstå verksamheten, kunden och sammanhanget – och sedan använda den kunskapen för att hitta meningsfulla sätt att förbättra.”
Så här tänker Chris och hans team:
- Tänk uppströms: Hoppa inte direkt till lösningar – börja med att skriva tydliga ärenden som beskriver problemet.
- Prioritera klokt: Lär dig hur teamet väger effekt, insats och brådska mot varandra. En trivial gränssnittsbugg på en föråldrad sida? Troligen ingen kris.
- Kunden först: Fråga alltid: ”Kommer detta att ha betydelse för en verklig användare?” Om inte, lägg det åt sidan och gå vidare.
När du har lärt dig systemen och kulturen kan du börja söka efter uppgifter med större hävstångseffekt – sådant som minskar friktion, förbättrar leveransen eller höjer kundupplevelsen.
”Genom att konsekvent leverera arbete som för verksamhetens mål framåt kommer du snabbt att uppfattas som någon som ’förstår’ – och som kan anförtros större saker”, säger Chris.
Tips #8: Leverera något. Vad som helst. Men äg det.
Senast dag 90 behöver du inte ha skrivit om en central tjänst eller lanserat en ny funktion på egen hand. Men du bör kunna peka på en sak, hur liten den än är, som du har levererat och tagit ansvar för från början till slut.
Det kan vara:
- En buggfix som minskade friktionen för användarna
- En justering av en CI/CD-pipeline som gjorde byggen snabbare
- En genomgång av en README-fil som hjälpte nästa nyanställda
- En backend-optimering som minskade tiden för en vanlig fråga med 50 ms
Det behöver inte vara sexigt – det måste vara användbart. Påverkan handlar inte om att glänsa, utan om funktion.
Ingenjörens mantra: ”Gjorde jag teamets vardag 1 % bättre den här veckan?”
Tips #9: Skapa en personlig lista över vad du vill lära dig
Du kommer inte att behärska hela kodbasen, infrastrukturen och verksamhetslogiken på 90 dagar. Det är okej. Det viktiga är vad du gör härnäst.
Skapa en personlig ”att-göra-lista” över kunskaper och kunskapsluckor. Skriv ner:
- Delar av systemet som du fortfarande inte förstår
- Verktyg eller ramverk som du vill lära dig mer om (t.ex. Kubernetes, gRPC, Terraform)
- Teknisk skuld eller egenheter som du vill återkomma till
Prioritera sedan en sak per sprint och bocka av den. Du lär dig inte bara systemet – du utformar din egen utvecklingsplan.
Prenumerera på The CTO Clubs nyhetsbrev för att få fler handböcker för dina första 90 dagar i vilken teknisk roll som helst!
