Byg dig til et karriereskift – 6 måneder mod junior-udvikler

Over halvdelen af de danske junioropslag i 2025 nævner GitHub direkte. Ikke uddannelse. Ikke certifikater. GitHub.

Det betyder stille og roligt: Det er dit repo og dine deploy-links, du bliver målt på. Ikke hvor du startede.

Hvem den her plan er til – og hvad “jobklar” faktisk betyder

Jeg møder nogenlunde de samme tre typer, når snakken falder på karriereskift til udvikler:

• Du har 0 erfaring, men har måske leget lidt med en HTML-side eller et Python-script.
• Du har taget et kursus eller to, men sidder fast i tutorial-land.
• Du har et andet fag (fx marketing, økonomi, pædagogik) og vil skifte retning.

Hvis du kan genkende dig selv i én af dem, er planen her til dig.

Ikke til “jeg vil være senior på 12 måneder” eller “jeg vil kun lave game engines i C++”. Det her er til dig, der vil have et realistisk karriereskift til programmør eller softwareudvikler i Danmark, hvor målet er:

• Et juniorjob eller et trainee-forløb.
• Evt. en freelance-opgave eller et deltidsstudiejob som stepping stone.

Hvad vil det sige at være jobklar?

Jobklar er ikke “jeg har fulgt 40 timers YouTube”. Jobklar er:

• Du kan klone et repo, følge README og få det til at køre.
• Du kan finde og rette en simpel bug uden at gå i panik.
• Du kan bygge en lille feature og lave en pull request.
• Du har 2-3 live projekter, du kan vise på et CV.
• Du kan forklare, hvorfor du har valgt de løsninger, du har.

Og vigtigst: Du har beviser. Det er hele temaet for planen her.

Ikke “jeg føler, jeg har lært meget”. Men “her er mit deploy-link, her er mine tests, her er min README, og her er en commit hvor jeg løste en fejl”.

Vælg dit spor: frontend, backend eller full stack light

Før vi går uge-for-uge, skal du vælge retning. Ikke for livet. Bare for de næste 6 måneder.

Spor 1: Frontend med web-fokus

Det her spor er til dig, der bliver glad af at se ting flytte sig på skærmen. HTML, CSS, JavaScript, komponenter, forms, UI-tilstande.

Du fokuserer på:

• HTML og CSS i bunden (semantik, layout, responsivitet).
• Vanilla JavaScript til at styre state og events.
• Senere et mindre framework (React, Vue eller Svelte).

Der er masser af gode indgange i kategorierne HTML og CSS og JavaScript, hvis du vil have ekstra læsning undervejs.

Spor 2: Backend med web-API’er

Her er du mere til datamodeller, API’er, databaser og “hvordan hænger ting sammen i maskinrummet”. Du må stadig gerne bygge simpel frontend, men det er ikke hovedretten.

Du fokuserer på:

• Python eller JavaScript (Node) som sprog.
• Et webframework (FastAPI, Flask, Express).
• En database (Postgres eller SQLite til at starte med).

Hvis du kan lide tanken om at blive en klassisk backend til web-profil, så hold også øje med kategorien backend til web.

Spor 3: Full stack light

Full stack “light” betyder: du går hele vejen fra UI til database, men du vælger de simple løsninger hver gang.

Fx:

• React eller Vue på frontend.
• Node/Express eller et hosted backend-produkt (Supabase, Firebase) på backend.

Det her spor er godt, hvis du ikke kan lade være med både at ville pille ved knapperne og ved API’erne. Men du skal være lidt hårdere med at begrænse dig, for det er nemt at drukne.

Hvad du bevidst fravælger i 6 måneder

For ikke at hoppe rundt som en pinball-maskine, siger du eksplicit nej til:

• Tre forskellige sprog på én gang.
• To store frameworks parallelt “for at sammenligne”.
• DevOps-dybder, der hører til i jobbet, ikke i opløbet.

Du vælger én stack og lærer den godt nok til at kunne vise arbejde i den. Derefter kan du udvide.

Uge 1 – 4: Fundamentet du ikke slipper udenom

De første fire uger er kedelige på papiret og ret tilfredsstillende i virkeligheden, fordi du hurtigt kan se fremskridt, hvis du holder rytmen.

Uge 1: Git, GitHub og helt basal terminal

