Development

Software-ontwikkeling
Iedere dag programmeren

Iedere dag programmeren

Word je ook echt beter in programmeren als je het elke dag doet, vraagt Felienne Hermans zich af.

28 oktober 2020

De ophef du jour op programmeertwitter was deze week een tweet van de verder onbekende Hays Stanford, die trots deelde dat hij dit jaar al 15.000 programmeerbijdrages had geleverd op GitHub. “Waarom programmeren jullie niet zo?”, schreef Standford bij zijn screenshot.

Er zijn allerlei interessante dingen op te merken aan de houding dat 'een echte programmeur' iedere dag moet programmeren. Zo past het bij het beeld dat je alleen een goede programmeur bent als je zo gek bent op programmeren dat je het echt iedere dag wilt doen, en dus ook geen andere hobby’s of interesses hebt. Immers, als je je zaterdag doorbrengt op het hockeyveld, in de voetbalkantine of bij de handwerkclub, dan heb je geen tijd om iedere dag te programmeren. Ten slotte wezen veel programmeurs Stanford op Twitter op het feit dat veel mensen zorgtaken hebben en dus om die reden ook geen tijd hebben om iedere dag te programmeren. Dat zijn natuurlijk veel vaker vrouwen dan mannen, dus het verheerlijken van dit soort gedrag als 'goed' is nou niet bepaald inclusief.

Op zich zijn dit allemaal invalshoeken die belangrijk genoeg zijn om een hele column aan te wijden, maar er is een onderstroom die ik nóg interessanter vind. Aan de basis van 'programmeer jij wel iedere dag?' ligt het idee dat je van meer programmeren een betere programmeur wordt. Is dat wel zo? Zoals vaste lezers weten, liep ik een jaartje geleden mijn eerste marathon, en behalve eeuwige 'bragging rights' houd je aan zo’n marathon ook een perspectief over aan hoe je eigenlijk goed wordt in iets.

Als je een marathon gaat lopen, is het niet bepaald een goed idee om iedere dag een marathon te lopen. Sterker nog, dat is een goede manier om snel een blessure op te lopen en er waarschijnlijk nog sneller genoeg van te krijgen. Je wisselt juist je trainingen af; heel snel maar kort, lange duurlopen op een lager tempo en ook krachttraining om je been- en buikspieren te trainen. Het idee dat verschillende soorten training in combinatie een goede manier zijn om iets onder de knie te krijgen, geldt niet alleen voor sport, maar bijvoorbeeld ook voor het leren bespelen van een muziekinstrument. Van alleen maar iedere dag wat deuntjes spelen, word je niet beter. Uit onderzoek naar topviolisten bleek dat de echte toppers en de middelmatige spelers ongeveer evenveel tijd besteden aan oefenen, maar de toppers deden dat met 'deliberate practice'; ze kozen stukken muziek die ze nog moeilijk vonden, en bleven juist die oefenen tot het beter ging.

Wil je beter worden in programmeren, dan ligt het voor de hand dat je ook veel beter gericht kan oefenen. Tien keer de while-lus in Python, twintig keer de for-lus en nog even een if'je om het af te maken. Daar heeft niemand op GitHub iets aan, maar jij wel.

Magazine AG Connect

Dit artikel is ook gepubliceerd in het magazine van AG Connect (oktobernummer, 2020). Wil je alle artikelen uit dit nummer lezen, klik dan hier voor de inhoudsopgave.

Reactie toevoegen
6
Reacties
Mathijs 01 november 2020 16:11

Mijn laatste posting door een foutje als Anoniem geplaatst, deze is dus door mij geplaatst (Mathijs Groen).

note aan forum beheerder: het zou wenselijk zijn als je de geplaatst bericht kunt aanpassen. Dank u.

Anoniem 01 november 2020 16:10

@EH Hoogendijk:
dat is dus juist wat je dient te voorkomen, door je bekwamen/trainen op het ontwerpen van software in een programmeertaal onafhankelijke aanpak. De taal is slechts een implementatievorm (zie mijn eerdere post). Of je nu een programma schrijft in taal X of Y, het ontwerp behoort (min of meer) hetzelfde te zijn. Door de stap van ontwerp(PSD) naar code te automatiseren voorkom je dat je bij moet blijven met alle nieuwe features in de diverse talen... deze worden (als het goed is) meegepakt in de (geautomatiseerde) translatie van ontwerpschema naar code regels....

E.H. Hoogendijk 29 oktober 2020 13:39

