Over boeken en boekenclubs (2/3)
Sinds enige tijd komen enkele van mijn collega’s en ik wekelijks bijeen om een boek te bespreken dat we met z’n allen lezen. De bijeenkomst duurt een uurtje, en over het algemeen lezen we één hoofdstuk. We bespreken wat ons opviel tijdens het lezen, wat we geleerd hebben, we vergelijken de gedachten uit het boek met onze eigen praktijk, trekken lessen en formuleren plannen om veelbelovende ideeën te implementeren.
Het beginnen van een boekenclub is, als ik zo vrij mag zijn, een van de betere ideeën die ik op mijn werk heb geïntroduceerd. (Zie ook deze blog.)
*
Waarom hebben we een boekenclub? – Ten eerste: om onszelf als ontwikkelaars te ontwikkelen. Softwareontwikkeling is kenniswerk, en het bijhouden van je eigen kennis is een essentieel onderdeel daarvan.
Ten tweede, om van elkaar te leren. De boekenwijsheid die we opdoen wordt vermenigvuldigd met de wijsheid die we als individuele ontwikkelaars in de boekenclub inbrengen. Het samenkomen van die verschillende perspectieven verbreedt én verdiept ons begrip. Het kritisch bediscussiëren van ideeën maakt ons betere ontwikkelaars.
Ten derde, om beter samen te kunnen werken. Dit geldt met name voor de boekenclubleden die in hetzelfde team zitten. Een team functioneert pas een team als alle leden ervan dezelfde kant op bewegen. Door inspirerende ideeën op te nemen en deze samen te bespreken, ontstaat er een gedeeld beeld onder de leden van de boekenclub over goede software en goede softwareontwikkeling.
Ten vierde, om bruggen te slaan over teams heen. Het is al te eenvoudig voor een organisatie om in een eilandencultuur terecht te komen: verschillende teams die elk hun eigen ding doen en niet of nauwelijks met elkaar praten. De boekenclub faciliteert het gesprek over teams heen, en verkleint de drempel om ontwikkelaars uit andere teams op te zoeken.
Ten vijfde: omdat het leuk is! Er wordt heel wat gelachen bij de boekenclub, en niet alleen omdat het opdoen van nieuwe kennis intrinsiek plezierig is.
*
Een boekenclub is een investering. Elke minuut die ontwikkelaars besteden aan het lezen en bediscussiëren van ideeën over softwareontwikkeling, is een minuut die ze niet kunnen besteden aan het daadwerkelijk ontwikkelen van software.
Dat maakt het belangrijk om steun van je manager te hebben vóórdat je een boekenclub begint. Gebrek aan steun zal de boekenclub in een vroeg stadium de nek omdraaien. Er zal druk worden uitgeoefend op ontwikkelaars om “hun werk te doen” – lees: code te schrijven – en dit soort “hobbyprojecten” te laten voor wat het is.1
Maar het is in het belang van de organisatie dat de ontwikkelaars hun kennis bijhouden en bijspijkeren. Een organisatie die deze activiteiten niet ondersteunt, snijdt zichzelf in de vingers. Wanneer een organisatie kennisvergaring actief tegenwerkt, zou dat voor mij persoonlijk een reden zijn om een andere werkgever te zoeken.
*
Ik heb het geluk altijd managers te hebben gehad die doordrongen waren van het belang van kennisvergaring en kennisdeling. Uit eigen ervaring kan ik dus geen tips geven om managers te overtuigen.
De enige tip die ik kan beredeneren is: begin klein – begin bij jezelf, bijvoorbeeld. Overtuig je manager om een boek (of een aantal boeken) voor jou alleen aan te schaffen. Die investering is klein genoeg om tot weinig weerstand te leiden. Groei van de kennis die je opdoet, en wees luid en duidelijk over het feit dat het die boeken waren die je gebracht hebben tot waar je nu bent. Wanneer deze excercitie zich heeft bewezen voor jou, is het een kleinere stap om te betogen dat dit ook op grotere schaal kan werken.
De start van een junior kan ook een mooie gelegenheid zijn om een boekenclub te beginnen. (Zie ook deze blog.) Introduceer het idee als (onderdeel van) een opleidingstraject. Het idee dat beginnende ontwikkelaars meer middelen nodig hebben bij het op peil krijgen van hun kennis, is voor een manager waarschijnlijk minder moeilijk te verkopen.
*
Kan de boekenclub haar eigen doelstellingen waarmaken? Heeft het ons inderdaad betere ontwikkelaars gemaakt, die meer en beter samenwerken? – Kwantitatieve data om die vragen te beantwoorden heb ik niet. Ik weet niet of de codekwaliteit is toegenomen sinds we met de boekenclub begonnen zijn, of dat we sneller features opleveren, of dat het aantal bugs is afgenomen.
We zullen het moeten doen met kwalitatieve data. Collega’s geven aan de boekenclub als plezierig te ervaren, te leren van de inhoud van het boek en de discussies daarover, en passen verschillende ideeën die ze op hebben gedaan in de boekenclub toe in de praktijk. Dit komt ook overeen met mijn eigen ervaring.
Zo is het aantal ontwikkelaars dat bereid is Test-Driven Development (TDD) te proberen, toegenomen nadat we Clean Craftsmanship hebben gelezen. En sinds we Code That Fits in Your Head lazen, wordt code in veel kleinere commits ingecheckt. Een collega die al tijden geen ruimte vrij had gemaakt voor zelfstudie, is begonnen zich te verdiepen in functioneel programmeren, na mee te hebben gedaan aan de boekenclub. Dit alles wijst erop dat de boekenclub een rol speelt in het verbeteren van de individuele teamleden en het team als geheel.
Een ander datapunt is: het aantal ontwikkelaars dat meedoet met de boekenclub, die inmiddels aan zijn derde iteratie toe is. De eerste iteratie (Clean Craftsmanship) begon klein, binnen mijn eigen team. Bij de tweede iteratie (Code That Fits in Your Head) werd de groep uitgebreid met nieuwe junioren en enkele senioren. Bij de derde iteratie (Continuous Deployment/Head First Design Patterns) haakten nog enkele medioren en senioren aan. Tot nog toe is er nog niemand afgehaakt, niet tijdens een iteratie en ook niet erna. Dat is een teken dat de deelnemers de boekenclub als plezierig en/of waardevol ervaren.
Dat alles in acht genomen, kom ik tot de volgende conclusie:

Het platslaan van software ontwikkelen tot code schrijven is niet alleen kortzichtig, het is fundamenteel onjuist. Het idee dat ontwikkelaars alleen waarde leveren op het moment dat ze code schrijven, veronderstelt dat de hoofdtaak van ontwikkelaars is om een al bedachte oplossing om te zetten in code. Maar software ontwikkelen is nu juist voor het grootste gedeelte: erachter komen wat het (eigenlijke) probleem is. ↩︎