Hvis du vil tages seriøst som selvlært udvikler, skal du kunne Git. Ikke alt. Bare det her:

• init, clone, status, add, commit, push, pull.
• Starte et repo på GitHub og få kode derop.
• Læse en simpel diff og se, hvad der er ændret.

Daglig mini-øvelse (15-20 min):

• Lav en mappe “dag-01”, skriv en lille .txt- eller .md-fil, commit og push.
• På dag 2 ændrer du filen, ser diff og committer igen.

Du kan snige kommandolinje ind her ved at gøre alt via terminalen. Det føles akavet de første to dage og pludselig helt naturligt.

Bevis for uge 1:

• Et offentligt GitHub-repo “learning-log” med mindst 5 commits.
• README hvor du kort skriver, hvad du laver i de næste 6 måneder.

Uge 2: HTML og CSS (eller basal Python-syntaks, hvis du går ren backend)

Frontend- og full stack-spor:

• Lær HTML-struktur: <header>, <main>, <section>, formularer, lister.
• Grib det grundlæggende layout med Flexbox og Grid.
• Øv dig i at lave én simpel, statisk side om dagen.

Hvis du har brug for et spark til forståelsen af semantik, så kig på artiklen om at opdage HTML-semantik. Den sparer dig for en del “div-salat”.

Backend-spor:

• Tager du Python: variabler, funktioner, loops, if-sætninger, lister, dicts.
• Skriv små scripts der læser input og printer noget tilbage.

Daglig mini-øvelse:

• Frontend: genskab en lille UI-komponent du ser på nettet (knap, kort, formular).
• Backend: skriv et problem på 1 linje og løs det med 10-20 linjer Python.

Bevis for uge 2:

• Et repo “week-2-mini-projects” med mindst 3 små HTML/CSS-sider eller Python-scripts.
• Skærmbillede i README, så man kan se resultatet.

Uge 3: JavaScript i browseren eller Python videre

Her begynder ting at føles som “rigtig” programmering.

Frontend og full stack:

• Lær variabler, funktioner, arrays, objekter.
• DOM-manipulation: find et element, lyt efter et klik, ændr noget på siden.
• Byg 3-4 micro-øvelser: en tæller, et simpelt faneblad, en light/dark-mode-switch.

Backend (Python):

• Øv funktioner med parametre og returværdier.
• Arbejd med simple filer: læs/skriv tekstfiler.
• Lav små scripts der behandler lister af data.

Bevis for uge 3:

• En lille “interaktiv ting” med JS eller Python (fx CLI-menu).
• Kort README der forklarer, hvordan man kører det.

Uge 4: HTTP, browserens Network-tab og første deploy

Nu forbinder du tingene. Hvad sker der egentlig, når du skriver en adresse i browseren?

• Forstå HTTP-request/response på højt niveau.
• Åbn Network-tab i DevTools og se et rigtigt request.
• Deploy en statisk side (Netlify, GitHub Pages eller Vercel).

Hvis DevTools føles som sort magi, så er artiklen om Chrome DevTools Network et ret godt sted at gøre det lidt mindre skræmmende.

Bevis for uge 4:

• Et live-link til en side, du har deployet.
• En note i README: “Deployet her: [link]”.

Uge 5 – 8: Projekt 1 – en lille webapp med rigtige brugere i tankerne

Nu bygger du dit første “rigtige” projekt. Ikke kæmpe. Bare rigtigt nok til, at en fremtidig chef kan prøve det på 30 sekunder.

Uge 5: Vælg idé og lav scope

Vælg noget jordnært:

• En to-do app (ja, den er stadig fin).
• En lille liste over opskrifter.
• En habit-tracker, bogliste, spildagbog.

Du skal kunne bygge en første version på 2 uger.

Skriv i README:

• Hvem appen er til.
• Hvad man kan som minimum (must).
• Hvad du først laver senere (nice to have).

Uge 6: Forms, validering og fejl-UI

Uanset om du laver frontend eller backend, skal du kunne håndtere input.

• En formular med mindst 3 felter.
• Validering: hvad må brugeren ikke gøre (tomme felter, for kort tekst osv.).
• Vis fejltilstande pænt: rød tekst, lille besked, ikke bare en alert.

Hvis du bygger backend:

• Lav en route til at modtage data.
• Valider på serveren, og returnér en meningsfuld fejl.

Bevis midtvejs:

