Stop med at gemme dig bag kedelige GitHub-links

Du sidder og stirrer på et tomt portfolio-layout

Skærmen er hvid, cursoren blinker, og du har fem GitHub-repos åbne i andre faner. Du ved godt, at du bør have en portfolio som udvikler, men alt føles enten for tamt eller for pralende.

Jeg har været der. Jeg lavede i lang tid bare en liste med links til repos og tænkte: “De kan jo bare se koden”. Spoiler: det gør de ikke. De har 5 minutter, max.

En udvikler portfolio handler ikke om at vise alt du kan. Den skal bevise nogle få, meget konkrete ting på rekordtid. Resten er støj.

Hvad en udvikler portfolio skal bevise

Især hvis du er junior eller skifter karriere, kigger en reviewer efter signaler, ikke perfekte projekter. Din portfolio skal svare på cirka de her spørgsmål:

• Kan du færdiggøre noget og få det deployet et sted?
• Kan du arbejde struktureret med kode (mappestruktur, commits, README)?
• Forstår du grundlæggende web-ting: HTML, CSS, JavaScript eller hvad du nu sigter mod?
• Kan du forklare dit eget arbejde uden buzzword-bingo?
• Udvikler du dig, eller står du stille?

Hver gang du overvejer et projekt til din portfolio, kan du stille dig selv spørgsmålet: Hvilket signal sender det her projekt?

Et notat-værktøj i ren JavaScript kan fx sende signalet: “Jeg kan bygge en lille app med state, events og localStorage”. Et u-færdigt React-projekt med halv kode og ingen README sender: “Jeg mister overblikket halvvejs”.

Struktur på din portfolio hjemmeside: byg den simpelt

Du behøver ikke fancy parallax-effekter og 3D-animationer. De må gerne komme senere. Få først en klar struktur på plads.

En portfolio hjemmeside for en udvikler fungerer typisk med 5 sektioner:

1. Hero / intro
2. Projekter (med 3-5 udvalgte cases)
3. Om mig
4. Tech stack
5. Kontakt

1. Hero / intro

Det er det første, man ser. Her skal du ikke skrive romaner. Du skal lande tre ting:

• Hvem du er
• Hvad du gerne vil arbejde med
• Hvad man skal kigge på

Eksempel:

Hej, jeg hedder Sofie, og jeg bygger webapps i JavaScript.
Jeg er junior frontend udvikler med fokus på rene brugerflader
og klar, simpel kode. Her kan du se mine bedste projekter.

Ingen “passioneret”, ingen “ambitiøs teamplayer”. Bare klart sprog.

2. Projekter

Det er her, kampen vindes. Hvert projekt bør have:

• Et kort resume (2-4 linjer)
• Et par nøglepunkter (features, læringer)
• Links til demo og GitHub

Vi kommer tilbage til en konkret case study-skabelon om lidt.

3. Om mig

“Om mig” er ikke din livshistorie. Det er kontekst til din kode.

Eksempel:

Jeg er tidligere pædagogmedhjælper, der begyndte at kode
for at lave små spil til børnene. Siden har jeg bygget
webapps med React og Node, og jeg er især glad for projekter,
der kombinerer UX og tilgængelighed.

Fortæl 2-3 sætninger om din vej ind i kode, og hvad du gerne vil fremadrettet. Tænk: “Hvad hjælper en rekrutteringsperson med at huske mig?”

4. Tech stack

Lav en enkel liste, ikke et helt våbenskab.

Del evt. op i:

• Bruger jeg jævnligt (fx HTML, CSS, JavaScript, React)
• Har jeg prøvet (fx TypeScript, Next.js, Firebase)

Det er mere ærligt end “jeg kan alt det her”. Og det gør det klart, hvad du kan sættes til i morgen.

5. Kontakt

Gør den her uhyggeligt enkel:

• Email
• LinkedIn
• GitHub

Ingen skjulte kontaktformularer uden feedback. Bare tydelige links. Hvis du vil nørde mere om HTML og struktur generelt, kan du fx kigge på denne intro til HTML-tags.

Hvilke projekter skal du vise i din udvikler portfolio?

