Hvilket språk du bør begynne med, hvorfor valget betyr mindre enn du tror, og hvordan du unngår å bruke et helt år på kurs uten å få laget noe.
Endre tallene og teksten i de blå feltene. Resultatet oppdateres mens du skriver. Dette er tre av de få tingene all programmering bygger på: regne ut, gjenta og velge.
Ingenting sendes noe sted. Feltene tolkes som tall og tekst, aldri som kode — derfor kan du ikke skrive kommandoer inn i dem.
Det første spørsmålet alle stiller er hvilket språk de skal begynne med, og det er spørsmålet som stjeler mest tid til minst nytte. Grunnbegrepene — variabler, betingelser, løkker, funksjoner, lister — er de samme overalt. Når du har dem i ett språk, tar språk nummer to noen uker, ikke noen år. Folk som har kodet i ti år bytter språk når prosjektet krever det, og bruker ikke lang tid på det.
Likevel er ikke alle startspråk like gode. Et godt førstespråk har lite seremoni før du får til noe, og gir tydelige feilmeldinger. To valg peker seg ut:
Alt annet er et spesialvalg. Skal du lage iPhone-apper trenger du Swift, Android-apper Kotlin, og spill i Unity krever C#. Men da har du allerede et mål, og dermed allerede svart på spørsmålet.
| Språk | Brukes til | Vanskelighet | Du kan lage |
|---|---|---|---|
| Python | Automatisering, data, KI, server | Lett | Skript som rydder filer, botter, analyser |
| JavaScript | Nettsider, apper, server | Lett til middels | Nettsider som gjør noe, små spill |
| HTML og CSS | Struktur og utseende på web | Lett | Sider — men det er ikke programmering |
| SQL | Spørringer mot databaser | Lett | Rapporter og uttrekk fra data |
| C# | Spill i Unity, forretningssystemer | Middels | 2D- og 3D-spill, skrivebordsprogram |
| Java | Store systemer, Android | Middels | Bank- og bedriftssystemer |
| Swift | iPhone og iPad | Middels | Apper til App Store |
| Rust eller C | Systemnær kode, ytelse | Vanskelig | Operativsystemer, motorer, verktøy |
Nesten all kode er kombinasjoner av seks ideer. Når du kjenner dem, kan du lese kode i språk du aldri har sett.
Dette tar noen uker å lære og resten av livet å bli god på å kombinere. Alt du møter senere — rammeverk, databaser, skytjenester — er lag oppe på disse seks.
Mønsteret er velkjent. Du følger et videokurs, alt gir mening mens du ser på, du skriver av koden og den virker. Så åpner du et tomt vindu for å lage noe selv, og hodet er blankt. Det føles som om du ikke har lært noe. Reaksjonen er som regel å starte enda et kurs, og der blir folk sittende i månedsvis.
Forklaringen er ikke at du er treg. Den er at gjenkjenning føles som kunnskap. Når du ser løsningen, kjenner du den igjen, og hjernen tolker det som at du kan den. Å hente den fram fra ingenting er en helt annen operasjon, og den øver du bare ved å gjøre nettopp det. Det er samme mekanisme som gjør at å lese notatene om igjen før eksamen føles tryggere enn å teste seg selv, men gir dårligere resultat.
Veien ut er ubehagelig og kort: bygg noe eget før du føler deg klar. Velg et problem du faktisk har — en kalkulator for noe du regner på ofte, et skript som døper om bildefiler, en side som viser når bussen går. Skriv den uten oppskrift. Slå opp alt du trenger underveis; det er lov, og det er slik profesjonelle jobber. Resultatet blir stygt. Det er likevel mer verdt enn det tiende kurset.
Nybegynnere leser feilmeldinger som en dom. Erfarne leser dem som en adresse. Forskjellen forklarer mye av forskjellen i tempo.
En typisk feilmelding inneholder tre ting: hvilken fil og hvilket linjenummer problemet oppsto på, og hva slags feil det er. Les nederste linje først — det er der den faktiske meldingen står. Gå så til linjen som nevnes, og husk at feilen ofte ligger på linjen over hvis det handler om en manglende parentes.
Fire feiltyper dukker opp igjen og igjen:
Kopier hele feilmeldingen inn i et søk. Noen har hatt akkurat samme problem, og det er ikke juks å lese svaret. Det er juks å lime inn løsningen uten å forstå hvorfor den virker.
Mange venter at man skriver kode og av og til må fikse noe. I praksis er fordelingen omvendt: mesteparten av tiden går med til å finne ut hvorfor noe ikke oppfører seg som det skal. Erfarne utviklere er ikke folk som skriver feilfri kode. De er folk som finner feilen raskere.
Metoden er systematisk, ikke genial:
Git er versjonskontroll: et system som husker hver versjon av koden din og lar deg gå tilbake. De fleste utsetter det fordi det ser komplisert ut. Det er en feil, for det er nettopp som nybegynner du ødelegger ting.
Du trenger fire kommandoer i starten. git init starter sporing i en mappe. git add merker hva som skal lagres. git commit lagrer et øyeblikksbilde med en beskjed om hva du gjorde. git push sender det til GitHub. Det er alt, og det tar en ettermiddag.
Gevinsten er dobbel. Du tør eksperimentere når du vet at du kan angre, og du bygger samtidig en offentlig profil. En GitHub-konto med jevn aktivitet over et år sier mer til en arbeidsgiver enn et kursbevis.
Det finnes uendelig mye gratis materiale, og kvaliteten spriker. Noen typer er verdt tiden:
Velg én hovedkilde og hold deg til den til du er ferdig. Å hoppe mellom fem kurs som alle dekker de samme tre første kapitlene er den vanligste måten å bruke et halvår på ingenting.
Kodeassistenter skriver fungerende kode raskere enn du rekker å lese den. Det gjør dem både nyttige og farlige for en som skal lære. Faren er ikke at koden blir dårlig — den er ofte grei. Faren er at du får et resultat uten å ha gjort arbeidet som skaper læring.
Tre regler som fungerer i praksis:
Brukt slik er dette den beste læreressursen som har kommet på lenge: du har alltid noen å spørre, og den blir aldri lei av deg.
Tallene under er grove og varierer mye med bakgrunn og innsats. De er tatt med fordi urealistiske forventninger er en av de vanligste grunnene til at folk gir seg.
| Innsats | Etter 3 måneder | Etter 1 år |
|---|---|---|
| 20 min per dag | Forstår kode du leser | Små skript som sparer deg tid |
| 1 time per dag | Små nyttige programmer | Egne prosjekter fra bunnen |
| 3 timer per dag | Enkle apper og nettsider | Portefølje som kan vises fram |
| Fulltid | Kan bidra i et prosjekt | Aktuell for juniorstillinger |
Spredning slår skippertak. Fem økter på en halvtime gir mer varig ferdighet enn én økt på to og en halv time, selv om summen er den samme. Grunnen er at hver gang du må hente stoffet fram igjen etter en pause, styrkes minnet. Koder du bare i helgene, går store deler av lørdagen med til å komme tilbake dit du var.
Utdanning gjør veien kortere, men er ikke et krav. Selvlærte får jobb, og da avgjør tre ting.
Porteføljen. Tre til fem prosjekter som faktisk kjører, ligger på GitHub og har en README som forklarer hva de gjør og hvorfor. Ett gjennomarbeidet prosjekt slår ti halvferdige. Helst noe som løser et ekte problem, ikke enda en gjøremålsliste fra et kurs.
Evnen til å forklare. På intervju får du spørsmål om valgene dine. «Hvorfor løste du det slik?» er et bedre spørsmål enn noen algoritmetest, og du kan bare svare hvis du faktisk skrev koden.
Utholdenhet i søkeprosessen. Regn med mange avslag, også på stillinger du passer til. Søk bredt, ta kontakt med konsulentselskaper som tar inn juniorer i kull, og vurder læreplass eller praksis hvis du er ung. Bidrag til åpen kildekode er en av få måter å få ekte erfaring på uten å ha jobb.
Vil du bygge noe konkret å vise fram, er en enkel hjemmeside eller en liten app et fornuftig første prosjekt.
Python hvis du ikke har et konkret mål, fordi syntaksen er ryddig og du slipper mye støy før du får til noe. JavaScript hvis målet er nettsider, siden det er det eneste språket nettleseren kjører direkte. Valget betyr mindre enn folk tror: grunnbegrepene er de samme, og språk nummer to tar en brøkdel av tiden.
Med en time om dagen får de fleste til små, nyttige programmer etter to til tre måneder. Å være god nok til å bli ansatt tar oftere ett til to år med jevn øving og ekte prosjekter. Tallene varierer mye, men mønsteret er stabilt: jevnlig øving over lang tid slår intensive perioder etterfulgt av pause.
Tutorial hell er tilstanden der du følger kurs etter kurs, forstår alt mens du ser på, og står helt blank når du skal skrive noe selv. Årsaken er at gjenkjenning føles som kunnskap. Løsningen er å bygge noe eget uten oppskrift, selv om resultatet blir stygt og du må slå opp alt underveis.
Til vanlig programmering trenger du ungdomsskolematematikk: de fire regneartene, prosent og litt logikk. Grafikk, maskinlæring og kryptografi krever mer, men det er spesialiseringer. Det du faktisk trenger er tålmodighet med detaljer og evnen til å dele et problem i mindre biter.
Bare hvis du limer inn svar uten å lese dem. Regelen som fungerer er enkel: skriv løsningen selv først, bruk verktøyet til å forklare hva du ikke forstår, og aldri godta kode du ikke kan gjenskape linje for linje. Da blir det en lærer i stedet for en snarvei.
Nei, men det gjør veien kortere. Selvlærte får jobb hver dag, og da er det porteføljen som avgjør: tre til fem fullførte prosjekter som kjører, med kode andre kan lese. Regn med flere avslag enn du liker, og søk bredt på junior- og konsulentstillinger.