• En bruger kan indsende en formular.
• Hvis noget er galt, får de en klar fejlbesked.

Uge 7: Første rigtige deploy og README der ikke er kedelig

Nu skal projektet ud i luften, selvom det ikke er perfekt.

• Frontend-only: deploy på Netlify eller Vercel.
• Backend: vælg en simpel hosting, eller kør backend billigt og brug en gratis database.

Din README skal mindst indeholde:

• Hvad projektet gør og til hvem.
• Hvordan man starter det lokalt.
• Link til live-version.

Hvis du vil nørde README lidt, så snup nogle ideer fra artiklen om at skrive en README der bliver læst.

Uge 8: Oprydning, små forbedringer og mini-demo

Den sidste uge på projekt 1 bruger du på at:

• Rydde i mappen: slet døde filer, navngiv ting lidt bedre.
• Tjekke, at der ikke er åbenlyse fejl i konsollen.
• Lave 3 issues til dig selv og lukke dem via commits.

Bevis for projekt 1 (måned 2):

• Live-link der virker på mobil og desktop.
• GitHub-repo med README, issues og mindst 30 commits.
• Skærmoptagelse (2-3 min) hvor du klikker rundt og forklarer.

Uge 9 – 12: Projekt 2 – API, database og lidt test

Nu tager vi et skridt op. Du skal gemme data rigtigt. Ikke i localStorage. Ikke i én stor JSON-fil.

Uge 9: Vælg data og modeller

Vælg noget med relationer:

• Brugere og deres opgaver.
• Kurser og tilmeldinger.
• Spil og highscores.

Design en simpel datamodel:

• Tegn tabellerne på papir.
• Skriv felterne ned: typer, constraints.

Bevidst fravalg: du behøver ikke microservices, event sourcing eller fancy patterns. En database og et API er nok.

Uge 10: Implementér API’et og migrations

Uanset sprog ønsker du nogenlunde det her:

• En route til at oprette en ressource (POST).
• En route til at hente en liste (GET).
• En route til at opdatere eller slette (PUT/PATCH/DELETE).

Og du vil have migrations, så databasen ikke er magisk:

• Brug ORM eller migrationsværktøj (prøv at gøre det “rigtigt” fra start).
• Lav én migration til at skabe tabellerne.

Bevis for uge 10:

• En kommando (eller to) der sætter databasen op fra nul.
• Et par curl- eller HTTPie-eksempler i README der viser API’et.

Uge 11: Tests og simpel CI

Tests lyder tungt, men du skal ikke bygge en hel testafdeling. Du skal:

• Have mindst 3-5 automatiske tests på centrale funktioner.
• Opsætte GitHub Actions til at køre dem på hver push.

Det kan være:

• Enhedstests af en funktion der validerer input.
• Integrationstests af en route med testdatabase.

Bevis:

• Grøn CI-badge i README.
• En test-kommando i README, der virker.

Uge 12: Auth-valg og fejl-håndtering

Du behøver ikke “enterprise security”, men du skal have taget stilling til:

• Har appen login? Hvis ja: sessions eller tokens.
• Er der routes, som kræver auth, og routes som ikke gør.
• Hvad sker der, når noget går galt (5xx, 4xx)?

Formålet er, at du til en samtale kan sige: “Jeg valgte X, fordi Y. Hvis jeg havde mere tid, ville jeg overveje Z.”

Bevis for projekt 2 (måned 3):

• Et API dokumenteret i README med eksempler.
• Migrations der kan køre fra nul.
• Mindst 5 tests og et CI-setup der kører dem.

Uge 13 – 16: Projekt 3 – et lille system i drift

Det tredje projekt handler ikke om flere features. Det handler om drift. At noget kan leve mere end en eftermiddag.

Uge 13: Vælg en version 2 eller noget nyt (med begrænset scope)

Du kan:

• Bygge videre på projekt 1 eller 2.
• Eller lave et mindre nyt projekt med fokus på drift.

Udfordringen: Maks 3-4 features. Du lægger energi i “alt omkring” koden.

Uge 14: Logging og simple metrics

Du skal kunne svare på: “Hvad gør appen lige nu?” uden at gætte.

• Tilføj struktureret logging (med niveauer: info, warn, error).
• Lav et par simple metrics: antal requests, fejl per dag, noget i den stil.