De fleste viser for mange projekter. Jeg synes, du skal starte med 3-5 og sørge for, at de tilsammen viser progression.

Tænk progression, ikke volumen

Forestil dig, at en reviewer klikker igennem i rækkefølge. Hvad ser de?

1. Et simpelt projekt med ren HTML/CSS
2. Et interaktivt projekt med JavaScript
3. Et projekt med API-kald eller backend
4. Evt. et gruppeprojekt (hvis du har)

Det fortæller historien: “Jeg starter simpelt, bygger ovenpå, lærer nye ting og kan samarbejde”.

Vælg projekter med forskellige signaler

Brug den her lille tabel, når du vælger projekter:

Hvis to projekter sender præcis samme signal, så vælg det bedste af dem.

Case study-format: sådan skriver du om et projekt

Et projekt uden forklaring er bare et link. En case study gør det til bevismateriale.

Du kan bruge en simpel struktur:

1. Problem
2. Løsning
3. Trade-offs (valg og begrænsninger)
4. Læring

Skabelon til case study-tekst

Kopier det her og tilpas:

Problem
Jeg ville bygge en lille webapp, hvor brugere kan gemme deres yndlingsfilm
og se trailers. Målet var at lære at arbejde med et eksternt API og håndtere
asynkrone kald i JavaScript.

Løsning
Appen er bygget i ren JavaScript uden framework for at fokusere på grundlæggende
DOM-manipulation. Den henter data fra The Movie Database API og viser resultater
med søgning og filtrering.

Trade-offs
Jeg valgte at gemme brugerens liste i localStorage i stedet for en rigtig
backend for at holde projektet simpelt. Det betyder, at listen kun findes
på den enkelte enhed.

Hvad jeg lærte
Jeg blev mere tryg ved async/await og fejlhåndtering, især når API'et returnerer
fejl eller tomme resultater. Jeg lærte også at strukturere min JavaScript
kode i mindre moduler.

Det her er langt mere brugbart for en reviewer end: “Film-app lavet i JavaScript”.

Projektbeskrivelser uden buzzwords

Hvis du har siddet og stirret på “Resultat-orienteret full stack løsning” og fået lidt kvalme, så samme her.

Nøgletricket er: skriv som om du forklarer projektet for en ven, ikke som om du skriver en brochure.

Før/efter-eksempler

Eksempel 1:

Før:
"Innovativ, skalérbar to-do applikation med fokus på brugercentreret design."

Efter:
"En simpel to-do app, hvor du kan oprette, færdiggøre og slette opgaver.
Bygget i React med localStorage, så opgaverne bliver gemt mellem besøg."

Eksempel 2:

Før:
"End-to-end full stack løsning med moderne webteknologier."

Efter:
"En lille webshop-demo med produktliste, kurv og checkout-flow.
Frontend i React, backend i Node/Express og data i en JSON-fil.
Bygget for at øve routing, state og simple API-endpoints."

Mini-skabelon til tekst under hvert projekt

Brug den her under projektets titel:

Kort beskrivelse (1-2 linjer):
Hvad er det, og hvem er det til?

Fokusområde (1 linje):
Hvad ville du især lære med projektet?

Resultat (1-2 linjer):
Hvad virker nu, og hvad ville du evt. bygge på senere?

Det behøver ikke være perfekt. Det skal være læsbart.

Tech stack uden at overlove

En klassisk fejl i en udvikler portfolio er en lang liste af teknologier, du har rørt ved én gang klokken 23.47 i en tutorial.

Lav i stedet tre niveauer:

• Bruger jeg ofte
• Har jeg bygget mindst ét projekt med
• Er jeg i gang med at lære

Eksempel på ærlig tech stack

Bruger jeg ofte
- HTML, CSS (inkl. Flexbox og Grid)
- JavaScript (ES6+)
- React
- Git og GitHub

Har jeg bygget projekter med
- Node.js og Express
- Firebase Authentication
- Tailwind CSS

Er jeg i gang med at lære
- TypeScript
- Next.js

Det viser både selvtillid og selvindsigt. Og du gør det let for en arbejdsgiver at matche dig til opgaver.

