♻️ 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. 🌈

Ook een waterval bestaat uit uit vele kleine stapjes🏃‍♂️

Water stroomt via het pad van de minste weerstand, en niet volgens een voorgedefinieerd plan. Als er een steen verschuift, onstaat er gewoon een alternatief pad naar beneden.

Bouwen van software werkt net zo:

Door de focus te houden op het grote doel en te accepteren dat we daarna overgeleverd zijn aan de realiteit, ontstaat succes vanzelf.

Het maken van software is een kwestie van doorlopend leren van falen. Door telkens in kleine stapjes te falen, blijven de kosten van het herstel (=het leren) behapbaar en ontstaat organisch een oplossing die voor het team en de context haalbaar is.

🦄 Het gekke is dat het er, net als bij een waterval, achteraf voor toeschouwers uit ziet alsof er een geweldig plan achter zat.

Laat je niet foppen; de meest succesvolle software ontstaat niet uit een vooraf bedacht plan, maar door elke dag weer de werkelijkheid onder ogen te durven zien.

En wat doen wij tijdens dit Mobi-Dick avontuur van OpenAI? ⏰

Als de open source AI modellen on iets leren, dan is het wel dat AI als technologie begonnen is met een een race naar de bodem: De betrokken partijen doen hun best tegen steeds lagere kosten steeds meer features toe te voegen. Daarmee belooft AI sneller dan ik had verwacht een betaalbare grondstof te worden. 📉

Een fascinerende ontwikkeling is dat inmiddels 70% van de startups onder de hoede van YCombinator een product op basis van AI bouwen, en er langzamerhand waanzinnige producten op de markt verschijnen die het prutsen met een chat prompt vervangen door een ervaring die de toepassing van AI volledig verbergt.

🌈 Dit maakt mij nieuwsgierig wat dit voor ons dagelijkse werk en leven op gaat leveren, en welke innovaties ons te wachten staan. Dit is voor ondernemers zowel een kans als een nachtmerrie, want als je zelf niet innoveert dan is er een serieuze kans dat een onvermoede concurrent dit wel zal doen.

Want jij gebruikt toch inmiddels ook Perplexity AI in plaats van Google om volledige antwoorden in plaats van slechts een lijst bronnen te vinden?