LÆRESKINNER

Beregningene

I løpet av de neste fire månedene møttes vi annenhver uke, og steg for steg oppdaget vi The Awesome World of Ruby et al. Kurset dekket språket Ruby, Ruby on Rails, Javascript og noen populære verktøy for RoR-applikasjoner som Devise, Pundit, Sidekiq eller Carriewave.

Hver student hadde også en mentor, som hadde ansvar for å motivere studentene og kontrollere arbeidet deres mellom møtene.

Angrepsplanen

Som lærer kom jeg forberedt med 3 års erfaring med Ruby on Rails, 10 års erfaring med programmering generelt og noen presentasjoner med problemstillinger og øvelser som skulle gjøres.

Bortsett fra et kort kurs i Linux-administrasjon som jeg hadde tatt tidligere, hadde jeg ingen erfaring med å undervise. Når det gjelder studentene, visste jeg bare at det kom til å være ti stykker, og at de hadde svært ulik bakgrunn - for noen av dem var det første gang de prøvde seg på programmering, mens andre hadde forsøkt å lære seg C eller Ruby på egen hånd før de begynte på kurset.

Jeg bestemte meg for å ta to forsetter - jeg skal være tålmodig, og jeg skal forklare alt hvis det trengs (ikke noe "vi har allerede snakket om det"). Den første beslutningen har stått seg over tid, men den andre - helt åpenbart - ikke. Jeg bestemte meg for å ikke gjøre noen spesielle forberedelser når det gjaldt det jeg skulle undervise i - jeg jobber med Ruby/Rails hver dag, og jeg føler meg ganske trygg på ferdighetene mine på det området. Jeg leste på det meste presentasjonene jeg hadde.

Utfordringen

Noe av det første som ble helt klart for meg rett etter kursstart, var at man ikke kan forklare alt. Det er en trist erkjennelse for en som meg, som liker å gå i dybden og finne ut hvordan ting fungerer, men det er begrenset hvor mye man kan lære bort i løpet av ett møte, og hvor mye som kan huskes av studentene. Det viser seg at du kan være en veldig god Ruby-programmerer uten å vite nøyaktig hvordan Arrays faktisk er representert i minnet eller hvordan Devise fungerer.

Undervisningen foregikk på lørdager og søndager fra kl. 09.00 til 17.00. Det er viktig å være klar over at det å undervise er ganske slitsomt - i tillegg til å forklare stoffet må du også alltid være klar til å svare på relaterte (eller ikke så relaterte) spørsmål og løse ulike problemer som studentene dine har.

Kaffe er din venn, men det mest avgjørende er den nevnte tålmodigheten. For folk som ikke har kodet før, må konsepter som er åpenbare for programmerere - som løkker, typer eller til og med variabler - læres, og det er ikke en umiddelbar prosess. Hvis du har programmert i XX år, synes matematikk er enkelt og kan ramse opp alle kjente programmeringsparadigmer midt på natten, kan det være vanskelig å sette seg inn i situasjonen til en person som ikke er helt sikker på hvilken side av likhetstegnet navnet på variabelen skal stå på. Men det er viktig at du gjør det. Grunnleggende begreper som variabler, løkker og matriser blir så naturlige at det er vanskelig å forstå hvordan noen ikke kan forstå dem med en gang, men de er vanskeligere enn de ser ut til for "oss programmerere".

En ekstra utfordring, spesielt i begynnelsen av kurset, var å forklare disse konseptene slik at de ble godt forstått. Etter min mening er det ikke mulig å lære Rails uten å lære Ruby - selv om jeg vet at noen vil hevde at det ikke er tilfelle. Det er sant at Rails har sine egne mønstre, og mange ting kan huskes i stedet for å læres i begynnelsen. Men jeg tror at for å bli en bevisst Rails-utvikler, er en moderat forståelse av Ruby, OOP eller SQL et must. Å lære folk å programmere er noe helt annet enn å lære bort Rails - mens med Rails er det mye du kan forvente å bare bli akseptert eller trodd (ingen trenger å vite hvordan callbacks fungerer i begynnelsen - bare hva de kan gjøre), bør programmeringskonsepter forklares mer detaljert.

Å engasjere kraften

Så hvordan gjør man det?

Tålmodig.

Det virker sikkert som om jeg gjentar meg selv hele tiden, men jeg kan ikke få understreket nok hvor viktig tålmodighet er. Selv de mest motiverte elevene mine har gjort en syntaksfeil her og der - det er en del av den normale læringsprosessen, og det er egentlig ikke noe annet å gjøre for en lærer enn å vise hva feilen består i og hvordan den kan rettes opp. Med tiden vil de lære seg å rette dem på egen hånd, men det krever langt mer enn én eller to feil.

