Tag Software Ontwikkelaar (Rol)

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…

Gaan we snel genoeg?

Sinds kort ben ik in van team gewisseld. Sinds die wissel mag ik mezelf met recht full stack developer noemen. Ik ben verantwoordelijk voor de back-end, de front-end – de database, de infrastructuur, security – de requirementsanalyse, de tests… Je kunt je voorstellen: het kan even duren voordat een (ogenschijnlijk) eenvoudige feature afgerond is. Af en toe maakt een knagend schuldgevoel zich dan ook meester van me: gaan we snel genoeg?

Wat is refactoring (volgens Hannah Arendt)?

Wat kunnen Hannah Arendts filosofische overpeinzingen ons leren over refactoring? Nou, bijvoorbeeld waarom de metafoor van technische schuld een misleidende is. Maar als refactoring niet het afbetalen van technische schuld is, wat is het dan wel? En wat betekent dat voor de rol die refactoring in onze dagelijkse werkzaamheden in mag (of moet?) nemen?

Koppeling buiten code om

Koppeling is: wanneer een wijziging in het ene systeem een wijziging in het andere systeem noodzakelijk maakt. Wanneer softwareontwikkelaars het over koppeling hebben, dan bedoelen we meestal: in code aan elkaar gekoppelde systemen. Maar twee systemen kunnen ook zuiver functioneel aan elkaar gekoppeld zijn, zonder ook maar één regel code te hoeven delen.

De bouwmetafoor

Softwareontwikkeling is geen constructieproces. Het bouwen (lees: “bouwen” – bouwen is een metafoor) van een applicatie is iets fundamenteel anders dan het bouwen van een huis.

Teveel tegelijk

“We zijn met teveel dingen tegelijk bezig,” constateert een ontwikkelaar tijdens de Retrospective. Die is met dit bezig, die met dat; hij met zus en zij met zo. Er is geen eenheid, iedereen werkt op zijn eigen eiland. – Het is een terugkerend thema. Waar ligt dat aan?