Hvis du ikke har et fancy metrics-system, kan du starte med at logge til filer eller gemme en simpel tæller i databasen.

Uge 15: Rate limiting og back-up plan

Rate limiting lyder meget større, end det er. Pointen er:

• Du skal have en eller anden beskyttelse mod for mange requests.
• Det kan være per IP, per bruger eller bare globalt.

Back-up plan:

• Hvis din database døde i dag, hvad ville du gøre?
• Lav en lille manuel procedure: tag backup, gendan backup i et testmiljø.

Bevis her:

• En sektion i README “Drift” hvor du beskriver logning, back-up og rate limiting.
• Et script eller en kommando til at tage/gendanne backup.

Uge 16: Mini “release-notes” og oprydning

Forestil dig, at projektet var i produktion. Hvordan ville du beskrive ændringer?

• Lav en CHANGELOG.md med mindst 3 versioner (v0.1, v0.2 osv.).
• Hver version har en dato og 3-5 bullet points.

Bevis for projekt 3 (måned 4):

• Live-link til en app der har logning, en back-up plan og simpel rate limiting.
• README med afsnit om drift og CHANGELOG.

Uge 17 – 20: Interviewforberedelse og story-telling

Nu har du 2-3 projekter. De næste uger handler om at kunne tale om dem uden at gå helt i stå.

Uge 17: Skriv din historie, ikke et eventyr

Sæt 1-2 aftener af til at skrive:

• Hvor du kommer fra (din tidligere karriere, studie, ingenting).
• Hvorfor du valgte at skifte til udvikling.
• Hvad du konkret har bygget de sidste 6 måneder.

Målet er ikke en roman. Målet er, at du kan sige det højt på 1-2 minutter uden at lyde som et CV, der læser sig selv op.

Uge 18: Debugging-øvelser og “jeg ved det ikke”

Mange glemmer, at en del af et karriereskift til softwareudvikler er at kunne fejlsøge roligt.

• Gå tilbage i dine projekter og find 3 fejl, du har rettet.
• Skriv ned: hvad var symptomet, hvad prøvede du, hvad virkede.

Hvis du vil træne fejl-jagt mere systematisk, er kategorien Fejlfinding og debugging fyldt med gode eksempler på, hvordan man kan angribe bugs uden at brænde sammen.

Øv dig i at sige: “Det ved jeg ikke endnu, men sådan ville jeg finde ud af det.” Det er en bedre sætning end at forsøge at bluffe dig igennem et spørgsmål.

Uge 19: Tradeoffs – hvad du valgte til og fra

Tag ét af dine projekter og svar skriftligt på:

• Hvilken tech-stack valgte du og hvorfor?
• Hvilke to ting ville du ændre, hvis du havde en uge mere?
• Hvad droppede du bevidst for at blive færdig?

Det her bliver guld til samtaler. Det viser, at du ikke bare “fulgte en tutorial”, men tog beslutninger.

Uge 20: Simuler et lille interview

Find en ven, veninde eller familiemedlem og bed dem om 30 minutter. Giv dem 5 spørgsmål, de skal stille dig, fx:

• Fortæl om et projekt du er stolt af.
• Hvornår gik noget galt, og hvad gjorde du?
• Hvordan lærer du nye ting?

Optag det (bare lyd) på din telefon. Lyt bagefter. Du opdager hurtigt, hvor du mumler, taler for hurtigt eller går for meget i detaljer.

Bevis for måned 5 (del 1):

• Et dokument (eller bare et afsnit i README) med din personlige historie.
• Noter på mindst 3 bugs, du kan forklare som små mini-cases.

Uge 21 – 24: CV, LinkedIn, GitHub og ansøgningsrytme

Til sidst skal du pakke det hele ind på en måde, der giver mening i danske jobopslag.

Uge 21: CV hvor projekter er hovedpersonen

Hvis du ikke har formel udvikler-erfaring, er det dine projekter, der bærer CV’et. Lav en sektion:

• Projekter (og placer den over “Tidligere jobs”).

For hvert projekt:

• 1 linje: hvad det er (“Webapp til at tracke vaner for studerende”).
• 1 linje: tech-stack (“React, Node, Postgres, GitHub Actions”).
• 2-3 bullet points med resultater (“Byggede login med X, opsatte CI med tests, deployede med Y”).
• Link til GitHub og live-demo.

