Programmeren

Ik zou eens wat kunnen gaan mijmeren over mijn programmeurscarrière. "Old programmer fart yelling at the Cloud" zeg maar.

In het kader van "mijn wapenfeiten" lag ik gisteravond in bed na te denken over Tao, een mainframe-programma filosofie en praktijk die we met ons team van COBOL ontwikkelaars eind vorige eeuw hadden bedacht net toen het zo'n beetje niet meer hoefde, en of het leuk zou zijn dat eens na te bouwen in Python.

Dat TAO-verhaal heb ik ergens anders wat gedetailleerder beschreven, voor het verhaal hier is het niet zo belangrijk, behalve dan om te laten zien we met meer bezig waren dan alleen maar applicatieprogramma's schrijven en te zorgen dat ze blijven werken.

Ik heb een oneerlijk voordeel (of nadeel) ten opzichte van veel (ex-)collega's: ik programmeer ook als hobby. In de tijd dat ik begon was dit veel normaler, in elk geval in het team waar ik destijds deel van uitmaakte, hoewel er ook toen genoeg makkers waren die naast hun beroep ook nog een leven hadden.

Een paar dagen later - weer in bed - bedacht ik dat ik mijn onvrede met hoe "het vak" en de manier waarop mensen het beoefenen wil proberen te verwoorden. Ik merkte de laatste jaren dat ik "blij zou zijn als ik van SAP af was" en nu ik alleen nog maar met Python werk wordt het des te duidelijker dat het vooral de dingen om het programmeren heen zijn die me dwarszitten.

Wat ik op het werk wel zag was dat in toenemende mate mensen aan het werk gezet werden zonder gedegen opleiding en dat ze zo snel mogelijk productief moesten zien te worden. Toen ik op mijn laatste afdeling begon kon ik dat makkelijk met twintig jaar ervaring en een hoop interesse in het vak, maar stel je voor dat je met niks begint in zo'n situatie...

Ik zie net zoiets langskomen als op Python Discourse of python-list en andere IT communities, aan de ene kant posts van mensen die een snelle oplossing willen zonder te kijken wat ze aan het doen zijn, en aan de andere kant discussies over tooling die het mensen in staat moet stellen snel iets werkends op te zetten zonder er over na te hoeven denken hoe je dat eigenlijk doet.

Voor mijn eigen tools heb ik een werkwijze gevonden die voor mij werkt maar niet zo standaard is - als er al zoiets als standaard zou moeten bestaan - en hoe meer ik lees over de tooling die er ontwikkeld wordt om wel volgens standaards te kunnen werken hoe minder zin ik daar in krijg, omdat het me het gevoel geeft dat het gemaakt wordt voor mensen die er niet over na willen hoeven denken. Wat vanuit een zeker opzicht begrijpelijk is omdat je je wilt focussen op wat je applicatie doet en niet hoe je hem aan de praat krijgt en/of houdt in een veranderende wereld, maar wat misschien ook wel onzin is omdat je daar nou eenmaal mee te maken hebt - als een nieuwe release van een component die ik gebruik of de software omgeving waarin ik werk vereist dat ik dingen anders moet doen dan heb ik daarmee te dealen.

Natuurlijk, het is vervelend en je zou je liever uitsluitend richten op het verbeteren van je tool maar ik denk dat "weten wat er aan de hand is en dat je nu even wat anders moet regelen zodat je je daarna weer kunt wijden aan waar je eigenlijk wilt doen" je een betere programmeur maakt en het steeds makkelijker maakt om even dat uitstapje te doen omdat je weet waar je mee bezig bent in plaats van alleen maar gefrustreerd omdat je niet verder kunt met wat je eigenlijk wilt doen - of "dan maar dit" uit te proberen in de hoop dat dat je probleem oplost, wat ik on het verleden ook veel collega's heb zien doen. Ik noem dat "wild om je heen slaan in de hoop dat je iets raakt".