anders lisdorf bloghoved

Danmark har ikke brug for programmører men programmering

Vinteren 1985 var meget kold i Danmark. Det var et godt år for snemænd, bobslæde og varm kakao, men også det år, hvor vi fik en computer hjemme hos os. En Amstrad. Ja, en Commodore 64, som alle de andre havde kunne det ikke blive til også her skulle vi være specielle. Det var på denne maskine jeg skrev mine første programmer. Det var nogle som stod i computer bladene. Det var naturligvis i BASIC, hvilket var rigtigt nemt at komme ind i. Hurtigt mistede jeg dog interessen for den tankekontrol, som lå i at følge en opskrift, som andre havde bestemt, og jeg begyndte selvfølgelig at freestyle. Jeg kan stadig huske fornemmelsen når man tastede RUN. Hvad ville der mon ske?

Men selv freestyling blev også hurtigt kedeligt, så derfor lavede jeg et program til at observere det kolde vejr: Vejrobs. Det er ikke meget jeg kan huske om dette program, men jeg er overbevist om, at man i hvert fald kunne indtaste temperaturer. Det blev aldrig rigtigt til flere programmer, fra min side, da fodbold sæsonen jo hurtigt gik i gang efter den kolde vinter.

Programmørens tilbagetog

Om jeg havde fortsat i programmeringsverden, så havde det nok været et godt træk dengang, men i dag er der noget, der tyder på, at programmering ikke er det mest oplagte karriere valg. I følge det amerikanske Bureau of Labour statistics vil behovet for programmører falde med 8% frem mod 2024

Årsagen er, at kodning kan gøres hvor som helst i verden. Det vil sige at steder med lave leveomkostninger, vil være mere oplagte steder at få kodet de systemer man skal have udviklet, da lønnen ikke behøver at være så høj her, som i f.eks. Schweitz hvor en hotdog koster det samme som en måneds husleje i Vietnam. Den åbenlyse konklusion er, at der ikke er brug for flere programmører. Den konklusion har jeg også selv draget i en tidligere blog post her på Version 2

Ikke programmører men programmering

En ny rapport fra Burning Glass kan dog nuancere dette billede noget.

De har analyseret 26 millioner unikke jobopslag. Deres nye indsigt er, at det ikke kun er i deciderede programmeringsjob, der er brug for programmeringsevner. I andre roller end software udvikling er der behov for at kunne mere end blot pege og klikke med en mus. Det er som f.eks. dataanalytiker, videnskabsmand, ingeniører og som designer, er der brug for kodeevner.

Dataanalytikere bruger muligvis visual basic i en klassisk excel verden, men det er efterånden mere almindeligt at arbejde med R eller Python i denne kontekst. Det samme gør sig gældende for ingeniører og videnskabsfolk. Web designere er efterhånden også nød til at mestre Javascript og de generelle web-færdigheder som HTML og CSS for at kunne begå sig.

Det er specielt data analytikerrollen, som antages at vokse mere end gennemsnittet i fremtiden. Derfor er der noget, som tyder på, at programmering ikke er helt ligegyldigt i den vestlige verden. Hvis vi kigger på alle disse områder, så er det netop programmering i sammenhæng med noget andet som er i fokus. En ingeniør skal jo vide noget om matematik og materialer. En videnskabsmand har jo selve det videnskabelige område som fokus om det så er delfiners sociale struktur eller pulsarer. På samme måde med data analytikeren: det er programmeringen i sammenhæng med noget andet som er værdifuldt. Ikke programmeringen i sig selv.

Programmering i fremtiden

Vi har brug for at dyrke det syntetiske i forbindelse med programmering. Vi har brug for at sætte det i en sammenhæng og fokusere på hvad det kan bruges til. Hvad betyder det, så for uddannelserne? I stedet for at promovere deciderede programmeringsuddannelser, så kunne man fokusere på at få programmering ind som en naturlig del af alle fag.

Kunne man forestille sig at visse eksamener skulle indeholde noget med kode? Hvis du i historiestudiet blev mødt med krav om at bruge kode kunne man jo tvinge folk til at være kreative. Der kan laves meget interessant humanistisk forskning baseret på data. Det kunne også integreres i design uddannelserne.

