UNDERVISNINGSRAMPER

Beräkningarna

Under de kommande fyra månaderna träffades vi varannan vecka och steg för steg upptäckte vi The Awesome World of Ruby et al. Kursen omfattade språket Ruby, Ruby on Rails, Javascript och några populära verktyg för RoR-applikationer som Devise, Pundit, Sidekiq eller Carriewave.

Varje student hade också en mentor, som ansvarade för att motivera studenterna och kontrollera deras arbete mellan mötena.

Planen för angrepp

Som lärare kom jag förberedd med 3 års erfarenhet av Ruby on Rails, 10 års erfarenhet av programmering i allmänhet och några presentationer med frågeställningar och övningar att göra.

Förutom en kort kurs i Linux-hantering som jag hade gått tidigare, hade jag ingen erfarenhet av att undervisa. När det gäller studenterna visste jag bara att de skulle vara tio stycken och att de kom från väldigt olika bakgrunder - för några av dem var det första gången de programmerade, medan andra försökte lära sig C eller Ruby på egen hand innan de började på kursen.

Jag bestämde mig för att avge två löften - jag skulle ha tålamod och jag skulle förklara allt om det behövdes (inget "det har vi redan gjort"). Det första beslutet har hållit, men det andra - helt uppenbart - gjorde det inte. Jag bestämde mig för att inte göra några särskilda förberedelser när det gällde det jag skulle lära ut - jag arbetar med Ruby/Rails varje dag och känner mig ganska säker på mina kunskaper inom det området. På sin höjd läste jag de presentationer jag hade.

Utmaningen

En av de första sakerna som stod helt klart för mig strax efter kursstart var att man inte kan förklara allt. Det är en mycket tråkig insikt för någon som jag, som gillar att gräva i och upptäcka hur saker och ting fungerar, men under den begränsade tiden för ett möte finns det bara så mycket du kan lära ut och som kan komma ihåg av studenterna. Det visar sig att du kan vara en mycket anständig Ruby-programmerare utan att veta exakt hur Arrays faktiskt representeras i minnet eller hur exakt Devise fungerar.

Lektionerna ägde rum på lördagar och söndagar mellan kl. 9.00 och 17.00. Det är viktigt att inse att undervisning är ett ganska ansträngande arbete - förutom att förklara materialet måste du också alltid vara redo att svara på relaterade (eller inte så relaterade) frågor och lösa olika problem som dina studenter har.

Kaffe är din vän, men det mest avgörande är det tidigare nämnda tålamodet. För personer som inte har kodat tidigare måste begrepp som är uppenbara för programmerare - som loopar, typer eller till och med variabler - läras in och det är inte en omedelbar process. Om du har programmerat i XX år, tycker att matte är lätt och kan räkna upp alla kända programmeringsparadigm mitt i natten, kan det vara svårt att sätta sig in i hur det känns för en person som inte riktigt vet på vilken sida av likhetstecknet variabelns namn står. Men det är viktigt att du gör det. Grundläggande begrepp som variabler, loopar eller arrayer blir så naturliga att det är svårt att förstå hur någon inte kan förstå dem direkt, men de är svårare än de verkar för "oss programmerare".

En ytterligare svårighet, särskilt i början av kursen, var att förklara dessa begrepp så att de är väl förstådda. Enligt min mening är det inte möjligt att lära sig Rails utan att lära sig Ruby - även om jag vet att vissa skulle hävda att så inte är fallet. Det är sant att Rails har sina egna mönster och att många saker kan komma ihåg snarare än att lära sig i början. Jag tror dock att en måttlig förståelse för Ruby, OOP eller SQL är ett måste för att bli en medveten RoR-utvecklare. Att lära folk att programmera är något helt annat än att lära ut Rails - medan det med Rails finns mycket du kan förvänta dig att bara accepteras eller tros (ingen behöver veta hur callbacks fungerar i början - bara vad de kan göra), bör programmeringskoncept förklaras mer detaljerat.

Engagera styrkan

Så hur gör man det?

Tålmodigt.

Det verkar förmodligen som om jag upprepar mig själv hela tiden, men jag kan inte nog betona hur viktigt tålamod är. Även mina mest motiverade studenter gjorde ett syntaxfel här och där - det är en del av den normala inlärningsprocessen och det finns egentligen inget annat att göra för en lärare än att visa vad felet är och hur man åtgärdar det. Med tiden kommer de att lära sig att rätta till dem på egen hand, men det krävs mycket mer än ett eller två fel.

En annan sak att notera är att Ruby inte är så lätt som det verkar. Om du började lära dig Ruby med kunskap om C/Java/Python, verkade allt förmodligen så rent och fint och enkelt. Försök att tänka på det dock, och du kommer att märka det:

1. Vad är det med parenteserna? Ska jag använda dem? Borde jag inte göra det?
2. Vad är det? själv sak? Ibland måste jag använda det (t.ex. attr_skrivare – self.variable = ...), ibland gör jag det inte (attr_läsare – variabel) och ibland kan jag inte! (privat def någon_metod – self.some_method kommer att ge ett felmeddelande)
3. Block. Jag slår vad om att även några erfarna programmerare (av olika språk) skulle behöva en stund mer än förväntat för att förstå #inject

Förutom att helt enkelt rätta till felen är det också en fråga om att faktiskt överföra din förståelse av saker och ting till dina studenter. För att göra detta behöver du en hel del flexibilitet. Vissa elever nöjde sig med att Array bara var en ordnad lista med element. Andra behövde en mer visuell analogi, som en hylla med numrerade platser där man kan lägga saker. Jag kom på mig själv med att förklara samma saker flera gånger på olika sätt - vilket är en ganska utmanande övning!

Men som jag sa tidigare, man kan inte förklara allt. När jag förklarade relationer i Rails var det mer av ett "så här gör man, och det gör att man kan göra det och det. Om du vill ha det så är det fantastiskt". Lyckligtvis var det ingen som frågade mig hur det här fungerar - jag tror inte att juniora utvecklare behöver känna till reflektioner.

Positionering i olika situationer

På grund av kursens upplägg (möten varannan helg och långa uppehåll) var vi tvungna att se till att perioderna mellan helgerna är produktiva för våra studenter - utan att de övar under den tiden skulle kursen inte fungera alls.

Några av mina kollegor gick med på att vara mentorer för studenterna i kursen. Mentorernas uppgift var att verifiera övningar som tilldelats under helgmötena och hjälpa till med problem som uppstod när de slutförde dem. Studenterna kommunicerade med mentorerna via Slack.

Jag var mentor för två av mina studenter. Det var en helt annan form av undervisning - och full av sina egna fallgropar. En sak som jag insåg lite för sent är att en bra programmerare måste vara självständig - de bör åtminstone försöka lösa problem på egen hand innan de ber om hjälp. Och att vara tillgänglig på Slack hela tiden tog inte bara mycket av min tid, utan inspirerade inte heller till sådan självständighet.

Missförstå mig inte - många av de frågor jag fick som mentor var berättigade och att besvara dem var att öka elevernas kunskaper. Det är dock väldigt lätt att hamna i "lärarläge" och återigen förklara alla frågor från helgens möten. Ur dagens perspektiv tycker jag att en mentors roll är att ge en överblick, tillhandahålla användbara länkar och ställa frågor som kan hjälpa till att hitta lösningen. Ibland kan det hända att man förklarar, men det bör inte vara den största delen av tiden.

Användning av underrättelsetjänster

Alla studenter är olika. En av de största svårigheterna var att anpassa tempot i kursen så att det passade alla studenterna bäst. På grund av de olika bakgrunderna och den allmänna nivån av lätthet att acceptera nya idéer mellan studenterna är det nästan en omöjlig uppgift.

Vår tidsram var 9 möten - gånger 2 dagar gånger 8 timmar gav oss 144 timmar att gå från 0 till Ruby-hero. Det var av största vikt att göra hela kursplanen på den här tiden - vilket i sig tvingade fram en ganska snabb takt. De tre första mötena handlade om Ruby - sedan ett möte för SQL, sedan RoR och ett möte för JS däremellan.

Som lärare var jag alltid tvungen att veta vem som mer eller mindre förstår en del av det material jag presenterade. Ibland räckte det med att fråga om detta är förstått, ibland gjorde jag små tester. Jag bad till exempel alla mina studenter att skicka mig sina egna definitioner av Ruby-begrepp, som klass, själv, metod, variabel etc, på Slack. Om någon fråga var särskilt oklar gick jag tillbaka och försökte förklara den igen.

Illusion och verklighet

Sammanfattningsvis var läraryrket en ännu svårare uppgift än jag hade trott. Det kan också vara mycket givande. Ändå är det hårt arbete och effekterna av det beror inte bara på läraren - studentens egen ansträngning är ännu viktigare för deras lärande. Detta gör att undervisning skiljer sig mycket från programmering, där du vanligtvis kan äga alla framgångar och misslyckanden. Det är viktigt att komma ihåg denna skillnad.

Det tvingar dig också att tänka på frågor som du vanligtvis inte tänker på - att förklara saker ger dig också en bättre förståelse för dem. På så sätt kan undervisning också göra dig till en bättre programmerare.