software ontwikkelaar (rol)
AI vs. ontwikkelaars
Kijk uit, merkte mijn manager op: een groot deel van haar sollicitanten was aan het solliciteren geslagen precies omdat hun huidige werkgever vol op AI had ingezet. De ontwikkelaars voelden zich niet meer thuis in die nieuwe wereld. Ze hadden er een hekel aan enkel nog code te reviewen, ze wilden weer terug code met de hand te schrijven. Hebben die ontwikkelaars het mis? Blijven zij achter?
Twee soorten verantwoordelijkheid
Programmeren en testen horen bij elkaar, het zijn twee kanten van dezelfde munt – en die munt is: productierijpe software opleveren. Daaruit volgt dat de activiteiten van het programmeren en testen verenigd moeten worden in één persoon – en die persoon is de ontwikkelaar. Dit wijkt af van de traditionele rolverdeling, waarin programmeurs programmeren en testers testen. Wat is dan nog de verantwoordelijkheid van de tester?
Twee doelen van een ontwikkelteam
Een softwareontwikkelteam heeft, in abstracto, twee doelen: vernieuwing en veiligheid. Een team bestaat daarom, zou je kunnen stellen, uit twee delen: ontwikkelaars en testers. Deze conceptualisatie van een ontwikkelteam is het gevolg van een vorm van reductionisme. Maar een team valt niet te reduceren tot haar samenstellende delen. Ze bestaat uit haar samenstellende delen plus hun vormen van interactie.
De vergeten tester
Testen is cruciaal voor softwarekwaliteit. En toch, toen ik de kans kreeg een nieuw agile softwareteam samen te stellen, “vergat” ik de tester. Hoe verklaren we deze paradox? Hoe kan een tester tegelijkertijd zó belangrijk en toch ongewenst zijn?
Een tip voor testers
Elke softwareontwikkelaar weet dat hij zijn werk goed moet testen. Waarom glippen de meest voor de hand liggende bugs er dan toch doorheen? Omdat testen bij testers is belegd. Dat klinkt voor programmeurs verleidelijk efficiënt: waarom tijd besteden aan het schrijven van tests als iemand het werk toch nog naloopt? Deze taakverdeling nodigt uit tot lagere codekwaliteit en legt de pijn daarvan bij testers.
Wat drijft je?
We lazen The Phoenix Project in de boekenclub. Bij de scène, dat is inmiddels alweer weken geleden, waarin alle managers bijeenkomen en hun levensverhaal delen, zei een medelezer: “Dit is heel belangrijk, want als je goed wil kunnen samenwerken, moet je weten wat je collega’s drijft.” Die opmerking is bij me blijven hangen, dus het leek me een mooie gelegenheid om te reflecteren over de vraag: wat drijft me eigenlijk als softwareontwikkelaar?
Aantekeningen over continuous deployment
De grootste uitdaging in het omarmen van continuous deployment ligt niet in het technische aspect. Deployment pipelines zijn anno 2026 alomtegenwoordig, unittesting is (bij de meeste teams) niet meer optioneel, en feature flags zijn in hun simpelste vorm niet meer dan eenvoudige booleans. Om continuous deployment een succes te kunnen maken, zullen de mensen hun vertrouwde manieren van werken moeten herzien.
Functietitels vervormen de werkelijkheid
In Being at Work maakt Mark Cole een interessante observatie over het vervormende effect van functietitels. In zijn existentiële analyse betekent dit: een vervormend effect op de zelfperceptie. Maar functietitels hebben ook een vervormend effect op de werkvloer zelf. Hun effect op de manier waarop werknemers hun taak opvatten, kan desastreuze gevolgen hebben.
Een ontwikkelaar is verantwoordelijk voor drie systemen
Ik weet niet meer waar ik de inval had, onder de douche of op de wc of tijdens het tanden poetsen (duidelijk is in elk geval dat het op de badkamer was): een ontwikkelaar is verantwoordelijk voor (ten minste) drie systemen.
De vergeten tester
Twee dingen kunnen tegelijkertijd waar zijn. (1) Ik vind de tester de belangrijkste rol hebben in het team. (2) Ik wil geen tester in het team. – Ik wil haast zeggen: de rol van de tester is te belangrijk om bij een tester neer te leggen, maar die uitspraak is makkelijk te misinterpreteren en nodeloos provocerend. En toch…