En annen ting å merke seg er at Ruby ikke er så enkelt som det ser ut til. Hvis du begynte å lære Ruby med kunnskap om C/Java/Python, virket alt sannsynligvis så rent og fint og enkelt. Men prøv å tenke over det, og du vil legge merke til det:

1. Hva er det med parentesene? Bør jeg bruke dem? Burde jeg ikke?
2. Hva er det seg selv ting? Noen ganger må jeg bruke den (f.eks. attr_writer – self.variable = ...), noen ganger gjør jeg det ikke (attr_reader – variabel) og noen ganger kan jeg ikke! (private def some_method – self.some_method vil gi en feilmelding)
3. Blokker. Jeg vedder på at selv noen erfarne programmerere (av forskjellige språk) vil trenge et øyeblikk mer enn forventet for å forstå #inject

I tillegg til å rette opp feilene, er det et problem å faktisk overføre din forståelse av ting til studentene dine. For å gjøre dette trenger du mye fleksibilitet. Noen elever nøyde seg med at Array bare var en ordnet liste over elementer. Andre trengte en mer visuell analogi, som en hylle med nummererte plasser man kan legge ting på. Jeg tok meg selv i å forklare de samme tingene flere ganger på forskjellige måter - noe som er en ganske utfordrende øvelse!

Men som jeg sa før, man kan ikke forklare alt. Da jeg forklarte relasjoner i Rails, var det mer et "det er slik du gjør det, og det lar deg gjøre det og det. Hvis du vil ha det, er det kjempebra". Heldigvis var det ingen som spurte meg om hvordan dette fungerer - jeg tror ikke juniorutviklere trenger å vite noe om refleksjoner.

Situasjonsbestemt posisjonering

På grunn av kursets format (møter annenhver helg og lange pauser) måtte vi sørge for at periodene mellom disse helgene var produktive for studentene våre - uten at de øvde i den tiden, ville ikke kurset fungert i det hele tatt.

Noen av kollegene mine sa ja til å være mentorer for studentene på kurset. Mentorenes oppgave var å verifisere øvelsene som ble tildelt under helgemøtene, og hjelpe til med problemer som oppstod under gjennomføringen. Studentene kommuniserte med mentorene via Slack.

Jeg var mentor for to av studentene mine. Det var en helt annen form for undervisning - og full av sine egne fallgruver. En ting jeg innså litt for sent, er at en god programmerer må være selvstendig - de bør i det minste prøve å løse problemer på egen hånd før de ber om hjelp. Og det å være tilgjengelig på Slack hele tiden tok ikke bare mye av tiden min, men inspirerte heller ikke til slik selvstendighet.

Misforstå meg rett - mange av spørsmålene jeg fikk som mentor, var gode, og det å svare på dem var å utvide kunnskapen om elevene. Det er imidlertid veldig lett å gå inn i "lærermodus" - og forklare alle spørsmålene fra helgemøtene på nytt. Fra dagens perspektiv mener jeg at en mentors rolle er å skaffe oversikt, gi nyttige lenker og stille noen spørsmål som kan bidra til å finne løsningen. Det kan hende at man forklarer av og til, men det bør ikke være hovedtyngden av det.

Bruk av etterretning

Alle studentene er forskjellige. En av de største utfordringene var å tilpasse tempoet i kurset slik at det passet best mulig for alle studentene. På grunn av studentenes ulike bakgrunn og generelle evne til å akseptere nye ideer er det nesten en umulig oppgave.

Tidsrammen vår var 9 møter - ganger 2 dager ganger 8 timer ga oss 144 timer til å gå fra 0 til Ruby-hero. Det var viktig å gjennomføre hele pensumet på denne tiden - noe som i seg selv tvang frem et ganske høyt tempo. De tre første møtene handlet bare om Ruby - deretter ett møte om SQL, så RoR og ett møte om JS.

Som lærer måtte jeg alltid vite hvem som mer eller mindre forstod en del av stoffet jeg presenterte. Noen ganger var det nok å spørre om dette er forstått, andre ganger gjorde jeg små tester. For eksempel ba jeg alle studentene mine om å sende meg sine egne definisjoner av Ruby-begreper, som klasse, seg selv, metode, variabel osv. på Slack. Hvis noe var spesielt uklart, gikk jeg tilbake og prøvde å forklare det på nytt.

Illusjon og virkelighet

For å oppsummere: Å undervise var en enda vanskeligere oppgave enn jeg hadde trodd. Det kan også være veldig givende. Ikke desto mindre er det hardt arbeid, og effekten av det avhenger ikke av læreren alene - studentens egen innsats er enda viktigere for læringen. Dette gjør undervisning svært annerledes enn programmering, der du vanligvis kan eie alle suksesser og fiaskoer. Det er viktig å huske denne forskjellen.

Det tvinger deg også til å tenke på ting du vanligvis ikke tenker på - når du forklarer ting, får du også en bedre forståelse av dem. På den måten kan undervisning også gjøre deg til en bedre programmerer.