Programmering er i dag en af de mest populære retninger for faglig udvikling.
Nogle kommer ind i branchen efter en it-uddannelse. Andre afslutter bootcamps. Endnu andre lærer selvstændigt ved at skrive de første applikationer i deres fritid.
Uanset vejen spørger næsten enhver nybegynderprogrammør sig de samme spørgsmål.
Hvilke teknologier skal man vælge?
Hvordan finder man sit første job?
Hvad forventer virksomhederne?
Hvordan ser den daglige arbejdsdag ud i et softwarehouse?
Og måske det vigtigste... Hvornår holder jeg op med at være junior?
Efter mere end tyve års arbejde med projekter for kunder fra forskellige brancher og oplæring af flere generationer af yngre udviklere kan vi besvare mange af disse spørgsmål.
Men vi advarer. Der kommer ikke en liste "10 frameworks du skal lære i 2026".
Sådanne artikler findes der tusindvis af på nettet...
I stedet vil vi vise, hvordan programmering ser ud indefra. Den ægte version.
Uden marketingfraser. Uden historier om udviklere, der arbejder fra stranden på Bali. Men med historier, der rent faktisk er sket. Og med råd, som vi selv engang havde brug for.
Hvad handler denne serie om?
I de næste fire artikler guider vi dig gennem den vej, som næsten enhver udvikler går igennem.
I de følgende dele vil vi blandt andet fortælle om:
- hvad det virkelig er værd at lære i starten af karrieren,
- hvilke teknologier der er fundamentet, og hvilke der blot er midlertidige trends,
- hvilket hardware og software der virkelig betyder noget,
- hvordan den daglige arbejdsdag i et professionelt softwarehouse ser ud,
- hvorfor Code Review er en af de bedste lektioner i programmering,
- hvordan man bruger AI til hurtigere at udvikle sig i stedet for blindt at kopiere kode,
- hvilke fejl næsten alle juniorer begår,
- hvorfor vendingen "det virker hos mig" er blevet en af de mest kendte jokes i branchen,
- hvad forskellen er på en Junior, en Mid og en Senior Developer,
- hvorfor de bedste udviklere kendes ikke på antallet af programmeringssprog, men på deres måde at tænke på.
Hvis du lige er begyndt din rejse med programmering, vil denne serie hjælpe dig med at undgå mange fejl.
Hvis du allerede arbejder i branchen, vil du sandsynligvis genkende mange situationer, som du selv husker tydeligt.
Hver Senior har engang været den fortabte Junior
Det er nogle gange svært at tro. Du ser en Senior Developer, som finder en fejl på få minutter, en fejl du har tænkt over i to dage. De skriver kode så hurtigt, som om de ikke behøver at tænke over det. De kender tastaturgenveje, du ikke anede fandtes. De taler om arkitektur, designmønstre og containerisering med samme lethed, som man taler om vejret.
Det er let at tænke: "Han er bare et geni."
Ofte ser sandheden dog helt anderledes ud...
Hver Senior har engang:
- glemt et semikolon,
- ved et uheld slettet en del af databasen,
- kæmpet med en fejl i en halv dag kun for at opdage en stavefejl,
- lavet sin første konflikt i Git,
- deployet en patch, som... brød noget helt andet.
Det er ikke talent, der adskiller de fleste Seniorer fra Juniorer. Det er erfaring. Og erfaring får man kun gennem praksis.
Studier lærer dig at programmere. Arbejde lærer dig at være udvikler.
Denne sætning kan virke provokerende, men den afspejler virkeligheden godt.
Studier er et godt sted at forstå grundlæggende ting. Lære algoritmer. Datastrukturer. Matematik. Computerarkitektur. Hvordan operativsystemer virker. Det er enormt værdifuldt. Men den daglige arbejdsdag ser helt anderledes ud.
Pludselig viser det sig, at udover kodning skal du også:
- forstå kundens behov,
- samarbejde med UX-designere,
- konsultere løsninger med projektlederen,
- integrere med eksterne systemer,
- læse dokumentation,
- skrive dokumentation,
- analysere fejl rapporteret af brugere,
- deltage i Code Review,
- planlægge eget arbejde,
- estimere tidsforbruget for opgaver.
Og netop det lærer de fleste studier ikke.
Den største overraskelse? Programmering er kun en del af arbejdet.
Det er et øjeblik, som overrasker næsten enhver junior.
Forestilling?
Du møder på arbejde. Får en opgave. Skriver kode. Afleverer. Går hjem.
Virkeligheden er anderledes...
En stor del af dagen går med samtaler. Planlægning. Analyse. Møder. Læsning af eksisterende kode. Debugging. Fejlfinding.
At skrive kode er ofte kun ét trin i hele processen.
En god udvikler er ikke den, der skriver kode hurtigst. En god udvikler er den, der kan finde den bedste måde at løse et problem på.
Nogle gange er den bedste løsning... ikke at skrive en eneste ny linje kode.
En historie fra vores team
For nogle år siden kom en praktikant til vores team. Vi husker den dag meget godt.
Stor entusiasme. Endnu større nysgerrighed. Og tusindvis af spørgsmål: Hvorfor gør vi det sådan? Hvad er formålet med dette designmønster? Hvorfor kan man ikke skrive det enklere? Er det virkelig nødvendigt at skrive tests? Hvordan virker Git?
Hver af os har engang stillet lignende spørgsmål.
Derfor besluttede vi os for i stedet for at forvente, at han fra dag ét ville bygge komplekse funktioner, at fokusere på noget helt andet - at lære ham en måde at tænke på.
Vi viste ikke kun hvordan man gør noget.
Vi forklarede først og fremmest hvorfor vi gør det på netop den måde.
Efter de første praktikperioder kom han tilbage til os. Fik mere ansvar. Deltog i Code Review. Lærte flere teknologier. Så, hvordan projekter for kunder bliver ledet. Lærte at samarbejde med hele teamet.
I dag er han et fuldgyldigt medlem af vores softwarehouse.
Han leder selv krævende opgaver. Designer løsninger. Løser problemer, som for få år siden virkede umulige for ham.
Skete det, fordi han lærte endnu et framework? - Nej.
Den største forandring var at lære en måde at tænke på. For en god udvikler kender ikke svarene på alle spørgsmål. En god udvikler ved, hvordan man effektivt finder dem.
"Det virker hos mig..."
Vi kunne ikke afslutte den første del uden en af de mest ikoniske sætninger i udviklerverdenen.
Alle, der har arbejdet i it i lidt længere tid, kender denne sætning. - Det virker hos mig.
Sætningen er både morsom...
...og meget farlig.
For brugeren er det ligegyldigt, at det virker på din computer.
Kunden interesserer sig ikke for, at det virkede i testmiljøet.
Produktionsserveren læser heller ikke en kommentar: // det virkede hos mig :)
En ægte udvikler afslutter ikke analysen med at sige, at "det virker hos mig".
Han stiller næste spørgsmål: Hvorfor virker det hos mig, men ikke hos kunden?
Og netop der starter den rigtige læring.
Begrebsordliste
Junior Developer
En udvikler, der starter sin professionelle karriere. Fokuserer på at få erfaring, lære best practices og udvikle tekniske færdigheder samt samarbejdsevner.
Code Review
Processen, hvor en anden udvikler gennemgår koden. Formålet er at forbedre kodekvaliteten, opdage potentielle fejl og videregive viden i teamet.
Framework
Et sæt færdige biblioteker og værktøjer, der gør det nemmere at bygge applikationer. Et framework pålægger en bestemt projektstruktur og fremskynder softwareudviklingen.
Git
Det mest populære versionskontrolsystem, som gør det muligt at spore ændringer i kode og samarbejde om et projekt.
Debugging (Debugging)
Processen med at finde, analysere og rette fejl i en applikation.
Opsummering
Hvis du efter at have læst denne del kun husker én ting, så lad det være denne.
Programmering kan læres gennem kurser, bøger og videoer.
At være udvikler lærer du først, når du begynder at løse rigtige problemer sammen med andre mennesker.
Det er dér, erfaring, ansvar og den måde at tænke på opstår, som med tiden adskiller en god udvikler fra en person, der kun kender sprogets syntaks.
I næste del går vi til det konkrete.
Vi viser, hvad det virkelig er værd at lære, hvilke teknologier der udgør et solidt fundament for en karriere, hvilket hardware og software man skal vælge, og hvorfor kendskab til ét sprog ofte er mere værdifuldt end overfladisk viden om fem.
