Tag boeken
Succesvol falen
Van fouten kun je leren, zegt men. Daaruit volgt: hoe meer fouten je maakt, hoe meer leerkansen je creëert. Eigenlijk zou je het maken van fouten dus moeten vieren. Hoe meer er mis gaat, hoe meer je leert – en hoe meer je leert, hoe minder er mis zal gaan. Toch is dat niet hoe het in veel organisaties werkt. Daar wordt er hard gewerkt om fouten te voorkomen. Erger nog, medewerkers die de mist in gaan, worden afgerekend op hun misstappen. Dat maakt hen voorzichtig, conservatief. En daardoor staan ze hun eigen groei – en die van de organisatie – in de weg.
Test-driven development is een ontwerpdiscipline
Een collega benaderde me laatst met een vraag over een stuk code. Hij was bezig met het implementeren van een feature om een toets met afbeeldingen om te zetten naar een PDF-representatie ervan. Zijn vraag was: hoe kom ik aan die afbeelding? Of liever: waar kom ik aan die afbeelding? Zijn eerste ingeving was om via dependency injection de relevante repository mee te geven aan de ImagePdfGenerator. - Het is een klassiek geval van het verknopen van het ophalen van data en het manipuleren ervan. Ik bleef wel met een knagend gevoel achter: hoe makkelijk blijkt het om dankzij een DI-container de verantwoordelijkheden van classes te verwateren - en wat moeten we daarmee?
Hoe hersenwetenschap programmeurs kan helpen
Er is in de vakliteratuur over softwareontwikkeling geen gebrek aan gepeperde meningen over hoe goede code eruit dient te zien. Goede code is naar hun mening eenvoudig, bijvoorbeeld, of testbaar of uitbreidbaar. Je zou kunnen zeggen dat hun redenen erop geënt zijn software zo goed mogelijk te kunnen onderhouden. Wie dat zou moeten doen en hoe ze dat aan moeten pakken, daar zijn de meningen minder gepeperd over. Veel professionals lijken code te beschouwen als iets wat op zichzelf staat, zonder veel oog te hebben voor de programmeurs die dat onderhoud zouden moeten plegen. Dat geldt niet voor Felienne Hermans. In The Programmer’s Brain behandelt ze vragen als: wat gebeurt er in het brein als je code leest? Hoe leer je zo efficiënt mogelijk nieuwe programmeertalen en -concepten? En hoe kun je deze kennis inzetten om betere code te schrijven?
Hoe review je eigenlijk code?
Hoe lees je eigenlijk code? Waar begin je? En in welke volgorde loop je code door? - En zit er verschil tussen het lezen van code tijdens je programmeerwerk en tijdens een code review? Ik stelde mezelf onlangs die vragen, na in Felienne Hermans' The Programmer’s Brain te hebben gelezen dat gevorderde programmeurs op een andere manier code lezen dan nieuwelingen.
Objectgeoriënteerd en functioneel BTW berekenen - Revisited
Ik plaatste een tijd geleden wat kanttekeningen bij mijn aanpak Enrico Buonanno’s uitdaging om een objectgeoriënteerde BTW-calculator te schrijven. Zo zette ik mijn vraagtekens bij het feit dat ik zijn oorspronkelijke model één op één overnam. Die keuze bracht met ertoe een aparte VatCalculator-class te definiëren. En hoewel die objectgeoriënteerd was opgezet, viel deze makkelijk om te schrijven naar een functionele variant. De vraag wierp zich op: hoe objectgeoriënteerd is die oplossing? Is de vergelijking daarmee wel eerlijk? Hoe zou een “echt” objectgeoriënteerde oplossing eruit zien?
De elf rollen van variabelen
Pas wanneer de vanzelfsprekendheid van code in het geding komt, gaan we nadenken - écht nadenken - over wat er op je scherm staat en waarom. Pas dan wordt de vraag “Wat doet deze variabele hier precies?” relevant. Goed, vraag jezelf nu eens af: als dat moment komt, hoe beschrijf je de rol van een variabele dan? - Heb je enig idee waar je moet beginnen bij het beantwoorden van die vraag?
Objectgeoriënteerd en functioneel BTW berekenen
In het eerste hoofdstuk van Enrico Buonanno’s Functional Programming in C# (Second Edition) demonstreert de auteur wat functionele features van C# aan de hand van een concreet voorbeeld: het berekenen van de BTW op een (lijst) product(en). Buonanno raadt de lezer aan om dezelfde functionaliteit ook op een objectgeoriënteerde manier te implementeren, om die oplossing te kunnen contrasteren met de zijne. Dus dat is precies wat ik heb gedaan.
Zelfs de testpiramide is niet meer heilig!
Ik ben altijd in de veronderstelling geweest dat mijn geautomatiseerde tests een piramidevormige verhouding tot elkaar zouden moeten hebben: aan de basis enorm veel unittests, in het midden een goede hoeveelheid integratietests, en aan de top een bescheiden aantal end to end (E2E) tests. Totdat ik Learning Domain-Driven Design van Vlad Khononov las. (Een aanrader, overigens!)
Is kunstmatige intelligentie wel écht intelligent?
Kunstmatige intelligentie (ook wel artificiële intelligentie of kortweg AI genoemd) heeft de laatste jaren een enorme opmars gemaakt. AI neemt een steeds prominentere plek in in het dagelijks leven: van vertaalmachines tot gepersonaliseerde advertenties tot gerobotiseerde obers. Hoog tijd dus om filosofisch op dit fenomeen te reflecteren. Wat is AI? Kunnen computers echt denken? Wat is denken überhaupt? En wat zijn de ethische en politieke implicaties van de steeds grotere rol die AI in de samenleving speelt? Deze en andere vragen komen aan bod in Guido van der Knaaps Van Aristoteles tot algoritme: Filosofie van kunstmatige intelligentie.
Incidentanalyse zonder schuldigen
Wat doet jouw team na een productieverstoring? En wat doet jouw team als een eindgebruiker een bug meldt? - Wat bij een grote bug? Wat bij een kleine? Neem je het ter kennisgeving aan, en ga je op dezelfde weg door? Ga je met vingers wijzen en mensen uitfoeteren voor hun nalatigheid? Of kijk je naar manieren waarop je de productieverstoring of bug in de toekomst kunt voorkomen? En waar kijk je dan naar - naar het individu, of het systeem?