Het recht om niet (teveel) na te hoeven denken

In drie eerdere blogs op DZone maakte ik een ludieke vergelijking tussen typen programmeurs en de regisseurs Stanley Kubrick (de onverbeterlijke perfectionist), Woody Allen (de gepassioneerde liefhebber) en stripfiguur Guust Flater (de hyperactieve knutselaar). Het ging mij hier om neigingen aan te duiden. Stereotyperingen werken leuk in een tv-serie als The IT Crowd of Nedry in de eerste Jurassic Park film. In het echt zit het alleen maar in de weg en valt er een stuk minder te lachen. De sociaal onaangepaste, geniale workaholic met overgewicht is een cliché. Maar ook al is de blanke, hetero, dertigjarige man het gemiddelde, dat betekent nog niet dat die groep het recht heeft de cultuur te bepalen. Bij mijn laatste bezoek aan JFall viel me op dat we qua diversiteit in gender en etniciteit nog flinke stappen moeten maken in Nederland.

Illustratie van Sandra de Haan

Wat wel hardnekkig overeind blijft is een onrealistisch vertrouwen in de individuele IT-er als allesweter en alleskunner. Dat leeft vooral binnen de blogwereld. Er is een soort artikel dat ik graag automatisch uitgefilterd zag: “de X kenmerken van een senior ontwikkelaar” en alle variaties daarop. Het zelfvertrouwen spetter ervan af in deze stukjes, geschreven door zelfbenoemde seniors, die dus wel weten hoe de vork in de steel zit. Zelden breken ze een lans voor bescheidenheid. Zelden begrijpen ze dat ervaring het besef oplevert dat er nog zoveel is dat je niet weet en nooit kunt weten, dat je niet alles kan, en zeker niet tegelijkertijd. Dat het individu een beperkte mentale en fysieke slagkracht heeft, en dat dat er na je veertigste niet beter op wordt. Zelden gaat het over de steeds grotere cognitieve last om bij te willen blijven met al die nieuwe technieken. 

Laat je toch niet gek maken door die vacatures met onrealistische wensenlijstjes vermomd als harde vereisten. Leeftijdgenoot Uwe Friedrichsen schreef een lange reeks over leaving the rat race. De software-, consultancy- en certificeringsindustrieën moeten ons met regelmaat een nieuw product, dienst of training aansmeren. Daar leven ze van. Echte innovaties op softwaregebied worden steeds zeldzamer, en daarom overdrijven we het belang van nieuwe ontwikkelingen.  Houd liever een helicopteroverzicht en probeer niet meteen overal tot in detail van op de hoogte te blijven als early adopter. Je hebt nog tijd zat wanneer het uiteindelijk gemeengoed is geworden en langzaam zijn weg vindt in alle legacysystemen – want dat laatste gaat nog steeds met een slakkengang. Technieken komen en gaan, en te vaak wedden op het verkeerde paard is verkwisting van je beperkte energie.

Van mijn tandarts verwacht ik niet dat zij ’s avonds voor de lol nog gratis bruggen en kronen zet voor vrienden. Idem voor boekhouders en tegelzetters. Ook voor IT-ers hoeven nieuwe programmeertalen, tools en gadgets geen roeping te zijn van 24/7 omdat er simpelweg niets fascinerender is in deze wereld. Onzin. Ik ben geen one trick pony, en ik raad iedereen aan er een andere serieuze liefhebberij bij te nemen. Kies voor na je contractuele uren een paar hobby’s die je niet achter toetsenbord en scherm doorbrengt. Die geven maar slapeloosheid, RSI en overgewicht. 

Ik schreef er al over in mijn vorige post: T-shaping is bittere noodzaak om alle complexiteit het hoofd te bieden. De moderne full-stack developer kan niet overal specialist in zijn, waar dat in 2001 met moeite nog wel kon. Kies het specialisme dat jou boeit en verdiep je pas in de details van de materie wanneer je die kennis nodig hebt, wat ik just in time leren noemde.

Tegelijk ontkom je er niet aan om vaker vragen te stellen binnen je team als de kennis verdeeld is. Dat is en blijft een spanningsveld. Onderbrekingen halen mensen uit hun flow, ik weet er alles van. Niet voor niks kan een kluizenaar/soloprogrammeur enorme voortgang maken als niemand hem/haar lastigvalt, maar dat is geen duurzame oplossing. Dergelijke einzelgängers laten meestal een erfenis aan ongedocumenteerde ondoorgrondelijke spaghetti achter.Je kunt echter wel veel onnodige vragen voorkomen. Het beroemde boek Don’t Make Me Think van Steve Krug ging weliswaar over gebruikersinterfaces, maar voor clean code geldt het net zo hard. Zie het als jouw taak om te voorkomen dat anderen naar je toe komen voor vragen. De grote jongens weten dat een dure usability specialist zich dubbel en dwars terugbetaalt als dat duizend minder telefoontjes naar de helpdesk oplevert, los van de grotere tevredenheid van de bestaande klanten. Wees dus zo begrijpelijk mogelijk, als je niet onnodig voor helpdesk wil spelen.