Måske kunne man introducere dataanalyse på samme måde som almen grammatik? Jeg tænker, at man skulle lære noget om data baser og løse basale SQL baserede opgaver. Denne skill vil også være vigtig i fremtiden, da en data analytikers interface med big data teknologier i høj grad vil være baseret på SQL eller lignende.

Det er faktisk her jeg ser, at vi i Danmark har gode forudsætninger, da vi i forvejen er gode til at være fleksible og søge nye veje at løse problemer på. Vi er ikke typisk begrænsede af historien, regler eller vanetænkning. Det er også det, som gør danske programmører gode i en international sammenhæng. Så, vi skal stadig uddanne programmører, men i endnu højere grad skal vi integrere programmering, som en naturlig måde at løse problemer på, selvom det ikke nødvendigvis fører til krystal klar kode og 3. normalform.

Der er mange, der ligesom jeg aldrig kan blive programmører, men som bedst kan motiveres til at programmere, hvis der er et specifikt problem at løse. Om det så blot er at observere vejret (en anden dansk specialitet), så er der en stor motivationskraft i at blive tvunget ud i at skulle bruge programmering til noget, som giver et ikke trivielt resultat.

Kommentarer (9)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Carsten Hansen

Da jeg skulle vælge studie under mikro-istiden omkring 1985 anbefalede min studievejleder at jeg skulle finde et fag og bruge IT i forbindelse hermed. Han frarådede en ren IT-specialisering, da programmører kun skulle udføre andres arbejde.

Jeg har ikke glemt formuleringen: "Aber kan programmere".

Hans udgangspunkt var vistnok administrative programmer i Comal-80 og han tænkte på snart nedlagte edb-assistent uddannelse.

Da jeg var til foredrag om SDU's supercomputer blev jeg overrasket over, at den f.eks. blev brugt på jurastudiet.

http://www.sdu.dk/om_sdu/institutter_centre/c_escience/ssc/studerende

Det er kun fantasien, der sætter grænser for, hvad supercomputeren kan bruges til: Kemikeren kan lave nye molekyler, lægen undersøge receptorer til den sidste nye medicin, humanisten datamine millioner af Facebook-sider for at finde nye sociale sammenhænge, og juristen analysere titusinder af domme for at se, hvordan de påvirker hinanden.

Derudover kommer jeg til at tænke på AI-vinteren fra 1980'erne:
https://en.wikipedia.org/wiki/AI_winter

Troen på kunstig intelligens var noget mindre dengang :-)

Jens Bengaard

Jeg har levet af softwareudvikling i snart 25 år. Ikke altid som programmør, men aldrig for langt væk fra koden. Jeg har fået at vide at Inderne kommer, og Kineserne tager mit job, for ikke at tale om alle østeuropæerne. Og de laver da også en masse. Men jeg kan stadig leve af det, og lønnen er god.

Bill Gates sagde engang at den største udfordring inden for software var manglen på dygtige programmører. Samtlige udviklede lande mangler programmører, og der kæmpes en hård kamp om dem der er.

Det du overser er, at der godt nok er kommet mange flere programmører på markedet, men behovet stiger endnu hurtigere. Jeg er ikke bekymret for mine fremtidige jobmuligheder.

Per Erik Rønne

Selv havde jeg også en Amstrad med en monokron skærm (så man fik 80 tegn Per linie), og med en kassettebåndoptager i tastaturet..

Men med to eksterne diskettedrev.

Så kunne man pludselig køre cp/m-80 og dermed noget mere seriøse programmer.

WordStar til tekstbehandling og som editor. Pascal, både turbo og mt+. COBOL og Fortran og hvad der ellers var af programmeringssprog. dBase II database og SuperCalc regneark.

I dag hører en sådan maskine hjemme på teknisk museum, og er forlængst skiftet ud med en Mac.

Men sådan så den ud:

https://en.m.wikipedia.org/wiki/Amstrad_CPC

Torben Mogensen Blogger

