De mensheid heeft in zijn lange geschiedenis voortdurend vaardigheden ontwikkeld en gereedschappen uitgevonden om het uitvoeren van die vaardigheden te vervolmaken. Met een zaagbank maak je rechtere snedes dan de meest ervaren timmerman dat ooit zou lukken met een handzaag. Maar de zaagbank vervangt de timmerman niet. Daarentegen hebben innovaties in concurrerende technieken wel hele beroepsgroepen obsoleet gemaakt. Het eeuwenoude vak van zetten is niet de nek omgedraaid door een superieure zetrobot, maar door tekstverwerkers en laserprinters. Overigens zegt de moeilijkheid om een bepaald ambacht te leren weinig over de waarschijnlijkheid dat het ook economisch interessant is om te automatiseren: er zijn nog genoeg vacatures voor menselijke bordenwassers.

Als zelfs meesterschap in het ultieme strategiespel go niet langer het exclusieve domein is van het menselijk brein mogen traditionele kenniswerkers zich af gaan vragen met welke kennis en vaardigheden ze in de toekomst dan wel hun baan veilig kunnen stellen. We denken bij kennis vooral aan informatie, aan gegevens die je uit het hoofd kunt leren, overdragen, opzoeken en die uiteindelijk door een computer verwerkt kunnen worden. Bij vaardigheden denken we toch eerder aan iets uniek menselijks wat je je slechts met tijd en inspanning eigen kan maken, zoals het maken van een vertaling waarbij alle nuances van de brontaal behouden blijven. Als we dit duidelijke en plausibele onderscheid tussen kennis en vaardigheden aannemen dan zou een kenniswerker in de letterlijke betekenis van het woord juist gemakkelijker weggeautomatiseerd kunnen worden dan een vakman, en niet lastiger.

Software-ontwikkelaars hoeven zich voorlopig nog geen zorgen te maken, maar dat wil niet zeggen dat het belang van kennis in de zin van te leren brokjes data niet ingrijpend verandert. Statische code analyse kan nu al honderden best practices en gangbare codeerfouten detecteren. Een ervaren programmeur kan dat ook, maar onmogelijk met dezelfde grondigheid. Toch kunnen deze tools voor statische analyse je niet vertellen of je code correct is, zoals een automatische test ook alleen maar op de aanwezigheid op bugs kan duiden, maar nooit de afwezigheid kan bewijzen. Kennis van ontwerppatronen geeft je bijvoorbeeld nog niet het inzicht om ze ook op de juiste manier te gebruiken.

Ik heb al eerder geschreven over het niet te onderschatten belang van soft skills voor ontwikkelaars. Toch heb je ook harde kennis nodig om je werk te kunnen doen. Daarbij zijn een grondige en actuele kennis van een of twee (maar geen vijf) moderne progammeertalen en algemene ontwerpbeginselen essentieel. Ernaast heb je in elk softwareproject nog drie soorten kennis nodig. Die kennis is minder basaal, omdat hij lastiger te overdragen is tussen projecten, minder duurzaam en meestal nutteloos buiten het project. Het is overigens nog steeds belangrijke kennis om je werk te kunnen doen.

Ten eerste is er de kennis van standaard tools, libraries en frameworks. Deze heb je in veel concurrerende smaken en vaak overlappen ze elkaar functioneel ook nog aanzienlijk. Sommige van deze tools bieden een belangrijke ondersteunende taak die je eenmalig moet inrichten en daarna weinig onderhoud zou moeten vergen, zoals build automatisering en source control. Dit is daarom ook niet het soort kennis waar iedereen binnen het team idealiter expert in zou moeten zijn. Ten tweede kun je de meeste lacunes in dit soort kennis heel efficiënt opzoeken. Niemand ploegt door de volledige documentatie van Spring of Hibernate om zich functies eigen te maken die je misschien nooit gaat gebruiken. Wil je x doen met tool y in een omgeving van z? Zo’n vraag is specifiek genoeg voor Google. Ten derde maken grote upgrades van bijvoorbeeld web frameworks – maar ook bijvoorbeeld van EJB2 naar EJB3 – vaak een radicale breuk met het verleden. Met zo’n sterke concurrentie heb je dan altijd winnaars en verliezers. Wie per se een guru wil worden in elk hip nieuw framework gaat onvermijdelijk ten onder aan vermoeidheid of frustratie.

Domeinkennis staat los van softwarekennis. Het omvat althans dat wat je moet weten over de buitenwereld waarin de software zal draaien om de juiste aannames te maken, en geen code te schrijven die weliswaar brandschoon is, maar volledig verkeerd. Toen ik voor de Rotterdamse haven ontwikkelde moest ik leren over de adminstratieve procedures wanneer een zeeschip de haven aandoet. Voor een andere klant – een zeer grote kwekerij – moest ik leren over stekjes en zaden en welke planten wanneer in het seizoen zijn. Samengevat: je kunt geen boekhoudsoftware maken zonder de beginselen van het boekhouden te kennen en het niet  tenminste een beetje leuk te vinden. Daarom is zoveel open source software ook specialistische tooling voor andere developers. Je kunt binnen het domein blijven dat je fascineert en waarmee je innig vertrouwd bent.

Als grote bedrijven nog grotere bedragen uittrekken voor maatwerksoftware mag je hopen dat hun bedrijf voldoende uniek is om de ontwikkeling van die software te rechtvardigen. Het betekent ook dat de domeinkennis die je daar opdoet waarschijnlijk niet naadloos aansluit aan wat je bij de concurrent moet weten, en daarin verschilt domeinkennis van programmerkennis. Hibernate 4 is hibernate 4 waar je ook heengaat, maar nautische regels zijn niet hetzelfde in Rotterdam, Portsmouth of Shanghai. En daarmee zijn we bij het derde type aangeland.

Er is namelijk ook nog kennis die geen domeinkennis is en waarvoor je tevergeefs zult zoeken op stackoverflow. Ik heb het over de irritante, ongedocumenteerde eigenaardigheden die je je eigen moet maken voordat je met de code in een groot project aan de slag kunt. Deze eigenaardigheden komen altijd door niet-standaard oplossingen. Je leert begrijpen waarom iets is zoals het is, terwijl je je realiseert dat het niet zo zou moeten zijn. Het systeem is ontwikkelaar-onvriendelijk – en dat belooft zelden veel goeds voor de eindgebruiker. De beste omschrijving van usability is wanneer dingen werken zoals je verwacht dat ze moeten werken en uitleg overbodig is. Hoe minder gebruiksvriendelijk een systeem is, des te meer kennis heb je nodig. Het is een teken aan de wand wanneer het je een dag kost om een machine voor een nieuwe ontwikkelaar in te richten.

Kennis over Spring en Docker is bepaald niet in steen gebeiteld, maar het is wel prima bruikbaar tussen projecten. Datzelfde geldt niet door domeinkennis, maar die gaat dan weer langer mee en kan op een bepaalde manier zelfs leuk en verrijkend zijn buiten het werk, ook als het niet van praktisch nut is. Eigenaardigheden over maatwerksoftware heeft geen enkele van deze voordelen. Het is nuttig (essentieel zelfs) om je werk te kunnen doen, en nutteloos daarbuiten. Het is een te vermijden moeite en een onnodige barrière voor nieuwe teamleden om snel aan de slag te kunnen. Daarnaast slokt het tijd op die je ook kon besteden om een betere programmeur te worden of het zakelijk domein te leren. Dit soort kennis zouden we helemaal niet moeten willen leren.