Hva er egentlig ekte programmering, eller kanskje det viktige spørsmålet er når vi skal bruke denne kompetansen, eller til hva?
En bok av Nils Liaaen Cornieliussen og Sjur Julin prøver å sette fokus på hva ekte programmering er.
Eller dreier boken seg egentlig om hva slags livsstil en ekte programmerer bør leve?
- Dårlige utviklere tror jobben er ferdig klokka fem
Uansett, de har skapt diskusjon. Spørsmålet er om det var poenget, eller om de faktisk står inne for alle sine påstander.
Personlig mener jeg det er drøyt at man i 2023 likestiller kvaliteten på håndverket med hvor mange timer man bruker på det.
Snakker om programmering som en religion
De prater om det å være programmerer mer som en livsstil eller en religion – enn et yrke. Likevel har de også noen poenger, men kanskje ikke der de ønsket å sette fokus.
Vi trenger utviklere som er i kontakt med den verden de bygger løsninger for, og ikke bare teknologien. Og det er viktig at vi får utviklere inn i miljøene våre fra ulike livsfaser og med ulike erfaringer. For med dette vil vi bygge løsninger som er mer komplette, og som passer til andre enn for de den ble utviklet av.
Utvikling av software med kvalitet kan ikke måles kun i tid. Kvaliteten i kode dreier seg like mye om kompetanse, nøyaktighet, oppgave- og teknologiforståelse. Det er samtidig viktig at beskrivelsen av hva man ønsker å oppnå er tydelig forklart – og hvor unik oppgaven er. Skal det skapes noe nytt, eller skal man prøve å løse den samme oppgaven mer effektivt?
Selvsagt ønsker vi kode som er bygget så gunstig og lite ressurskrevende som mulig. Men at man skal gå nesten tilbake til hullkortmaskinen for å ta med seg alle minneoptimaliseringsteknikkene og triksene når minnekapasiteten var så begrensende. Det tror jeg ikke.
Glem "ekte" programmering - Martin etterlyser empatiske utviklere
Mange oppgaver er allerede løst
Med utspillet om at de ønsker mindre import og mer tenkning tar forfatterne utgangspunkt i at oppgaven som skal løses er unik. Realiteten er at veldig mange av oppgavene utviklerne står foran er løst på en aller annen måte av noen andre allerede. Og at import er det mest ressurseffektive både for utviklerne, men også for oss som samfunn.
Utfordringen blir å vite når man skal bruke tid til å finne ut hvordan man skal utvikle selv, og når man skal se om man finner noen som har løst oppgaven tidligere.
«Det er nettopp dette, at man bygger videre på, og ikke bare kopierer, som løfter en utvikler til en «ekte programmerer».»
For det er meget effektivt å lære og bygge videre på andre sine løsninger.
Det er nettopp dette, at man bygger videre på, og ikke bare kopierer, som løfter en utvikler til en «ekte programmerer». Det er gjennom samspillet vi drar utviklingen videre, og vi oppnår en kollektiv læringskurve som kan skape nye teknologiske fortrinn.
Utnytt kapasiteten best mulig
Vi bygger nå løsninger med en enorm datakraft, og det å lære å utnytte denne kapasiteten krever en annen tilnærming enn tidligere.
Den enorme datakraften gjør at viktigheten av å utnytte kapasitetene som er tilgjengelig blir en viktig lederoppgave. Enten det er ressursoptimalisering for å få bedre ytelse, lavere cloud-kostnader eller mer effektiv utviklingskapasitet.
Vi har i Norge, som i resten av verden, et gap mellom behov og kapasitet knyttet til utvikling. Mange bedrifter står foran store moderniseringsbehov, og ønsker å løse mer av oppgavene med egen utvikling. Man begrunner dette med sin egen unikhet, og at man ønsker å ivareta eller utvikle et konkurransefortrinn. Men realiteten er at man bruker kostbar kompetanse på mindre interessante eller mindre viktige arbeidsoppgaver.
Når det blir et stort gap mellom tilbud og etterspørsel på kompetanse, vil lønningene presses opp. Dette er en mekanisme som gjør at de som har et behov må verdsette kompetansen de skal kjøpe inn. Men det betyr ikke nødvendigvis at verdien av det som produseres øker tilsvarende.
"Ekte programmering": - Vi ville engasjere
Kaster bort god kompetanse
Når bedriftene tror de har unike behov, og velger å bygge selv noe som ikke er unikt, eller allerede er bygget, så vil de dyktige og «ekte» utviklerne ende opp med å gjøre mindre viktigere utviklingsoppgaver enn de har kompetanse til. Vi risikerer å overbetale for å få bygget egne løsninger, og vi kaster bort god kompetanse.
Oppgaver som enkelt kan løses krever ikke «ekte programmerere», disse oppgavene er vi bedre tjent med at løses med lavkode plattformer, eller automatiserte AI-baserte løsninger.
Utviklerne har tidligere kunnet løse enkle utfordringer ved å google seg frem til svaret, og kopiere noe fra Stack Overflow som de importerer inn i egen kodebase og utgir for sitt eget. Denne kunnskapsdelingen vi har fått til med internett har vært helt unik for menneskeheten, og har løftet oss fremover.
«De automatiserte løsningene, med nocode, lowcode, og AI-baserte verktøy vil ta unna basisoppgavene.»
Nå kan selv den ikke-tekniske produkteieren ved hjelp av ChatGPT lage dette selv. Det positive er at vi blir utfordret til når vi skal bruke de dyktige utviklerne våre til oppgaven.
De automatiserte løsningene, med nocode, lowcode, og AI-baserte verktøy vil ta unna basisoppgavene. Endelig vil vi kunne bruke de gode utviklerne på de virkelig viktige oppgavene. Og da blir jobben vår å sikre at vi vet hvilke oppgaver vi skal bygge selv, hva vi skal kjøpe, og om vi kan stole på ChatGPT.
Dette løser vi ikke ved at utviklerne bare tenker på hvordan de kan utvikle litt smartere ved å ofre tiden med venner og familie. Dette krever noe mer enn å lese en bok om ekte programmering.