Det er rigtigt, at en del programmeringsopgaver bliver outsourcet til lavlønslande, men det er ikke alle programmeringsopgaver, hvor det giver mening. En del software laves i tæt dialog mellem programmører og fagspecialister, så her er det praktisk at kunne sidde i samme rum og bruge en fælles tavle til diskussion af designvalg m.m. Endvidere vil, som Jens siger, de lande, som de lavtlønnede programmører sidder i, selv have brug for de bedste af disse, så man risikere nemt kun at kunne outsource til programmører, der er så svage, at de ikke kan få arbejde i eget land.

Så mit råd er, at man, hvis man vil gøre programmering til en karriere, ikke bare lærer at kode, men sikrer sig en solid faglig ballast indenfor enten et fagområde, hvor programmering bruges, eller indenfor algoritmer, dataanalyse, eller andet specialiseret datalogisk emne. Så kommer man ikke til at mangle jobmuligheder.

David Kjær

Jeg er personligt ikke så nervøs for at AI skal stjæle mit job.... Tværtimod, så tror jeg bedre værktøjer - og et højere abstraktionsniveau - blot vil gøre os udviklere i stand til at løse endnu mere komplekse problemer.

Mht outsourcing, så er antallet af programmører i verden fordoblet ca hvert femte år siden faget begyndte at eksistere. Behovet ser bare ud til at følge med.

Kurt Frederiksen

Det er jo bare en fattig omskrivning af Levitt's

"People don't want to buy a quarter-inch drill, they want a quarter-inch hole."

Det er måske rigtigt, men du kan ikke leve af at lave huller uden at have det nødvendige bor.

Det er det samme med programmering og programmører. Når nu regnskabsfolkene e.l. har lavet programmeringen uden programmør uddannelse, så står man typisk tilbage med et vedligeholdelsesmareridt.

Man løber hele tiden på de folk som tror de kan undvære fagligt uddannede og dette er bare endnu et eksempel.

Morten Henriksen

Er på flere punkter uenig - for det første lyder det som om du mener programmører ikke tilfører anden værdi end at oversætte præcist definerede problemer til programkode. Dette er nok tilfældet for de færreste udviklere i Danmark. Det er de færreste der får et problem a la "Lav en funktion f der tager et array af tal, og som tager første tal og ganger med og gemmer i...". Hvis opgaverne var så velspecificerede (selvom denne allerede er underspecificeret) kunne man utvivlsomt spare penge ved at sende implementeringen til udlandet.

Men i praksis er hverdagen for udviklere nok anderledes. En mere typisk opgavebeskrivelse ville nok snarere være: "Det skal være sådan, at næste gang brugeren logger på, beregner systemet de tre billigste tilbud og viser i en box øverst. Hvis han så ikke vælger én af dem, så næste gang...". Det er så programmørens opgave at finde ud af hvad det kræver at løse den - det vil givetvis være noget der går på tværs af hele systemet, mange forskellige moduler, front-end og back-end, database osv. Man skal vide lidt om det hele. Bemærk også at opgaven er meget underspecificeret, og der er utvivlsomt et hav af specialtilfælde opgavestilleren ikke har tænkt på, men som bliver mere tydelige når man kender koden, datastrukturen osv. Programmørens opgave er så at træffe nogle fornuftige valg hvor der er et åbenlyst "rigtigt valg" og ellers involvere opgavestilleren i de egentlig betydende valg. At kunne identificere hvad programmøren selv kan/skal tage stilling til og hvad der er "betydende" kræver stor erfaring og afhænger også af et dybt kulturfællesskab mellem udvikler og opgavestiller. Derudover skal programmøren naturligvis også træffe fornuftige valg med hensyn til den rent tekniske implementation, hvilket utvivlsomt kan gøres mere eller mindre heldigt også mht. systemets videre udvikling osv.

Men OK, selv hvis man anerkender at softwareudvikling er mere end bare programmering, kunne man stadigvæk spørge hvorfor det ikke bare laves i udlandet? Well, man kunne med samme rimemlighed spørge hvorfor produktejeren osv. ikke sidder i udlandet? Alt kan jo laves i udlandet, verden ville sikkert køre fint videre uden lille Danmark. Men nu er firmaet altså bosat i Danmark - firmaet vil sikkert selv mene, at de har nogle unikke kompetencer for at kunne adressere et dansk marked. Bemærk f.eks. at Asien har deres egne sociale medier, søgemaskiner m.m. Her kunne man også spørge "Hvorfor bruger de ikke bare Google/Facebook"? Eller man kunne spørge "Hvorfor har Google/Facebook med deres enorme formuer og antal ansatte ikke været i stand til at tilfredsstille dette marked?".

