"Code was nooit het moeilijke deel" is een belediging voor alle programmeurs

Het vak van softwareontwikkeling bevindt zich in het midden van een omwenteling. Niemand weet hoe de AI-revolutie uiteindelijk zal uitpakken, maar het is duidelijk dat veel aspecten van werk en leven zullen transformeren — inclusief programmeren.

Een van de opmerkingen die ik de laatste tijd vaak hoor, komt neer op: "LLM's zijn misschien goed in coderen, maar software was nooit het moeilijke deel" en "coderen is makkelijk, bepalen wat je moet coderen is wat moeilijk is".

Ik geloof dat dit een grove belediging is voor alle programmeurs wereldwijd.

Als coderen makkelijk is...

Als coderen makkelijk is, hoe komt het dan dat programmeurs jarenlang zeer gewild waren en hoge salarissen vroegen (zelfs vóór de periode van ZIRP)? Waarom was er zoveel stress, overwerk en burn-out, nog voordat AI begon met het uitspugen van pull requests van 5000 regels? Waarom zochten bedrijven naar '10x ninja rockstar coders' en onderwierpen ze hen aan leetcode-interviews — zou een junior die net van de universiteit komt toch iets kunnen produceren als het zo makkelijk is?

Als coderen makkelijk is, waarom hebben we dan dikke boeken als Clean Code en The Pragmatic Programmer? Is The Art of Computer Programming een lichte zomerlektuur? Is SICP een koffietafelboek? Waarom zijn er bootcamps of zelfs volledige universitaire opleidingen aan gewijd?

Als coderen makkelijk is, was Carmack dan gewoon op de juiste plek op het juiste moment? Waarom beschouwen we Fabrice Bellard als een genie?

Als coderen makkelijk is, waarom zijn mensen dan boos dat AI (of iemand anders) hun code kopieert? Waarom doen ze alsof ze hun zweet, ziel en enorme hoeveelheden tijd in iets triviaals hebben gestoken?

Als coderen makkelijk is, waarom hebben velen nu het gevoel dat hun identiteit en professionele doel hen worden ontnomen?

Als coderen makkelijk is, waarom is software dan zo verdomd buggy?

Als bepalen wat er gebouwd moet worden het moeilijke deel is...

Als beslissen wat er gebouwd moet worden het moeilijke deel is, waarom lijken zoveel productmanagers dan clueless? Waarom zijn er voor hen geen rigoureuze 10-staps interviews? Waarom worden zij niet beter betaald dan de ontwikkelaars?

Als beslissen wat er gebouwd moet worden het moeilijke deel is, waarom worden marktonderzoekers, usability-experts en — godzijdank — customer success-medewerkers dan niet beschouwd als de rockstars van een softwarebedrijf? Als "de klant begrijpen" moeilijker is, waarom worden business analisten dan weggezet als kantoorklerken?

Als implementatie makkelijk is en het vinden van de vraag moeilijker, waarom zijn programmeurs dan boos wanneer verkopers een nieuwe functie beloven aan een klant om de deal te sluiten? Ze hebben immers een echte vraag gevonden; iets waar mensen voor willen betalen!

Als coderen makkelijk is, waarom bouwt dan niet iedereen gewoon tien variaties van een product om te zien welke aanslaat?

Er bestaat geen gemiddelde programmeur

Een andere clichématige opmerking is: "het grootste deel van het werk in softwareontwikkeling bestaat uit praten met stakeholders, het begrijpen van de behoeften van de klant en duidelijkheid hebben over de prioriteiten".

Ik heb in mijn carrière veel programmeurs ontmoet, en zeer weinigen van hen willen met stakeholders praten, laat staan met klanten (uitzonderingen zijn freelancers en oprichters, vooral van softwarehuizen). En "duidelijkheid over de prioriteiten" komt vaak neer op: "vertel me gewoon wat ik moet doen en verander het niet om de twee dagen".

Sommige softwareontwikkelaars zeggen: "Ik schrijf geen code, ik los de problemen van de klant op". Maar vervolgens beginnen ze te filosoferen over monaden, memory safety en DRY-principes, terwijl hun begrip van de klant een verzonnen "user persona" is, en ze denken dat "affordance" het zakgeld is dat je ouders je vroeger gaven om in het weekend uit te gaan.

Anderen zullen zeggen: "Softwareontwikkeling is theorievorming". Programma's zijn in feite bewijzen (zoals wiskundige bewijzen). Elke commit zou een verhaal moeten vertellen. En het probleem van een klant oplossen door simpelweg een PHP-bestand via FTP te uploaden, is een doodzonde.

Ik wil niet suggereren dat er geen ontwikkelaars zijn die zich tegelijkertijd intensief bezighouden met het vakmanschap van softwareontwikkeling én echt empathie hebben voor de klant. Hoewel ik geloof dat zij wellicht professionele hulp zouden kunnen zoeken voor een gesplitste persoonlijkheid.

Wat is belangrijk?

Ik geloof dat praten met gebruikers, hun ervaring begrijpen, empathie tonen, de problemen van klanten oplossen en alle stakeholders op één lijn krijgen cruciaal is voor het succes van een softwareproject.

Ik geloof ook dat het schrijven van goede code een ambacht is dat vaardigheid, geduld, oog voor detail, ervaring en wijsheid vereist, en dat dit in de komende tijd relevant zal blijven.

