LEUNINGEN

De berekeningen

In de volgende vier maanden kwamen we elke twee weken bij elkaar en stap voor stap ontdekten we The Awesome World of Ruby et al. De cursus behandelde de taal Ruby, Ruby on Rails, Javascript en enkele populaire tools voor RoR-toepassingen zoals Devise, Pundit, Sidekiq of Carriewave.

Elke student had ook een mentor, die verantwoordelijk was voor het motiveren van studenten en het controleren van hun werk tussen de bijeenkomsten door.

Het aanvalsplan

Als docent kwam ik voorbereid met 3 jaar ervaring met Ruby on Rails, 10 jaar ervaring met programmeren in het algemeen en een aantal presentaties met onderwerpen en oefeningen om te doen.

Afgezien van een korte cursus Linux-beheer die ik eerder had gedaan, had ik geen ervaring met lesgeven. Wat de studenten betreft, wist ik alleen dat er tien van hen zouden zijn en dat ze een zeer verschillende achtergrond hadden - voor sommigen was het hun eerste kennismaking met programmeren, terwijl anderen C of Ruby op eigen houtje probeerden te leren voordat ze zich inschreven voor de cursus.

Ik besloot twee voornemens te maken - ik zal geduldig zijn en ik zal alles uitleggen als dat nodig is (geen "we hebben het er al over gehad"). Het eerste voornemen heeft de tand des tijds doorstaan, maar het tweede - overduidelijk - niet. Ik besloot om me niet speciaal voor te bereiden op de dingen die ik zou gaan onderwijzen - ik werk elke dag met Ruby/Rails en ik voel me behoorlijk zelfverzekerd in mijn vaardigheden op dat gebied. Ik heb hooguit de presentaties gelezen die ik had.

De uitdaging

Een van de eerste dingen die me meteen na de start van de cursus heel duidelijk werd - je kunt niet alles uitleggen. Het is een triest besef voor iemand als ik, die graag graaft en ontdekt hoe dingen werken, maar in de beperkte tijd van één bijeenkomst is er maar zoveel dat je kunt leren en dat studenten kunnen onthouden. Het blijkt dat je een goede Ruby programmeur kunt zijn zonder precies te weten hoe Arrays in het geheugen worden weergegeven of hoe Devise precies werkt.

De lessen vonden plaats op zaterdag en zondag van 9 tot 17 uur. Het is belangrijk om te beseffen dat lesgeven behoorlijk vermoeiend werk is - naast het uitleggen van de stof moet je ook altijd klaar staan om gerelateerde (of niet zo gerelateerde) vragen te beantwoorden en verschillende problemen van je leerlingen op te lossen.

Koffie is je vriend, maar het meest cruciale is het eerder genoemde geduld. Voor mensen die nog niet eerder hebben gecodeerd, moeten concepten die voor programmeurs vanzelfsprekend zijn - zoals lussen, types of zelfs variabelen - worden geleerd en het is geen instant proces. Als je al XX jaar programmeert, wiskunde makkelijk vindt en midden in de nacht alle bekende programmeerparadigma's kunt opnoemen, is het misschien moeilijk om in de huid te kruipen van iemand die niet weet aan welke kant van het gelijkheidsteken de naam van de variabele staat. Maar het is essentieel dat je het doet. Basisconcepten zoals variabelen, lussen of arrays worden zo natuurlijk dat het moeilijk te begrijpen is hoe iemand ze niet meteen kan begrijpen, maar ze zijn moeilijker dan ze lijken voor "ons programmeurs".

Een bijkomende moeilijkheid, vooral in het begin van de cursus, was het uitleggen van die concepten zodat ze goed begrepen werden. Naar mijn mening is het niet mogelijk om Rails te leren zonder Ruby te leren - hoewel ik weet dat sommigen zullen beweren dat dit niet het geval is. Het is waar dat Rails zijn eigen patronen heeft en dat veel dingen eerder onthouden dan geleerd kunnen worden in het begin. Ik denk echter dat om een goede RoR ontwikkelaar te worden, een matig begrip van Ruby, OOP of SQL een must is. Mensen leren programmeren is heel wat anders dan Rails onderwijzen - terwijl je bij Rails veel kunt verwachten dat gewoon wordt geaccepteerd of geloofd (niemand hoeft in het begin te weten hoe callbacks werken - alleen wat ze kunnen doen), moeten programmeerconcepten in meer detail worden uitgelegd.

De kracht inschakelen

Hoe doe je dat?

Geduldig.

Het lijkt waarschijnlijk alsof ik mezelf de hele tijd herhaal, maar ik kan niet genoeg benadrukken hoe belangrijk geduld is. Zelfs mijn meest gemotiveerde leerlingen staan erom bekend dat ze hier en daar een syntaxfout maken - het is onderdeel van het normale leerproces en er is voor een leraar niet echt iets anders te doen dan te laten zien wat de fout is en hoe je hem kunt oplossen. Na verloop van tijd zullen ze leren om ze zelf op te lossen, maar daar is veel meer voor nodig dan één of twee fouten.

Iets anders om op te merken is dat Ruby niet zo makkelijk is als het lijkt. Als je begon met het leren van Ruby met kennis van C/Java/Python, leek alles waarschijnlijk zo schoon en mooi en eenvoudig. Probeer er echter over na te denken en je zult het merken:

1. Wat is er met die haakjes? Moet ik ze gebruiken? Moet ik ze niet gebruiken?
2. Wat is dat zelf ding? Soms moet ik het gebruiken (bijv. attr_schrijver – zelf.variabele = ...), soms ook niet (attr_lezer – variabele) en soms kan ik het niet! (private def sommige_methode – zelf.sommige_methode geeft een fout)
3. Blokken. Ik durf te wedden dat zelfs sommige ervaren programmeurs (van verschillende talen) even meer dan verwacht nodig zouden hebben om te begrijpen #inject

Afgezien van het eenvoudigweg herstellen van de fouten, is er ook nog de kwestie van het overbrengen van jouw begrip van de dingen op je leerlingen. Om dit te doen, heb je veel flexibiliteit nodig. Sommige leerlingen waren tevreden met Array als gewoon een geordende lijst van elementen. Anderen hadden meer visuele analogie nodig, zoals een plank met genummerde plaatsen waar je dingen op kunt zetten. Ik merkte dat ik dezelfde dingen meerdere keren op verschillende manieren uitlegde - wat best een uitdagende oefening is!

Maar, zoals ik al eerder zei, je kunt niet alles uitleggen. Toen ik relaties in Rails uitlegde, was het meer een "zo doe je dat, en het staat je toe om dat en dat te doen. Je wilt dat, het is geweldig". Gelukkig vroeg niemand me hoe dit werkt - ik denk niet dat junior ontwikkelaars iets hoeven te weten over reflecties.

Situationele positionering

Door de opzet van onze cursus (bijeenkomsten om het weekend en lange pauzes) moesten we ervoor zorgen dat de periodes tussen die weekenden productief zijn voor onze studenten - zonder dat ze in die tijd oefenen zou de cursus helemaal niet werken.

Een aantal van mijn collega's stemden ermee in om mentor te zijn voor studenten in de cursus. De mentoren controleerden de oefeningen die tijdens de weekendbijeenkomsten werden toegewezen en hielpen bij problemen die zich voordeden tijdens het maken van de oefeningen. Studenten communiceerden met mentoren via Slack.

Ik was mentor voor twee van mijn studenten. Het was een heel andere vorm van lesgeven - en vol met zijn eigen valkuilen. Wat ik me iets te laat realiseerde, is dat een goede programmeur onafhankelijk moet zijn - hij moet op zijn minst proberen problemen zelf op te lossen voordat hij om hulp vraagt. En de hele tijd beschikbaar zijn op Slack nam niet alleen veel van mijn tijd in beslag, maar inspireerde ook niet tot een dergelijke onafhankelijkheid.

Begrijp me niet verkeerd - veel van de vragen die ik als mentor kreeg, waren geldig en het beantwoorden ervan was het uitbreiden van kennis over de leerlingen. Het is echter erg makkelijk om in de "docentenmodus" te gaan - en alle kwesties van de weekendbijeenkomsten opnieuw uit te leggen. Vanuit het perspectief van vandaag denk ik dat de rol van een mentor bestaat uit overzicht geven, nuttige links geven en vragen stellen die kunnen helpen bij het vinden van de oplossing. Af en toe uitleggen kan gebeuren, maar het zou niet de hoofdmoot moeten zijn.

Het gebruik van intelligentie

Elke student is anders. Een van de grootste problemen was om het tempo van de cursus aan te passen aan alle studenten. Door de verschillende achtergronden en het algemene gemak waarmee studenten nieuwe ideeën accepteren, is dit een bijna onmogelijke taak.

Ons tijdsbestek was 9 bijeenkomsten - maal 2 dagen maal 8 uur gaf ons 144 uur om van 0 tot Ruby-hero te komen. Het was van het grootste belang om de hele syllabus in deze tijd te doen - wat op zichzelf al een behoorlijk hoog tempo afdwong. De eerste drie bijeenkomsten gingen allemaal over Ruby - dan één bijeenkomst voor SQL, dan RoR en één bijeenkomst voor JS tussendoor.

Als docent moest ik altijd weten wie een deel van de lesstof min of meer begreep. Soms was het genoeg om te vragen of dit begrepen werd, soms deed ik kleine testjes. Ik vroeg bijvoorbeeld al mijn studenten om mij hun eigen definities van Ruby-begrippen te sturen, zoals klasse, zelf, methode, variabele enz. op Slack. Als iets bijzonder onduidelijk was, ging ik terug en probeerde ik het opnieuw uit te leggen.

Illusie en werkelijkheid

Samengevat was lesgeven nog moeilijker dan ik dacht. Het kan ook heel lonend zijn. Desalniettemin is het hard werken en de effecten ervan hangen niet alleen af van de leraar - de eigen inspanning van de leerling is nog belangrijker in hun leerproces. Dit maakt lesgeven heel anders dan programmeren, waar je meestal zelf alle successen en mislukkingen kunt bepalen. Het is belangrijk om dit verschil te onthouden.

Het dwingt je ook om na te denken over zaken waar je normaal niet over nadenkt - dingen uitleggen geeft je ook een beter begrip ervan. Op die manier kan lesgeven je ook een betere programmeur maken.