Nå men så har erkendt at virksomheden ligger i Danmark og product managers etc. er her, er der ikke så langt til at indse fordelen i at udvikleren også er i Danmark. Kommunikationsvejen er kortere, hvilket navnlig er en fordel når man arbejder med de iterative forløb som de noget uklare krav"specifikationer" fra forretningen lægger op til. Som nævnt er der også kulturelle fordele der spiller ind. Derudover er der velkendte fordele ved at udviklingen foregår in-house, f.eks. at alle har samme chef og kan styre i én retning. I samme øjeblik ting er outsourcet har man en "agency cost". F.eks. bliver det pludselig meget afgørende hvorvidt en leverance har en fejl eller specifikationen er forkert, da det kan have betydning for om der er "leveret". Hvis alle arbejder under samme tag har man ikke den concern.

Laurits West

Når jeg læser dit indlæg forstår jeg udemærket din pointe, mn ved at læse kommentarer virker det som om vi har behov for fælles forståelse.

For mig er en programmør en person der ikke har systemudvikling og arkitektur med i sin uddannelse, kompetencer. For ganske korrekt "Aber kan programmere".
Et nyligt eksempel jeg er stødt på er i PHP hvor måden man stykker sine data sammen er arrays med arrays i en helt ulogisk opbygning. Dette viser en programmør er en der løser opgaven, men ikke har fokus på struktur og arkitektur i løsningen, eller udvidelsesmuligheder og skalerbarhed af løsningen.

Når vi så taler om en systemudvikler så vil dette for mig være en person som har fokus på opbygningen af sin kode/programmer struktureret til både den nuværende opgave, men ofte også med en tanke for fremtidige muligheder for hvordan systemet opbygges.
Jeg ville mene at langt størstedelen af udviklere i DK tilhører den sidste kategori, og som du selv er inde på så er dette det som gør os gode! Vi tænker videre end at "løse opgaven", men ser på alle aspekter i opgaven for at forstå opgaven der skal løses og hvordan den skal spille sammen med kommende opgaver og til de steder der kan være afhængigheder.
Ofte kan udfordringen være ved at outsource at hvis dette outsources til et lavtlønsland som koder opgaven uden at forstå hvorfor, tænke på performance i løsningen, struktur og fremtidsmuligheder og skalerbarhed så kan denne "vinding" i pris komme tilbage og hjemsøge dig mange gange efterfølgende.
Vi har alle oplevet systemer hvor vi har prøvet at få en opgave der siger "kan i ikke bare lige gøre det og det fra det skærmbillede der", men inde bag ved skal man pludseligt til at kalde andre dele af systemet, gøre en masse ekstra som ikke passer ind, fordi strukturen og arkitekturen i koden gør det meget svært at ændre ting på grund af bindinger.

Simple opgaver vil altid kunne outsources til en programmør, men det som gør vi vil bibeholde vores jobs er vores alsidighed og evne til at favne hele opgaven så den laves korrekt.
Jeg forventer kun at med tiden vil jeg få større muligheder med nye sprog og muligheder som gør det nemmere for mig (fx. nemmere at lave asynkrone kald), som gør jeg bliver mere effektiv og forventer ikke der vil være nedgang i efterspørgsel på folk som mig.

Netop pointen med at få de "rigtige" udviklere er her det bliver svært. Når man stiller en opgave der er meget løst defineret er det ekstra vigtigt at systemudvikleren her selv sikrer sig at danne det korrekte overblik med viden for at levere den korrekte løsning. Det er korrekt det i princippet er opgavestillers ansvar, men netop derfor det er ekstra vigtigt med en systemudvikler der selv sørger for at spørge ind til mangelområder så løsningen bliver holdbar nu, når den skal virke med andre systemer og skal virke om nogle år også. Her kommer forskellen på hvilken person du får ansat virkeligt tydeligt frem. Så alt efter opgaven vil man kunne vælge den rigtige mand for opgaven.

Log ind eller Opret konto for at kommentere