Waarom niet allebei?

Voor zover we dat kunnen realiseren, denk ik dat we naar beide moeten streven: een diepgaand begrip van het systeem dat we bouwen, samen met een diepgaand begrip van waarom we het bouwen.

Luidkeels proclameren dat "code makkelijk is" of, aan de andere kant, dat "code kunst is, een creatieve menselijke uiting die niet geautomatiseerd kan worden", is niets anders dan je hoofd in het zand steken.

Het is een overlevingsmechanisme (cope). En je wilt niet alleen overleven; je wilt groeien.

Hiermee bedoel ik niet: "spring op de LLM-trein." Ik bedoel niet: "word een manager van vloten AI-agenten." Ik bedoel ook niet: "AI-gegenereerde code is gestolen troep, vecht er met hand en tand tegen, de bubbel zal toch snel knappen."

Maar erken dat we ons in het midden van een sectorbrede tektonische verschuiving bevinden. We moeten uitzoeken hoe we ons kunnen aanpassen. We moeten begrijpen wat waarschijnlijk zal veranderen en wat nooit verandert.

Wat verandert er niet?

Software zal complexer worden. Software zal altijd onderhoud nodig hebben: bit-rot is een feit van het leven, net als entropie. Technologie (zowel hardware als software) zal vooruitgaan, voor beter of slechter. De toren van abstracties wordt steeds hoger.

Gebruikers zullen altijd meer willen en bereid zijn minder te betalen. Ze zullen nog steeds niet weten hoe ze hun behoeften en wensen moeten overbrengen. Erger nog: ze zullen nog steeds niet precies weten wat ze willen. De kloof tussen de klanten (die daadwerkelijk voor de software betalen) en de gebruikers (die het gebruiken) zal blijven bestaan, evenals de spanning tussen de behoeften van het bedrijf en die van zijn klanten.

En alsof dat niet genoeg is: er zal nooit een tekort zijn aan kwakzalvers. De techniek van de dag komt en gaat (ik wacht nog steeds op de nieuwe VR-renaissance!).

Wat verandert er wel?

Programmeurs zijn vanaf het begin bezig geweest met het ontregelen van hun eigen industrie. Niemand gebruikt ponskaarten meer. Zeer weinig mensen hoeven nog in Assembly of COBOL te coderen. De decennia die besteed zijn aan het bestrijden van memory-bugs in C of C++, met de littekens om het te bewijzen, zijn waardeloos in het tijdperk van Rust, Go, Python en JavaScript.

Ik ben oud genoeg om Valgrind te waarderen of me mysqlrealescape_string() uit het PHP4-tijdperk te herinneren — zaken die ik nooit meer in mijn leven nodig zal hebben. En dat was nog niet eens zo lang geleden! Ik heb net de tijd van dBase, Clipper, HyperCard en Access gemist; technologieën die ik nog steeds zie draaien in winkels, cafés of op een stoffige, ooit beige en nu goudbruine mid-tower die nog vrolijk een op maat gemaakte zakelijke oplossing draait (backups? welke backups?).

Hoe kunnen we groeien?

Accepteer dat verandering gebeurt. Wees zowel nieuwsgierig als kritisch over nieuwe dingen.

Begrijp dat er veel hype is en probeer onderscheid te maken tussen warme lucht en wat echt werkt (en in hoeverre). Wees je ook bewust van de constant verschuivende doelpalen: neem afstand en kijk naar het afgelopen jaar, of de afgelopen vijf jaar, en beoordeel de snelheid van verandering (technisch, economisch, maatschappelijk).

Je rol en je verantwoordelijkheden zullen veranderen. Wees bereid om tijd en energie te investeren in het beter begrijpen van vakgebieden of rollen die grenzen aan die van jou.

Ben je een senior developer? Zoek je heil niet alleen in het verdiepen van je expertise. Leer over gebruikerservaring (UX), klantinterviews of bedrijfsstrategieën voor de bedrijven in jouw domein. Het zal je helpen een beter besef te krijgen van al het werk dat nodig is om software in de handen van gebruikers te krijgen, of je die andere taken nu daadwerkelijk zelf moet uitvoeren of niet.

Begin je net of ben je een junior? Investeer in het verdiepen van je begrip van hoe software werkt. Inzicht in pointers, recursie of geheugenhiërarchie zal je helpen, zelfs als je een JavaScript-ontwikkelaar bent. Het begrijpen van netwerkprotocollen en hoe HTTP werkt is nuttig, zelfs als je WordPress-plugins bouwt. Doe leetcode en leer over algoritmen en datastructuren, zelfs als je ze niet direct nodig hebt. Wees niet bang om te vragen waarom en hoe precies iets werkt.

Ter inspiratie zijn hier enkele boeken en andere bronnen die nuttig kunnen zijn:

• Structure and Interpretation of Computer Programs (PDF)
• Cracking the Coding Interview
• The Mythical Man-Month
• Working Backwards
• Team Topologies
• 7 Powers
• The Soul of a New Machine
• Obviously Awesome
• The Design of Everyday Things
• Don't Make Me Think
• Continuous Discovery Habits
• The Mom Test

Nog één ding

Wie je ook bent, besteed je begrip, oordeelsvermogen, empathie en smaak niet uit aan AI. Ontzeg jezelf niet je verantwoordelijkheid. Wees geen menselijke proxy.