Erfaringsvisdom til begynderprogrammøren

Mens jeg sad og skrev på min devlog, slog det mig: "Hvor er det rart egentlig at øse ud af sine erfaringer og give en del af sig selv til lidt af verden". Lad mig give lidt mere. Du kan i øvrigt ikke stoppe mig, for det er mig, der har "Udgiv"-knappen *gnæk, gnæk*

Det følgende er møntet til begynderprogrammøren, og det er generelle råd, som jeg måske selv godt kunne have brugt, da jeg startede med at programmere for over 25 år siden.

Vi lever i en verden fyldt med meninger og ekspertråd. I vores hyperoptimerede performance- og perfekthedskultur, skal det helst fremstå som om vi er fejlfri, men sandheden er jo, at det er umuligt. Og jeg tror, at mennesker, der prøver at opretholde den her perfekthedsillusion, har potentialet til at krakelere totalt, fordi der er områder, hvor de ikke kan leve op til deres egne krav.

Har egentlig aldrig følt, at jeg skulle vide alt, men jeg ville gerne have "styr på mit shit", hvis jeg blev spurgt om noget. Jeg er ikke bleg for at indrømme, at der er områder, jeg ikke har styr på. Ej heller er jeg typen, der kan læse en bog, og så klæber alting bare fast. Nej, jeg skal prøve ting af, før de sidder på "lystavlen".

 Jeg er f.eks en dør til matematik, men det skal satme ikke hindre mig i at programmere. Nøgleordet her er nysgerrighed. 

De fleste barrierer er dem vi sætter i hovedet på os selv. "Nej, det kan jeg nok ikke" - det er den værste, mest vanvittige sætning, du kan fortælle dig selv. Gu' kan du det, hvis du har viljen. Er vi enige? Godt. Ellers skriv "Jeg kan det, jeg sætter mig for" mange gange på en tavle et sted.

Nå.. Nu går det løs.

1. og absolut vigtigste råd: Tro på dig selv. Du kan ikke vide alt. Der vil altid være nogen, der er dygtigere end dig på forskellige områder. Og hvem har egentlig patent på, hvornår man er "god nok"? Ingen. Det er en tilstand, hvor man godt selv kan føle, når niveauet er der, hvor tingene sidder lige i skabet. Lyt til kritik, men lad være med at lade dig gå på af den. Som i nogensinde! Var det informativ kritik eller usaglig kritik? Vend kritikken på hovedet, og se det som en udfordring til dig for at blive klogere.

2. Vær nysgerrig. Måske synes du pointers er megasvært. Og du har ret, der findes en del koncepter, som er svære at forstå. Måske har du læst på stoffet flere gange, og forstår det stadig ikke? Se der er problemet - slip teksten, og kom i gang med at teste problemet af i praksis: Åbn kodeeditoren, tast problemkoden ind, fyr op for debuggeren, og se hvad den gør.

3. Vær en ven. Det lyder banalt, men jeg har set så mange store arrogante røvhuller ude på nettet bruge tid på at skræmme nybegyndere væk. Jeg krummer tæer, når jeg ser RTFM i supportfora ("Read The Fucking Manual"). Jeg ved ikke hvor stort problemet er generelt, men lov mig at du aldrig bliver den type, uanset hvor dygtig du bliver. Det er en uskik at nogle forsøger at skræmme andre væk, og det gavner absolut ikke branchen.

4. Find din egen sti. Elsker du Javascript og PHP, men får at vide af andre programmører, at det ikke er det rigtige, så fuck dem. Ja.. Seriøst. Det vigtigste er, at du har det sjovt, og at du får løst dine opgaver. Længere er den ikke. Jeg har hørt folk hade Javascript lige så længe, som jeg har udviklet websites og selvom sproget har sine whatthefuck-moments, så er det et sjovt sprog, og har vist sit værd gennem mange år. Nu er det praktisk talt livsnerven i WebAssembly, som baner vejen for, at vi kan programmere i andre sprog på klientsiden i browserne. Det er da et sjovt paradoks?!

5. Lad være med at tro, at du skal opfinde alting selv*. Du ender med at brænde ud, inden du kommer i gang med kernen i dit projekt. Brug de åbne kodebiblioteker, der findes på nettet. Skrev Apple MacOS fra bunden? Nej. Det er baseret på åben Unix-kode. Åben kode er virkelig en gave: Du får gennemtestet, ofte hyppigt opdateret kode, og du kan fokusere på andre ting, som er vigtige for dit projekt. (* = Medmindre du altså vil udvikle deciderede libraries)

6. Lav MVP. Minimum Viable Product. Kend dit produkt og din målgruppe. Lav kun akkurat det, der skal til for at få din applikation hurtigt ud af døren. Det lyder dovent, men vi kan ofte bruge så sindsygt meget tid på at håndoptimere kode. Du kan _altid_ vænne tilbage, og optimere senere. Jeg har brugt timer og dage på at prøve at forhåndsoptimere dele af min kode, som aldrig kom i nærheden af at skulle yde det, som jeg prøvede at optimere udfra. Så glem det. Compileren er oftest smartere end os dumme mennesker. Hvis du er uenig i ovenstående, så prøv at tænke på, hvor meget af koden, der har direkte relevans for kunden eller din slutbruger. De ser oftest kun brugerfladen. Hvis verden var indrettet korrekt, så blev der lavet film om Steve Wozniak fremfor Steve Jobs.

7. Erfarne programmører laver også fejl. Jeg laver selv, og har også set andre meget erfarne programmører lave det værste slamkode. Det gør man altså bare indimellem, sådan er det. Jeg har set arkiteturmæssigt lækker kode, som var et helvede at arbejde med, fordi der var så mange abstraktionslag, at man helt glemte, hvad koden egentlig skulle gøre.. Og så var den tilmed langsom og svær at fejlsøge. Er "poleringen" så umagen værd?