Profielfoto
Karl van Heijster

softwareontwikkelaar · filosoof · spreker

Ode aan Bob Dylan

var i = new Employee(“Bob Dylan”); / var farm = new Establishment(“Maggie’s Farm”);

Refactoren als context switch

Context switching heeft een slechte naam in softwareontwikkelland en dat is niet helemaal onterecht. Het is enorm vervelend als je nét lekker aan het programmeren bent – om vervolgens weggeroepen te worden voor een snelle vraag of ellenlange vergadering (die ook een e-mail had kunnen zijn). Op dat moment raak je alle informatie kwijt die je in je hoofd hebt opgebouwd om een probleem te kunnen tackelen, en mag je opnieuw beginnen. Maar dat is maar de helft van het verhaal.

Beter testen in de Agile praktijk

Een twee weken durende Sprint is te kort voor het opstellen van gedetailleerde testplannen, en wie de testwerkzaamheden bewaart voor de laatste fase van de Sprint, komt onvermijdelijk in tijdnood. Hoe kan het beter? Dat antwoord wordt gegeven aan de hand van twintig praktijkcases in De karakteristieken van een modern testproces.

Iteratief verbeteren in de praktijk

Er was een briefje op de deur geplakt, de deur richting de wc’s: “Dicht houden in verband met de kou!” Er was een dingetje dat je moest weten. Als die deur eenmaal dicht was, dan kon je de afdeling softwareontwikkeling alleen nog maar uit – niet meer in. Een slimme ontwikkelaar liet die deur dus op een kier staan. En we waren allemaal slimme ontwikkelaars – misschien was het daarom wel zo koud, bedenk ik nu.

Objectgeoriënteerd programmeren draait niet om objecten

Van Anjana Vakil leerde ik een interessante les: objectgeoriënteerd programmeren draait niet om objecten, het draait om het uitwisselen van informatie.

Het is niet jouw verantwoordelijkheid een onmogelijke deadline te halen

Er gebeurt iets wonderlijks wanneer je tegen een ontwikkelteam zegt dat die en die feature een deadline heeft: ze gaan hun best doen om die deadline te halen. Dat is een nobel streven, natuurlijk. Maar het is ook een gevaarlijk gegeven. Want niet elke deadline voor elke feature is even realistisch. Een team dat, ongeacht de haalbaarheid, gaat rennen om die deadline te halen, werkt zichzelf – en haar stakeholders – in de nesten.

Waarom zou je naar tech podcasts luisteren?

Je wordt beïnvloed door dat waar je mee omgaat. Zorg er dus voor dat je omgaat met mensen met betere ideeën dan jijzelf. Podcasts zijn een middel om een bepaalde houding te cultiveren. Die houding is er één van: ik mag tevreden zijn - trots misschien zelfs wel - met waar ik nu sta, maar ik weet dat het nog beter kan. Hoe? Door te luisteren naar hen die het beter doen dan ik.

Leren leren op het werk

De mens is een lerend wezen. Wie zijn ogen ervoor openhoudt, ziet dat we haast elke dag wel een nieuw inzicht opdoen. Maar zodra men aan het werk gaat, lijkt een groot deel van de mensen die lerende houding thuis te laten. Sterker nog, goedbedoelde leerinitiatieven worden van tijd tot tijd zelfs met vijandigheid begroet. Waarom? Zijn we toch niet zo lerend als je op voorhand zou denken?

Waar doe je het voor?

Een luie programmeur grijpt alles aan om zijn eigen werk makkelijker te maken (met uitzondering van het besparen op kwaliteit - daar is een andere term voor: een slechte programmeur). En makkelijker maken betekent meestal: automatiseren. Want waarom zou je zelf het werk doen, als een machine het ook voor je kan doen?

Tijdreis

Ik vroeg mijn collega’s: “Wat doet dit ding precies?” - waarop ze prompt de code tevoorschijn haalden en me stap voor stap door het importproces loodsten. Het was alsof ik terug werd geslingerd naar het begin van mijn ontwikkelcarrière, toen we met z’n allen een twaalf jaar oude legacy applicatie onderhielden die alleen te doorgronden was door nauwgezet de code te doorlopen. Wat blijkt: tijdreizen bestaat - je hoeft alleen maar bij een ander team te buurten.