Uge 22: GitHub-profil og pinning

Din GitHub skal ligne en arbejdsplads, ikke en skraldespand.

• Pin dine 2-3 bedste projekter.
• Giv dem gode beskrivelser og tags.
• Arkivér meget rod, så det ikke distraherer.

Tjek også at dine README’er giver mening uden kontekst. En rekrutterer bruger måske 30 sekunder per repo. Hjælp dem lidt.

Uge 23: LinkedIn uden cringe og netværk uden spam

Dit LinkedIn-headline kan være simpelt:

• “Aspirerende frontend-udvikler | Karriereskifte fra XX | Bygger projekter i React og Node”

Lav et lille opslag, når du:

• Får et projekt deployet.
• Har bygget noget nyt, du er stolt af.

Og når du connecter med folk, så skriv en kort, ærlig besked:

• “Hej, jeg er ved at skifte karriere til frontend og bygger pt. X. Så dit opslag om Y og tænkte, det kunne være spændende at følge med.”

Uge 24: Ansøgningsrytme og justering

Sidste del: du går fra “forberedelse” til faktisk at sende ting ud.

Mål for uge 24:

• Find 10 relevante opslag (junior, praktik, trainee, studiejob, freelancerelevante ting).
• Send 3-5 målrettede ansøgninger.
• For hver ansøgning: nævn ét specifikt projekt og hvorfor det matcher.

Din ansøgning må gerne referere direkte til dine beviser:

• “Jeg vedhæfter link til en simpel webapp med login, formular-validering og CI-tests, som jeg byggede i efteråret.”

Bevis for måned 6:

• Opdateret CV og LinkedIn med projekter.
• GitHub med 2-3 pinne-de repos og gode README’er.
• Mindst 5 udsendte ansøgninger.

Checkpoints: sådan ved du, om du er klar – og hvad du gør, hvis du ikke er

Vi slutter med en lille selv-evaluering. Ikke for at dømme dig, men for at give dig en ærlig pejling.

Checkpoint 1 (uge 8): Første projekt live

Spørg dig selv:

• Har jeg et live-link, som en ven kan teste uden hjælp?
• Har jeg en README, der forklarer projektet på 1 minut?
• Kan jeg rette en lille bug i projektet på under en time?

Hvis nej:

• Skalér projektet ned. Fjern features. Få noget tiny men færdigt ud.
• Brug 1-2 uger ekstra her og hop lidt kortere over det næste projekt.

Checkpoint 2 (uge 12): API og database

Tjek:

• Kan jeg fra nul sætte database og API op via README?
• Har jeg mindst én test, der kører automatisk i CI?
• Kan jeg forklare min datamodel med ord?

Hvis nej:

• Byg en endnu mindre API: én ressource, to routes.
• Kig forbi kategorierne Data og databaser og Full stack workflows og find små, overskuelige stykker at øve på.

Checkpoint 3 (uge 16): Drift og omtanke

Spørg:

• Ved jeg, hvor mine logs havner?
• Har jeg prøvet at tage en backup og gendanne den?
• Har jeg en eller anden rate limiting eller simpel beskyttelse mod misbrug?

Hvis nej:

• Vælg én ting: logning, backup eller rate limiting. Løs den ordentligt.
• Skriv en lille note i README om, hvad du endnu ikke har løst. Ærlighed er bedre end at lade som om.

Checkpoint 4 (uge 24): Klar til at trykke “send”

Til sidst et par skarpe spørgsmål:

• Har jeg mindst 2 projekter med live-links og README på mit CV?
• Har jeg commit-historik der viser læring over tid (ikke kun én stor “initial commit”)?
• Kan jeg forklare to fejl, jeg selv har løst, uden at åbne editoren?

Hvis du mangler et “ja” til en af dem:

• Brug én ekstra måned på at polere det svageste projekt.
• Hold stadig ansøgningsrytmen kørende, men vær ærlig om, hvor du er.

Karriereskift til programmør er ikke en eksakt videnskab. Nogle får job efter 3 måneder, andre efter 12. Det, du kan styre, er mængden og kvaliteten af de beviser, du lægger online.

Hvis du kun gør én ting anderledes efter at have læst det her, så sørg for, at hvert stykke tid du bruger på at lære, ender med et synligt bevis: et lille repo, et live-link, en README, en test der kører eller en bug-historie du kan fortælle.