UNDERVISNINGSSKINNER

Beregningerne

I løbet af de næste fire måneder mødtes vi hver anden uge, og skridt for skridt opdagede vi The Awesome World of Ruby et al. Kurset dækkede Ruby-sproget, Ruby on Rails, Javascript og nogle populære værktøjer til RoR-applikationer som Devise, Pundit, Sidekiq eller Carriewave.

Hver elev havde også en mentor, som var ansvarlig for at motivere eleverne og kontrollere deres arbejde mellem møderne.

Planen for angrebet

Som underviser kom jeg forberedt med 3 års erfaring med Ruby on Rails, 10 års erfaring med programmering generelt og nogle præsentationer med spørgsmål og øvelser, der skulle laves.

Bortset fra et kort kursus i Linux-administration, som jeg havde taget før, havde jeg ingen erfaring med at undervise. Hvad angår de studerende, vidste jeg kun, at der ville være ti af dem, og at de kommer fra meget forskellige baggrunde - for nogle af dem er det deres første møde med programmering, mens andre forsøgte at lære C eller Ruby på egen hånd, før de tilmeldte sig kurset.

Jeg besluttede mig for at tage to beslutninger - jeg vil være tålmodig, og jeg vil forklare alt, hvis det er nødvendigt (ikke noget med "vi har allerede dækket det"). Den første beslutning har stået sin prøve, men det gjorde den anden - helt åbenlyst - ikke. Jeg besluttede mig for ikke at forberede mig specielt på de ting, jeg skulle undervise i - jeg arbejder med Ruby/Rails hver dag, og jeg føler mig ret sikker på mine færdigheder på det område. Jeg læste højst de præsentationer, jeg havde.

Udfordringen

En af de første ting, der stod helt klart for mig lige efter kursets start, var, at man ikke kan forklare alt. Det er en meget trist erkendelse for en som mig, der godt kan lide at gå i dybden og finde ud af, hvordan tingene fungerer, men det er begrænset, hvor meget man kan nå at lære på et enkelt møde, og hvor meget de studerende kan huske. Det viser sig, at man kan være en meget god Ruby-programmør uden at vide præcis, hvordan Arrays egentlig er repræsenteret i hukommelsen, eller hvordan Devise helt præcist fungerer.

Undervisningen foregik på lørdage og søndage fra kl. 9 til 17. Det er vigtigt at forstå, at undervisning er et ret udmattende arbejde - ud over at forklare stoffet skal man også altid være klar til at besvare relaterede (eller ikke så relaterede) spørgsmål og løse forskellige problemer, som de studerende har.

Kaffe er din ven, men det mest afgørende er den førnævnte tålmodighed. For folk, der ikke har kodet før, skal begreber, der er indlysende for programmører - som løkker, typer eller endda variabler - læres, og det er ikke en øjeblikkelig proces. Hvis du har programmeret i XX år, synes, at matematik er nemt, og kan opremse alle kendte programmeringsparadigmer midt om natten, kan det være svært at sætte sig i en persons sted, som ikke er helt sikker på, hvilken side af lighedstegnet navnet på variablen skal stå på. Men det er vigtigt, at du gør det. Grundlæggende begreber som variabler, loops eller arrays bliver så naturlige, at det er svært at forstå, hvordan nogen ikke kan forstå dem med det samme, men de er sværere, end de ser ud for "os programmører".

En yderligere vanskelighed, især i begyndelsen af kurset, var at forklare disse koncepter, så de blev forstået. Efter min mening er det ikke muligt at lære Rails uden at lære Ruby - selvom jeg ved, at nogle vil hævde, at det ikke er tilfældet. Det er rigtigt, at Rails har sine egne mønstre, og mange ting kan huskes i stedet for at blive lært i begyndelsen. Men jeg tror, at en moderat forståelse af Ruby, OOP eller SQL er et must for at blive en bevidst Rails-udvikler. At lære folk at programmere er noget helt andet end at undervise i Rails - mens der med Rails er meget, man kan forvente bare bliver accepteret eller troet på (ingen behøver at vide, hvordan callbacks fungerer i begyndelsen - kun hvad de kan gøre), skal programmeringskoncepter forklares mere detaljeret.

Inddragelse af kraften

Så hvordan gør man det?

Tålmodigt.

Det virker sikkert, som om jeg gentager mig selv hele tiden, men jeg kan ikke understrege nok, hvor vigtig tålmodighed er. Selv mine mest motiverede elever laver en syntaksfejl her og der - det er en del af den normale læringsproces, og der er ikke rigtig noget at gøre for en lærer andet end at vise, hvad fejlen er, og hvordan man retter den. Med tiden vil de lære at rette dem selv, men det kræver langt mere end en eller to fejl.

En anden ting at bemærke er, at Ruby ikke er så let, som det ser ud til. Hvis du begyndte at lære Ruby med kendskab til C/Java/Python, virkede alt sikkert så rent og pænt og enkelt. Men prøv at tænke over det, og du vil opdage det:

1. Hvad er der med parenteserne? Skal jeg bruge dem? Skal jeg ikke?
2. Hvad er det? sig selv ting? Nogle gange er jeg nødt til at bruge den (f.eks. attr_writer – self.variable = ...), nogle gange gør jeg det ikke (attr_læser – variabel) og nogle gange kan jeg ikke! (privat def some_method – self.some_method vil give en fejl)
3. Blokke. Jeg vil vædde på, at selv nogle erfarne programmører (af forskellige sprog) ville have brug for et øjeblik mere end forventet for at forstå #inject

Ud over blot at rette fejlene er der spørgsmålet om rent faktisk at overføre din forståelse af tingene til dine studerende. For at gøre dette har du brug for en masse fleksibilitet. Nogle elever var tilfredse med, at Array bare var en ordnet liste over elementer. Andre havde brug for en mere visuel analogi, som en hylde med nummererede steder, hvor man kan lægge ting. Jeg tog mig selv i at forklare de samme ting flere gange på forskellige måder - hvilket er en ret udfordrende øvelse!

Men som jeg sagde før, kan man ikke forklare alt. Da jeg forklarede relationer i Rails, var det mere et "sådan gør du, og det giver dig mulighed for at gøre det og det. Hvis du vil have det, er det fantastisk". Heldigvis var der ingen, der spurgte mig, hvordan det fungerer - jeg tror ikke, at juniorudviklere behøver at vide noget om refleksioner.

Situationsbestemt positionering

På grund af kursets format (møder hver anden weekend og lange pauser) var vi nødt til at sikre, at perioderne mellem disse weekender var produktive for vores studerende - uden at de øvede sig i den tid, ville kurset slet ikke fungere.

Nogle af mine kolleger indvilligede i at være mentorer for de studerende på kurset. Mentorernes arbejde bestod i at verificere øvelser, der blev tildelt under weekendmøderne, og hjælpe med problemer, der opstod under udførelsen af dem. De studerende kommunikerede med mentorerne via Slack.

Jeg var mentor for to af mine studerende. Det var en markant anderledes form for undervisning - og fuld af sine egne faldgruber. En ting, jeg indså lidt for sent, er, at en god programmør skal være selvstændig - de bør i det mindste forsøge at løse problemer på egen hånd, før de beder om hjælp. Og at være tilgængelig på Slack hele tiden tog ikke kun meget af min tid, men inspirerede heller ikke til en sådan uafhængighed.

Misforstå mig ikke - mange af de spørgsmål, jeg blev stillet som mentor, var gyldige, og at besvare dem var at udbrede kendskabet til de studerende. Det er dog meget let at gå i "lærer-mode" - og forklare alle spørgsmålene fra weekendmøderne igen. I dag mener jeg, at en mentors rolle er at skabe overblik, give nyttige links og stille nogle spørgsmål, der kan hjælpe med at finde en løsning. Indimellem skal man måske forklare, men det bør ikke udgøre størstedelen af det.

Brugen af efterretninger

Alle studerende er forskellige. En af de største vanskeligheder var at justere tempoet på kurset, så det passede bedst muligt til alle de studerende. På grund af de studerendes forskellige baggrunde og generelle lethed ved at acceptere nye ideer er det næsten en umulig opgave.

Vores tidsramme var 9 møder - gange 2 dage gange 8 timer gav os 144 timer til at gå fra 0 til Ruby-hero. Det var altafgørende at nå hele pensum på den tid - hvilket i sig selv betød et ret højt tempo. De første tre møder handlede kun om Ruby - derefter et møde om SQL, så RoR og et møde om JS i mellemtiden.

Som lærer var jeg altid nødt til at vide, hvem der mere eller mindre forstod en del af det materiale, jeg præsenterede. Nogle gange var det nok at spørge, om det var forstået, andre gange lavede jeg små tests. For eksempel bad jeg alle mine studerende om at sende mig deres egne definitioner af Ruby-begreber, som for eksempel klasse, sig selv, metode, variabel osv. på Slack. Hvis noget var særligt uklart, ville jeg gå tilbage og prøve at forklare det igen.

Illusion og virkelighed

For at opsummere var det at undervise en endnu sværere opgave, end jeg troede. Det kan også være meget givende. Ikke desto mindre er det hårdt arbejde, og effekten af det afhænger ikke af læreren alene - de studerendes egen indsats er endnu vigtigere for deres læring. Det gør undervisning meget anderledes end programmering, hvor man normalt kan eje alle succeser og fiaskoer. Det er vigtigt at huske denne forskel.

Det tvinger dig også til at tænke over ting, du normalt ikke tænker over - at forklare ting giver dig også en bedre forståelse af dem. På den måde kan undervisning også gøre dig til en bedre programmør.