Hvis du er helt ny og mest har lavet ting i ren HTML/CSS/JS, så er det også fint. Fokuser på at vise det gennem dine projekter. Du kan evt. hente inspiration i andre artikler på Coding Class, fx om at lære at kode fra bunden.

GitHub som en del af din portfolio

Din GitHub er ikke bare et lager, det er en del af din ansøgning. Mange kigger direkte i dine repos.

Derfor skal mindst dine portfolio-projekter have:

• En ordentlig README.md
• Meningsfulde commits
• En nogenlunde ren mappestruktur

README-skabelon til portfolio-projekter

Her er en simpel README, du kan kopiere og tilpasse til hvert projekt:

# Projektnavn

Kort beskrivelse af projektet (1-2 sætninger).

## Demo

Live version: <link til din deploy>

## Funktioner

- Kort punkt 1
- Kort punkt 2
- Kort punkt 3

## Tech stack

- HTML, CSS, JavaScript
- React
- API: The Movie Database

## Sådan kører du projektet lokalt

1. Klon repoet
2. Kør `npm install`
3. Kør `npm run dev`

## Læring

- Hvad du især lærte i projektet
- Udfordringer du løste

Ja, det tager længere tid at skrive. Men det gør det også 10 gange nemmere for en reviewer at forstå, hvad de kigger på.

Hvis du vil nørde mere Git, kan du senere dykke ned i ting som branches og pull requests. Men til en portfolio hjemmeside for en udvikler er en god README et rigtigt stærkt skridt.

Tjekliste før du sender din portfolio ud i verden

Inden du smider linket på LinkedIn eller i en ansøgning, så gå din portfolio igennem som en lidt sur, men retfærdig reviewer.

1. Fungerer alle links?

• Link til demo? (åbner den og virker appen?)
• Link til GitHub? (går den til det rigtige repo?)
• Kontakt-links? (åbner mail, LinkedIn, osv.)

Det her lyder banalt, men jeg har selv sendt en portfolio rundt med et dødt link til mit bedste projekt. Det var en sjov opdagelse 3 uger senere.

2. Ser den fornuftig ud på mobil?

Åbn din portfolio på din telefon. Klik rundt.

• Kan man læse teksten uden at zoome?
• Er projekterne til at klikke på med en finger?
• Ser dine screenshots nogenlunde ud på lille skærm?

Hvis du ikke ved, hvor du skal starte med responsivitet, så er en simpel mobil-first tilgang og lidt max-width ofte nok til at komme langt.

3. Loader siden nogenlunde hurtigt?

Du behøver ikke perfektionere performance, men tjek for åbenlyse ting:

• Har du uploadet 5 MB store billeder direkte fra mobilen?
• Loader du kæmpe JS-bundles til en simpel statisk side?

Komprimer billeder, fjern unødvendige scripts, og dyb vejrtrækning. Det er ikke en produktionsplatform, men du vil gerne virke nogenlunde bevidst om performance.

4. Er det tydeligt, hvad du søger?

Står der et eller andet sted:

• “Søger praktik som frontend udvikler”
• eller “Leder efter juniorstillinger inden for webudvikling”

Det hjælper både rekrutteringsfolk og udviklere med at placere dig.

5. Er sproget menneskeligt?

Læs lige din tekst højt. Hvis du skammer dig halvvejs igennem “passioneret problemknuser”-afsnittet, så skriv det om.

Hellere lidt kant og ærlighed end en tekst, der lyder som en skabelon fra et CV-site. Hvis du er i tvivl om tonen, kan du kigge på, hvordan vi skriver i andre artikler på Coding Class, fx om CV til IT-job, og læne dig op ad den stil.

6. Sender hvert projekt et klart signal?

Tag din projektliste og skriv én sætning ud for hvert projekt:

• “Det her projekt viser, at jeg kan …”

Hvis du ikke kan udfylde sætningen, eller hvis to projekter har præcis samme svar, så har du noget at rydde op i.

7. Er der mindst ét projekt, du selv er lidt stolt af?

Ikke fordi det er perfekt, men fordi du ved, hvor meget du lærte af det. Den energi kan mærkes, når du beskriver det. Og det gør det meget nemmere at tale om til samtaler.