Gepubliceerd in SDN Magazine nr 145, dec 2022

Deze column gaat over de waarde van het programmeren als ambacht. Ook voor managers is het belangrijk daar voeling mee te blijven houden. Maar ik begin met een muziekvoorbeeld. Wijlen Steve Jobs was geen programmeur of ontwerper maar zag zich graag als de dirigent die het beste uit zijn orkest haalde. Of perste, als je zijn biografie leest. Als Apple het New York Philharmonic was, dan had Jobs wel wat van sterdirigent Leonard Bernstein, net zo berucht om zijn temperament.

Uitvinder en uitvoerder waren van oudsher dezelfde persoon. Wat componisten als Mozart en Chopin bedachten konden ze zelf ook virtuoos uitvoeren. Maar om hun orkestwerken voor vijftig of meer muzikanten in goede banen te leiden was een nieuwe functie nodig: die van dirigent, tegenwoordig een volwaardige masterstudie. Dirigenten bespelen ook wel een instrument, maar meestal niet op hetzelfde topniveau als de muzikanten die zij muzikaal leiden. Qua vakmanschap zijn de vereisten voor beide beroepen even hoog, maar maatschappelijk waarderen we ze wel degelijk anders. Wie leiding geeft of de grote lijnen uitzet staat hoger op de ladder, met overeenkomstig salaris.

Terug naar de software, want in onze branch is het niet anders. Hiërarchisch gezien zijn de programmeurs de muzikanten, is de dirigent de development lead en de enterprise architect de grote componist. Maar tussen de rollen bestaat veel minder onderscheid tussen uitvinder en uitvoerder dan je zou denken. Programmeren is niet het volgen van een recept, zoals brood bakken. De uitdagingen liggen weliswaar op meer gedetailleerd niveau (nl. de broncode) dan de grote lijnen waar de architect mee worstelt, maar vergen net zoveel creativiteit. Waarom vinden veel bedrijven het echter normaal dat een developer minder code schrijft naarmate haar ervaring groeit? De progressie van senior/lead developer naar architectuur verraadt een mening dat code schrijven op zeker moment te min voor je is. Grote onzin, en wel om drie redenen.

Mensen die de grote lijnen uitzetten voor grote systemen hebben een streepje voor als ze ook in detail begrijpen wat anderen voor ze bouwen. Ze zouden op elk moment moeten kunnen bijspringen – al is het wel belangrijk dat ze die neiging onderdrukken, want niemand houdt van micromanagers. De naam Elon Musk dringt zich hier op.

Ten tweede kun je ook na twintig jaar steeds een beetje beter worden in programmeren. Daarbij verouderen talen en trends sneller dan je fysieke lichaam. Wie beweert dat hij alles inmiddels wel weet is waarschijnlijk een one-trick pony. Niet zo verstandig voor je inzetbaarheid, en saai bovendien. De noodzaak om bij te blijven houdt mij juist gemotiveerd.

In kunst en wetenschap brengt jeugdig talent en geldingsdrang vaak vroeg succes. Daarom vindt Mark Zuckerberg jonge mensen gewoon slimmer. Misschien, maar het tomeloos enthousiasme en hoog IQ van de jonge honden levert ook onbegrijpelijke staaltjes op van pocherige ‘kijk mij eens’ code. Mijn derde reden om te blijven coderen is dat ervaren krachten bescheiden zijn en bewust van hun beperkte hersenpan. Ze hebben de pest aan slimme truukjes en ze weten meteen welke beroemde programmeur ik hier zojuist citeerde. 

Edsger W. Dijkstra The Humble Programmer (1972) https://tinyurl.com/3wfp3akp