Waarom zijn zoveel programmeurs bètanerds?
Als filosoof kan ik een titel als How do our ideas about coding affect the software we create? natuurlijk moeilijk weerstaan - en ik heb dan ook met veel plezier naar het gelijknamige praatje van Christin Gorman gekeken.
Gorman begint vanuit een probleem: de softwareontwikkelpopulatie (3x woordwaarde) is weinig divers. Ze bestaat, gechargeerd gezegd, voor het grootste gedeelte uit nerds met interesses in de hoek van de bètawetenschappen. Hoe komt dat?
Techniek
Volgens Gorman is dat terug te herleiden naar twee algemeen geaccepteerde ideeën over wat software ontwikkelen precies inhoudt. Het eerste is dat softwareontwikkeling is een discipline die nauw verwant is met de bètawetenschap - dat wat in het Engels STEM wordt genoemd: science, technology, engineering, and mathematics.
Dit idee heeft ook zijn weg gevonden naar de manier waarop softwareontwikkeling onderwezen wordt. Wie zich het programmeervak eigen wil maken, zal zich vooral moeten focussen op het leren van de syntax van een programmeertaal. Diegene leert welke datastructuren er allemaal bestaan, en hoe hij of zij algoritmen schrijft om zo efficiënt mogelijk een lijsten te doorzoeken of een handelsreiziger aan het werk te houden. Softwareontwikkeling is een technische discipline, en het onderwijs richt zich dus logischerwijs op de techniek - dat is het idee.
Eenzijdig
Helemaal onterecht is dat natuurlijk niet. Het valt moeilijk te ontkennen dat software wat te maken heeft met technology en engineering. Softwareontwikkelaars gebruiken immers techniek om bepaalde problemen op te lossen. (Voor science en mathematics valt ook een zaak te maken, maar die zijn wat mij betreft wat minder overduidelijk.)
Gormans punt is dan ook niet dat dit idee niet klopt. Het is eerder zo dat het een te eenzijdig beeld van softwareontwikkeling schetst.
Softwareontwikkeling is immers ook: met stakeholders praten, hun domein modelleren, rollen en verantwoordelijkheden toewijzen aan verschillende delen van de code, een team zover krijgen zich op de juiste dingen te focussen, tests en documentatie schrijven - onder andere. In haar woorden: software ontwikkelen is management + documentatie. Dat zijn allemaal zaken die buiten beeld vallen als je het vak louter als technische discipline opvat.
Nieuwe dingen leren
De notie dat softwareontwikkeling een vooral technische discipline is, heeft een direct verband met het tweede algemeen geaccepteerde idee dat Gorman onderscheidt: constante ontwikkeling karakteriseert softwareontwikkeling als discipline - en constant nieuwe dingen leren karakteriseert softwareontwikkelaars daarom als professionals.
De crux zit ’m in wat er wordt verstaan onder “nieuwe dingen” - en dat is: nieuwe technieken. Dag in dag uit worden softwareontwikkelaars gebombardeerd met een stroom aan nieuwe tools, talen en frameworks. Deze ontwikkelingen bijhouden is een nagenoeg onmogelijke taak geworden - wat ontwikkelaars overigens niet tegenhoudt om het te proberen.
Een softwareontwikkelaar groeit door nieuwe technieken te leren. De alomtegenwoordigheid van dat idee uit zich in de hoeveelheid van mijn collega’s die het leren van die technieken tot de kern van hun persoonlijk ontwikkelingsplan hebben gemaakt. Een aantal jaar geleden zag ik iedereen om mij heen zich op Angular storten, het jaar daarop wilden mijn collega’s massaal wat met Azure doen.
Oude dingen leren
De vraag die vaak wordt vergeten is: is een nieuwe techniek wat we nodig hebben? Loont het zich om om de zoveel jaar massaal over te stappen van server side rendering naar client side rendering en weer terug? En hoeveel zin heeft het om je tot big ball of mud verworden monoliet van de grond af aan opnieuw op te bouwen als een big ball of microservices?
Als softwareontwikkeling meer is dan een louter technische discipline, dan loont het zich misschien net zo goed - of misschien zelfs wel meer - om dingen te leren die niet nieuw zijn. Hoe je requirements opstelt, bijvoorbeeld, of hoe je een domein modelleert. Een gemiddelde ontwikkelaar heeft veel meer aan een goede teststrategie dan aan het leren van Blazor (hoewel ik niks tegen Blazor heb). - Maar daar zie ik mijn collega’s zich niet op storten.
Het idee dat softwareontwikkeling een technische discipline is, heeft hen blind gemaakt voor alle “oude”, niet-glimmende technieken die hen zouden kunnen helpen.
Problemen oplossen
Let op, ik wil niet zeggen dat het leren van nieuwe technieken onbelangrijk is. Integendeel, een goede ontwikkelaar is op de hoogte van de trends in zijn vakgebied.
Maar het aanwenden van die trends moet haar grond vinden in een niet-technische vaardigheid: het oplossen van businessproblemen. Een nieuwe techniek moet geïntegreerd worden in een bestaand systeem - daarvoor moet je verantwoordelijkheden kunnen scheiden. Een nieuwe techniek moet getest worden - daarvoor moet je gedrag kunnen documenteren.
En vooral: de nieuwe techniek moet beoordeeld worden op haar bruikbaarheid binnen de context van een bepaald probleem - en het aantal vaardigheden dat je daarvoor nodig hebt, valt niet op één hand te tellen.
Divers
Er zullen genoeg ontwikkelaars bestaan die zich zowel interesseren voor de technische als niet-technische kanten van softwareontwikkeling. Maar een eenzijdige focus op software als constant vernieuwende bètawetenschap trekt vooral mensen aan die zich interesseren voor het leren van nieuwe technieken.
Dat is waarom zoveel van je collega’s bètanerds zijn.
De softwareontwikkelpopulatie zou een stuk diverser worden als we zouden erkennen dat programmeren meer is dan algoritmen schrijven. Dat zou het onderwijs transformeren - en bovendien beter doen aansluiten op de praktijk. En het zou professionals stimuleren om zich te verdiepen in iets anders dan alleen de nieuwste technieken.
De softwareontwikkelpopulatie zou een gezellig gezelschap worden van alle soorten nerds: bèta, alfa, gamma - noem maar op! Maar het blijven nerds niettemin, want laten we eerlijk zijn: wie de hele dag met code bezig wil zijn, blijft toch een beetje ‘n aparte.