De geschiedenis herhaalt zich⌛

Aan het begin van mijn carrière was er weerstand tegen het gebruik van hogere programmeertalen, omdat daarmee de efficiëntie van handmatig coderen in machinetaal niet gehaald kon worden. En toen kwam Intel met processoren die te complex werden om er handmatig efficiënte code voor te schrijven. De rest is geschiedenis uit de oude doos, of in ieder geval een niche ambacht geworden.

Nu lees is ik dat AI maar een hype is, omdat het menselijke brein om allerlei redenen superieur is. (En niet zo lang geleden deelde ik zelf ook die indruk.)

💡Maar de evolutie gaat in de laatste maanden steeds sneller, waardoor tools als Windsurf en Aider inmiddels dingen kunnen die de ontkenners zich niet voor kunnen stellen.

En natuurlijk zijn de tools nog niet perfect, net als ik destijds om de fouten van de compiler heen moest werken. Maar dat is slechts een tijdelijke onhandigheid die vanzelf opgelost wordt.

Of juist de start van de SciFi wereld? 🚀

⁉️ AI gaat programmeurs hyper-productief maken, waardoor veel software banen gaan verdwijnen. – Of levert dit eindelijk de capaciteit om de informatiesystemen te maken die we alleen nog in films hebben gezien?

⁉️ Omdat AI straks meer kennis heeft dan elk individueel mens, is dit het einde van de menselijke beschaving. – Of levert het juist gereedschap waardoor de mensheid boven zichzelf uit kan stijgen?

⁉️ De opkomst van AI maakt ons afhankelijk van een handje vol Big Tech bedrijven die de wereld zullen beheersen. – Of zijn de collectieve belangen zo groot dat het de mensheid samen gaat brengen?

We leven in fascinerende tijden …

♻️ Hoe lang gaat jouw code mee? ⏳

Leesbare code met een duidelijke structuur kost tijd en toewijding. Sommigen noemen het heel deftig “Clean Code”, en voor anderen is het gewoon routine en gezond verstand. Het is een ontwikkelde vaardigheid die een investering in tijd en toewijding vergt. 🐌

Snel afronden zodra het lijkt te werken kost veel minder moeite, en waarom zou je tijd verspillen aan het wijzigen wat werkt? Het levert direct winst op korte termijn. Bij druk om op te leveren geeft deze manier van werken enorme voldoening, niet in de laatste plaats door de waardering door buitenstaanders met haast. 🚀

🤔 Wat is dan beter?

De meeste software is doorlopend in ontwikkeling. En om iets te wijzigen is het belangrijk om de context en impact van de wijziging te overzien. Code wordt hierdoor in praktijk veel vaker gelezen dan geschreven. Dus het levert op langere termijn meer op als juist het lezen minder moeite kost. De winst van “snel” afronden verdampt hierdoor tijdens het onderhoud, terwijl structuur en duidelijkheid zijn vruchten op de lange termijn af blijft werpen. 🌈

Is jouw code duurzaam of juist praktisch?

Vertel erover! 📣

Als freelance software bouwer verwonder ik me over de verschillen in samenwerking binnen teams waar ik mee werk: De ene keer bemoeit iedereen zich met alles, en de andere keer is het werk vooraf verdeeld en zoekt iedereen het zelf maar uit. Vooral dat laatste ervaar ik als een gemiste kans. 🦄

Als ik mijzelf een doodlopende weg in heb geredeneerd of de oplossing niet direct zie, helpt het mij om mijn redenering aan iemand anders uit te leggen. Dat ordent mijn gedachten en helpt me zo alternatieve oplossingen te ontdekken voor ik die doodlopende straat verder in ren. Feedback en “onnozele” vragen van de toehoorder zijn voor mij van grote waarde. 🚀

Dit is voor mij een van de peilers van pair-programming: 👯 Doordat de navigator de gedachtengang moet verwoorden naar de persoon achter het toetsenbord, worden gedachten geordend en redeneringen onderbouwd. Dit maakt dat 1 + 1 al snel meer wordt dan 2. (En dat staat nog los van de inspiratie die dat met zich meebrengt.)

Het viel mij op dat ook de nieuwste redenerende AI modellen hiervan gebruik maken: Ze verwoorden LLM bedenksels in tokens, om vervolgens alternatieven af te laten vallen of terug te komen op eerder suggesties. 🤖

Dat kan toch haast geen toeval zijn. 🤔

✍️ Commentaar in code is nog niet zo’n slecht idee. 🚀

💡 Heel veel jaren terug introduceerde een collega me in het concept “self-documenting code”: Het kiezen van namen voor functies en variabelen zodat uitleg in commentaar niet nodig is. We vonden het een briljante uitvinding.

Daarna heb ik geleerd om commentaar juist wel te gebruiken om toe te voegen wat er niet al in de code staat. Dus niet meer melden dat het een class of functie is, en vooral extra context voor beter begrip toevoegen. 🦄

🫣 Vervolgens heb ik door schade en schande ontdekt dat misschien wel het meest belangrijke “commentaar” bestaat uit documentatie van de structuur en intenties van de software als geheel. Dus het ontwerp of de architectuur die tijdens het bouwen op kladjes of het whiteboard staat, dan wel in je hoofd zit.

Dus doe jezelf, nieuwe teamleden (en jouw AI assistent) een plezier, en schrijf eindelijk eens de gedachten achter de code op. 🌈