Waar doe je het voor?

Een tijd terug gaf ik een presentatie bij usergroup Nimma.Codes - en met veel plezier.¹ Wat blijkt: als je af en toe een grapje maakt, dan kun je mensen best drie kwartier wakker houden met gezemel over tests en documentatie.

Maar daar wil ik het niet over hebben. Ik wil het hebben over een gesprek dat ik had voor aanvang van de presentatie, met front-end developer Bram Doppen, op dat moment een gloedjenieuwe aanwinst voor de organisatie van Nimma.Codes. We spraken over zijn werk als interactiedesigner en hoe hij plezier haalde uit het verzinnen van oplossingen waar eindgebruikers écht wat aan hebben.

We hadden het ook over waar ik plezier uit haal, en ik kwam erachter dat mijn motieven een stuk minder hoogdravend zijn.

Ik hou ervan mijn eigen werk zo makkelijk mogelijk te maken.

Makkelijker

Dat is waarom ik blogs schrijf over tests als documentatie, bijvoorbeeld. Of pull requests als documentatie. Of documentatie als documentatie. Als er is opgeschreven waarom iets op een bepaalde manier is opgezet, dan bespaart me dat het denkwerk dat opnieuw uit te vogelen.

Dat is waarom ik schrijf over clean code in het algemeen, en Test-Driven Development en refactoren in het bijzonder. Als ik, met tests als stevig vangnet, een codebase steeds een klein beetje op kan schonen, dan heb ik de volgende feature des te sneller af.

En het is ook waarom ik überhaupt blogs schrijf. Elke blog is een oefening in het redeneren over code - en de manier waarop we code schrijven. Hoe beter ik erover kan redeneren, hoe makkelijker het wordt om fouten te herkennen en te voorkomen. En - dat is het fijne aan geschreven tekst -, ik hoef al die lessen niet eens te onthouden.

(Op FutureTech in Utrecht, woonde ik een hartstikke leuke sessie bij over de verschillende manieren waarop ChatGPT je als ontwikkelaar kan ondersteunen. Maar toen werd gesuggereerd dat je AI ook kunt gebruiken om blogs te schrijven, voelde ik een haast fysieke weerstand bij me opkomen. Het hele idee van bloggen is - als je het mij vraagt althans - nu juist dat je voor jezelf helderheid creëert over het onderwerp waar je over schrijft. AI kan de output wel vervangen, maar niet het verkrijgen van een beter begrip.)

Lui

Het constant willen vereenvoudigen van je eigen werk heeft een sterke link met het idee van de luie programmeur. 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?

Unittests zijn een automatisering van alle handelingen die ervoor nodig zijn om het systeem in een bepaalde staat te brengen, een actie uit te voeren en te checken of dat het juiste resultaat had. Gerefactorde code is een automatisering van een nieuw inzicht dat je op hebt gedaan over de code - in de code zelf, nota bene. En schriftelijke documentatie is een automatisering van kennisoverdracht. In plaats van die overdracht elke keer opnieuw face to face te doen, kun je alle relevante informatie één keer vastleggen en iemand in het vervolg daar naar verwijzen.

De term “luie programmeur” is bewust prikkelend, natuurlijk. Want het automatiseren van sommige taken kan een enorme inspanning vragen. In hun inspanning om hun eigen werk makkelijker te maken, kunnen luie programmeurs zich dus absoluut geen luiheid veroorloven.

Verbeteren

Je hebt eigenlijk twee soorten luiheid, bedenk ik nu.

Destructieve luiheid is je verantwoordelijkheid verzaken. Het is het testen achterwege laten omdat je die bugfix snel naar productie wil brengen - met alle gevolgen van dien.

Constructieve luiheid is iets heel anders. Wie constructief lui is, neemt wél de verantwoordelijkheid op zich om te verbeteren - maar is ook van mening dat dat op termijn niet tot extra werklast mag leiden. Het is unittest na unittest na unittest schrijven - omdat je weet: als die er eenmaal zijn, dan breng ik alle inspanning die ervoor nodig is om te erachter te komen of de applicatie werkt, terug tot één druk op de knop.

Ja, weet je, daar doe ik het wel voor.

Als ik eerlijk ben, zijn blije eindgebruikers voor mij eerder bijvangst. Maar van die bijvangst worden teamgenoten die meer op Bram lijken dan weer blij, en dat is ook wat waard.

Waar doe jij het voor?

bloggen · clean code · documentatie · luie programmeur · refactoren · test-driven development · testen · verantwoordelijkheid · werkplezier