En natuurlijk je zelf blijven ontwikkelen en je de nieuwe features van de zoveelste release van je favoriete programmeertaal eigen willen maken. Je loopt daarbij wel het gevaar dat anderen je programmeerwerk niet meer begrijpen omdat ze lui jarenlang dezelfde "verouderde" code-constructen blijven schrijven.

Hans Bezemer 29 oktober 2020 13:00

Leren programmeren kun je alleen op basis van het Pippi Langkous principe "Ik heb het nog nooit gedaan, dus ik denk dat ik het wel kan".

Boekjes lezen is leuk om een feel te krijgen voor de syntax en mogelijkheden, maar helpen verder erg weinig. Voorbeelden helpen om de toepassing van bepaalde elementen te illustreren (zie: de geweldige Borland manuals voor hun C compilers), maar ze hebben pas zin als je het volgende gaat doen.

Een programma schrijven. Niet eentje voor een if, while, until loopje (die hoogover constructies zijn bijna overal hetzelfde, behalve dan in talen als ColorForth of Factor, die exotische dingen als recursie en quotations toepassen), maar eentje, die een echt probleem oplost. Anders gezegd, iets wat je nodig hebt of wilt gebruiken.

Na weken van lezen ging ik met mijn eerste C programma aan de slag. Eigenlijk triviaal, maar het kostte me 12 uur. Assembly hetzelfde verhaal - duik erin, kijk wat je wilt doen en zoek de constructies erbij. Tien tegen een dat je juist tegen de vragen aanloopt, die je jezelf nooit zou stellen als je alleen een while loopje oefent.

Echt hele goeie programmeurs willen gewoon weten wat er onder de motorkap zit. Een goeie C-programmeur kan voorspellen welke assembly code er ongeveer uit de compiler rolt. Supergoeie programmeurs, kunnen dat zelfs voor -O2 of -O3 of GNU specifieke extensies. Voor Java bytecode geldt dat overigens hetzelfde.

De viool metafoor loopt dus stuk. Wellicht dat er violisten zijn die hun bloedeigen Stradivarius zo goed kennen, dat ze van specifieke technieken gebruik kunnen maken of een speciale intonatie in hun spel te kunnen leggen. Wellicht - maar ik heb het nooit gehoord.

Ik heb leren programmeren door een half jaar lang dagen te maken van 16 uur, waar ik niet of nauwelijks wegkwam van het toetsenbord.

En dan zijn er NOG een paar componenten, die van een programmeur een goede programmeur maken. Ontwerp en architectuur is zo'n dingetje. De context van de klant kennen is zo'n dingetje. Kennis van wiskunde en kennis van de enorme stapel algoritmen is ook zo'n dingetje (dank je Donald).

Dus als je echt een goeie programmeur wilt worden is een heleboel toewijding noodzakelijk. Uiteraard kun je er tevreden mee zijn om de Duinenmars uit te kunnen lopen of een halve marathon in 4 uur flat af te leggen - maar dat maakt je geen maestro.

JGM van der Zanden 28 oktober 2020 20:55

@Mathijs: Helemaal mee eens.
En vergeet ook niet om de principes van structured programming, data hiding en nog zo wat aan te leren. Dat betekent dat iedereen het eerst met Java of Pascal moet leren; C is het eerste jaar sowieso streng verboden. Want anders wordt dat programmeren nog steeds prutswerk.
Helaas is de praktijk bij 90% van de organisaties, dat de SW gewoon amateuristisch geklungel is. Cowboys die kopiëren en krassen. Het lijkt er veel op dat de wereld wat dit betreft sinds de jaren '60 nog helemaal niks geleerd heeft…..

Mathijs 28 oktober 2020 12:53

Waarom blijf je hangen in het "programmeren", in een taal (of dat nou Python, C, Java, of whatever is)? Beter is het beschouwen van programmeren als een softwareontwerpmethode, programmeertaal onafhankelijk.
Ik doel hierbij op het feitelijke ontwerpen, dat vooraf hoort te gaan aan het "code inkloppen": (het opstellen van, beheren en onderhouden van): PSD diagrammen of Nasi-Shneiderman diagrammen (meer info: https://en.wikipedia.org/wiki/Nassi%E2%80%93Shneiderman_diagram)

Zorg dat je goed bent/wordt/blijft in deze manier van ontwerpen. Snap je dit concept en deze methode dan zal je zien dat een specifieke programmeertaal slechts een implementatiemethode is van het ontwerp. (er zijn zelfs al tooltjes op de markt die het PSD-ontwerp geautomatiseerd in code (Java, C, Python) zetten (dan hoef je niet eens meer te code-kloppen).

Dagelijks code kloppen is dan ook niet nodig. In plaats daarvan: wordt/blijf een kei in de Nasi-Shneiderman ontwerpen.