Ik heb naast wiskunde vooral programmeren en 3D gegeven, en er is één patroon dat bij bijna elke beginner terugkomt.
Ze hebben tutorials gevolgd. Uren ervan. Alles werkte. En dan gaan ze zelf iets maken en er gebeurt niets.
Dat is geen gebrek aan talent. Het is een voorspelbaar gevolg van hoe die tutorials werken.
Wat een tutorial je wel en niet leert
In een tutorial krijg je een probleem dat al opgelost is. Iemand vertelt je stap voor stap wat je moet typen, en aan het eind werkt het.
Wat je daarbij oefent, is lezen en overschrijven. Wat je niet oefent, is het enige dat programmeren eigenlijk is: een probleem opdelen in stappen die een computer kan uitvoeren.
Dat verschil blijft onzichtbaar zolang er iemand voorzegt. Het wordt pijnlijk zichtbaar op het moment dat je voor een leeg bestand zit.
En dan is de conclusie meestal verkeerd. Mensen denken dat ze te weinig weten en gaan nog een tutorial doen. Wat ze missen is geen kennis maar oefening in het denken zelf.
De oefening die het verschil maakt
Bouw iets kleins dat niet in een tutorial staat.
Niet een to-do-app die je uit een filmpje kent, maar iets waarvan jij de eisen bepaalt. Een script dat je bestanden hernoemt. Een programmaatje dat je punten bijhoudt en een gemiddelde uitrekent. Een spelletje boter-kaas-en-eieren.
Het maakt niet uit wat het is. Het maakt uit dat niemand je vertelt hoe.
Je gaat vastlopen, en dat is niet het bewijs dat het te moeilijk is: dat is de oefening. De vaardigheid die je hier opbouwt is precies degene die je op een examen of in een job nodig hebt, want daar staat ook geen tutorial bij.
Opdelen is de hele vaardigheid
Als je vastloopt, is de vraag bijna altijd: wat is de kleinste stap die ik nu wel kan?
Neem het boter-kaas-en-eieren-voorbeeld. "Maak een spel" is te groot om aan te beginnen. Maar: teken een leeg bord op het scherm. Dat kan je. Daarna: sla in een lijst op wat er in elk vakje staat. Ook dat kan je. Daarna: laat een speler een vakje kiezen. En zo verder.
Elke stap is klein genoeg om op te lossen, en samen vormen ze het programma.
Dat opdelen is niet iets dat je erbij doet. Het is het werk. Wie dat kan, kan bijna alles bouwen met een beperkte kennis van een taal. Wie het niet kan, blijft steken ondanks veel kennis.
Foutmeldingen zijn informatie, geen straf
Beginners doen bij een foutmelding meestal één van twee dingen: ze plakken hem in een zoekmachine, of ze proberen willekeurig iets anders.
Lees hem eerst. Er staan bijna altijd drie dingen in: wat voor soort fout het is, in welk bestand, en op welke regel.
Die drie samen lossen het merendeel van je fouten op zonder dat je iets hoeft op te zoeken. En belangrijker: elke keer dat je zelf een foutmelding ontcijfert, wordt de volgende sneller. Wie ze consequent laat oplossen door iemand anders, blijft ze even lang eng vinden.
Nuttige tussenstap als je echt vastzit: laat je programma tussentijds iets afdrukken. Wat zit er op dit punt in die variabele? Klopt dat met wat je verwachtte? Dat is de simpelste vorm van debuggen en ze werkt verrassend vaak.
Waar AI je helpt en waar het je tegenhoudt
Ik bouw zelf AI-functies in dit platform, dus neem mijn belang als gegeven. Ik denk nog steeds dat de meeste beginners het gebruiken op de manier die hen het meest kost.
Een taalmodel geeft je een werkende oplossing. Dat is precies het probleem: je krijgt het antwoord zonder de stap die je zou moeten oefenen, namelijk het opdelen.
Wat wel werkt: gebruik het om iets uit te leggen dat je niet begrijpt, of om je eigen code na te kijken nadat je hem geschreven hebt. Wat niet werkt: het de opdracht laten maken en jezelf wijsmaken dat je het begrepen hebt omdat je de code kan volgen.
Code volgen is makkelijk. Code bedenken is het vak.
Dat is trouwens niet uniek voor programmeren. Ik had ooit een leerling die vier dagen voor zijn herkansing bij me kwam omdat zijn UV-unwrap in Blender niet werkte. Hij had het al aan een AI gevraagd en een net, zelfverzekerd antwoord gekregen over waar hij zijn naden moest leggen. Dat antwoord was op zich niet fout. Het kon alleen niet zien dat het model eronder het probleem was: verborgen ngons, omgekeerde faces, dubbele vertices. Geen enkel advies over naden ging dat oplossen.
AI beantwoordt de vraag die je stelt. Bij een beginner is de gestelde vraag zelden de juiste vraag.
Programmeren en algoritmisch denken zijn twee vakken
Dit onderscheid kost in het hoger onderwijs elk jaar eerstejaars hun eerste zit, en het overvalt precies de studenten die dachten dat ze een voorsprong hadden.
Programmeren is een oplossing opschrijven in een taal. Algoritmisch denken is bepalen wélke oplossing goed is: hoe lang duurt dit als de invoer tien keer zo groot wordt, en bestaat er een aanpak die dat vermijdt.
Iemand die al jaren hobbyprojecten bouwt, kan uitstekend het eerste en nooit het tweede geoefend hebben. En algoritmen en datastructuren test vooral het tweede.
Als je een informaticarichting overweegt, is dat de moeite om te weten. Niet om je af te schrikken, wel om te snappen waarom "ik kan al programmeren" geen garantie is.
De vier dingen die in elke taal hetzelfde zijn
Beginners raken vaak in de war van de vraag welke taal ze moeten kiezen, terwijl de eerste taal vooral een vehikel is. Wat je erin leert, gaat grotendeels mee naar de volgende.
Er zijn vier bouwstenen en zowat elk programma bestaat eruit.
Variabelen. Iets bewaren onder een naam, zodat je het later kan gebruiken of aanpassen.
Voorwaarden. Als dit waar is, doe dan dat. Dit is waar je programma keuzes maakt.
Herhaling. Doe dit zolang, of doe dit voor elk element in een lijst. Bijna alles wat een computer nuttig maakt, zit hierin: dingen die je zelf niet duizend keer wil doen.
Functies. Een stuk werk een naam geven zodat je het kan hergebruiken en zodat je programma leesbaar blijft.
Als je die vier echt begrijpt, in de zin dat je ze kan gebruiken zonder voorbeeld, kan je in principe elk probleem aan dat je aankan. De rest, de bibliotheken en de syntax en de gereedschappen, is opzoekwerk.
Dat is ook de reden dat "welke taal" minder belangrijk is dan het lijkt. Wie deze vier in Python leert, herkent ze binnen een week in Java, en omgekeerd.
Hoe je het volhoudt
Twee praktische dingen die meer bepalen dan aanleg.
Werk in korte sessies, regelmatig. Vier keer een uur per week zet meer vast dan één zaterdag van vier uur, om dezelfde reden als bij talen: je hebt herhaling over tijd nodig.
Hou iets af. Een half project dat je laat liggen, leert je minder dan een klein project dat af is, want de laatste twintig procent is waar je de vervelende problemen tegenkomt en dus het meest leert.
En verwacht dat het traag voelt in het begin. De eerste maanden bouw je vooral het vermogen op om een probleem in stukken te zien, en dat is onzichtbare vooruitgang tot het opeens klikt.
Als je vastzit in een opleiding
Zit programmeren in je studie en loopt het vast, dan is de eerste vraag welke van de twee het is: het schrijven zelf, of het bedenken van de aanpak.
Bij het eerste helpt oefenen op volume. Bij het tweede helpt oefenen op opdelen, en dat is een ander soort werk waarbij je juist minder code schrijft en meer op papier zet.
Onze docenten geven bijles in programmeren en in algoritmen en datastructuren voor het hoger onderwijs. Zit je in het eerste jaar en loopt er meer vast dan alleen dit vak, dan staat de bredere aanpak in je eerste jaar aan de unief.
Gaat het om een kind dat wil beginnen, dan liggen de volgorde en het startpunt anders, en dat staat in programmeren voor kinderen.