OPETUSKISKOT

Laskelmat

Seuraavien neljän kuukauden aikana tapasimme kahden viikon välein, ja askel askeleelta löysimme Rubyn ym. mahtavan maailman. Kurssilla käsiteltiin Rubyn kieltä, Ruby on Rails, Javascript ja joitakin suosittuja RoR-sovellusten työkaluja, kuten Devise, Pundit, Sidekiq tai Carriewave.

Jokaisella opiskelijalla oli myös mentori, jonka tehtävänä oli motivoida opiskelijoita ja tarkistaa heidän työnsä kokousten välillä.

Hyökkäyssuunnitelma

Opettajana olin valmistautunut 3 vuoden kokemuksella Ruby on Rails:stä, 10 vuoden kokemuksella ohjelmoinnista yleensä ja muutamilla esityksillä, joissa esiteltiin kysymyksiä ja harjoituksia.

Minulla ei ollut mitään kokemusta opettamisesta, lukuun ottamatta lyhyttä Linux-hallintakurssia, jonka olin käynyt aiemmin. Opiskelijoista tiesin vain, että heitä oli kymmenen ja että he olivat hyvin erilaisista lähtökohdista - joillekin heistä tämä oli ensimmäinen kerta ohjelmoinnin parissa, kun taas toiset yrittivät opetella C:tä tai Rubya omin päin ennen kurssille ilmoittautumista.

Päätin tehdä kaksi lupausta: aion olla kärsivällinen ja selittää kaiken tarvittaessa (ei "me käsiteltiin jo kaikki"). Ensimmäinen päätös on kestänyt ajan hammasta, mutta toinen - aivan ilmeisesti - ei. Päätin olla valmistautumatta erityisesti niihin asioihin, joita aioin opettaa - työskentelen Ruby/Railsin parissa joka päivä ja tunnen olevani melko varma taidoistani tällä alalla. Korkeintaan luin esityksiä, joita minulla oli.

Haaste

Yksi ensimmäisistä asioista, jotka tulivat minulle täysin selväksi heti kurssin alettua - kaikkea ei voi selittää. Se on hyvin surullinen oivallus kaltaiselleni henkilölle, joka haluaa syventyä ja selvittää, miten asiat toimivat, mutta yhden tapaamisen rajallisessa ajassa voi opettaa vain rajallisen määrän asioita, jotka oppilaat voivat muistaa. Kävi ilmi, että voit olla erittäin hyvä Ruby-ohjelmoija tietämättä tarkalleen, miten Arrays todella esitetään muistissa tai miten Devise toimii.

Oppitunteja pidettiin lauantaisin ja sunnuntaisin klo 9-17. On tärkeää ymmärtää, että opettaminen on melko uuvuttavaa työtä - materiaalin selittämisen lisäksi on oltava aina valmis vastaamaan aiheeseen liittyviin (tai ei niinkään aiheeseen liittyviin) kysymyksiin ja ratkaisemaan erilaisia ongelmia, joita oppilailla on.

Kahvi on ystäväsi, mutta tärkeintä on edellä mainittu kärsivällisyys. Ihmisille, jotka eivät ole aiemmin koodanneet, on opeteltava käsitteitä, jotka ovat ohjelmoijille itsestään selviä - kuten silmukoita, tyyppejä tai jopa muuttujia - eikä se tapahdu hetkessä. Jos olet ohjelmoinut XX vuotta, pidät matematiikkaa helppona ja osaat luetella kaikki tunnetut ohjelmointiparadigmat keskellä yötä, voi olla vaikea asettua sellaisen henkilön asemaan, joka ei ole aivan varma, kummalle puolelle yhtäsuuruusmerkkiä muuttujan nimi kuuluu. On kuitenkin elintärkeää, että teet sen. Peruskäsitteet, kuten muuttujat, silmukat tai matriisit, tulevat niin luonnollisiksi, että on vaikea käsittää, miten joku ei voi ymmärtää niitä heti, mutta ne ovat vaikeampia kuin miltä ne näyttävät "meille ohjelmoijille".

Lisävaikeutena, erityisesti kurssin alussa, oli näiden käsitteiden selittäminen niin, että ne ymmärretään hyvin. Mielestäni ei ole mahdollista oppia Railsia oppimatta Rubya - vaikka tiedänkin, että jotkut väittävät, että näin ei ole. On totta, että Railsissa on omat mallinsa ja paljon asioita voi ennemmin muistaa kuin oppia alussa. Olen kuitenkin sitä mieltä, että ollakseen tietoinen RoR-kehittäjä, kohtuullinen ymmärrys Rubysta, OOP:sta tai SQL:stä on välttämätöntä. Ohjelmoinnin opettaminen on aivan eri asia kuin Railsin opettaminen - kun Railsin kanssa voi odottaa, että paljon asioita vain hyväksytään tai uskotaan (kenenkään ei tarvitse alussa tietää, miten callbackit toimivat - vain mitä niillä voi tehdä), ohjelmoinnin käsitteet pitäisi selittää tarkemmin.

Voiman käyttäminen

Miten se tehdään?

Kärsivällisesti.

Tuntuu varmaan siltä, että toistan itseäni koko ajan, mutta en voi tarpeeksi korostaa, miten tärkeää kärsivällisyys on. Jopa kaikkein motivoituneimpien oppilaideni tiedetään tekevän syntaksivirheitä silloin tällöin - se on osa normaalia oppimisprosessia, eikä opettajalle ole oikeastaan muuta tehtävissä kuin näyttää, mikä virhe on ja miten se korjataan. Ajan myötä he oppivat korjaamaan ne itse, mutta siihen tarvitaan paljon enemmän kuin yksi tai kaksi virhettä.

Toinen huomioitava asia on se, että Ruby ei ole niin helppoa kuin miltä se näyttää. Jos aloitit Rubyn opettelun C/Java/Python:n tuntemuksella, kaikki näytti luultavasti niin puhtaalta, mukavalta ja yksinkertaiselta. Yritä kuitenkin ajatella asiaa, niin huomaat sen:

1. Miksi suluissa? Pitäisikö minun käyttää niitä? Eikö pitäisi?
2. Mikä tuo on? itse juttu? Joskus minun on käytettävä sitä (esim. attr_writer – self.variable = ...), joskus en (attr_reader – muuttuja) ja joskus en voi! (private def some_method – self.some_method heittää virheen)
3. Lohkot. Lyön vetoa, että jopa jotkut kokeneet ohjelmoijat (eri kielillä) tarvitsisivat hetken enemmän kuin odotetaan ymmärtääkseen seuraavat asiat. #inject

Virheiden korjaamisen ohella on myös kysymys siitä, miten siirrät ymmärryksesi asioista oppilaillesi. Tätä varten tarvitset paljon joustavuutta. Jotkut oppilaat tyytyivät siihen, että Array oli vain järjestetty luettelo elementeistä. Toiset tarvitsivat enemmän visuaalista analogiaa, kuten hylly, jossa on numeroituja paikkoja, joihin voi laittaa asioita. Huomasin selittäväni samoja asioita useita kertoja eri tavoin - mikä on varsin haastava harjoitus!

Mutta kuten sanoin aiemmin, kaikkea ei voi selittää. Kun selitin relaatioita Railsissa, se oli enemmänkin "näin se tehdään, ja sen avulla voi tehdä sitä ja tätä. Jos haluat tuon, se on mahtavaa". Onneksi kukaan ei kysynyt minulta, miten tämä toimii - en usko, että juniorikehittäjien tarvitsee tietää heijastuksista.

Tilannekohtainen paikannus

Kurssimme muodon vuoksi (kokoukset joka toinen viikonloppu ja pitkät tauot) meidän oli varmistettava, että näiden viikonloppujen väliset ajanjaksot ovat tuottavia opiskelijoillemme - ilman, että he harjoittelevat tuona aikana, kurssi ei toimisi lainkaan.

Jotkut työtoverini suostuivat toimimaan kurssin opiskelijoiden mentoreina. Mentoreiden tehtävänä oli tarkistaa viikonloppukokouksissa annetut harjoitukset ja auttaa niitä tehdessä ilmenneissä ongelmissa. Opiskelijat olivat yhteydessä mentoreihin Slackin kautta.

Olin mentorina kahdelle oppilaalleni. Se oli merkittävästi erilainen opettamisen muoto - ja täynnä omia sudenkuoppiaan. Yksi asia, jonka tajusin hieman liian myöhään, on se, että hyvän ohjelmoijan on oltava itsenäinen - hänen on ainakin yritettävä ratkaista ongelmia itse ennen kuin hän pyytää apua. Ja se, että olin koko ajan tavoitettavissa Slackissa, ei ainoastaan vienyt paljon aikaani, vaan ei myöskään innoittanut tällaiseen itsenäisyyteen.

Älkää käsittäkö minua väärin - monet kysymykset, joita minulta mentorina kysyttiin, olivat päteviä, ja niihin vastaaminen oli opiskelijoiden tietojen levittämistä. On kuitenkin hyvin helppoa siirtyä "opettajamoodiin" - ja selittää uudelleen kaikki viikonloppukokouksissa käsitellyt asiat. Nykypäivän näkökulmasta mentorin tehtävänä on mielestäni luoda yleiskatsaus, tarjota hyödyllisiä linkkejä ja esittää kysymyksiä, jotka voivat auttaa ratkaisun löytämisessä. Silloin tällöin voi tapahtua selittämistä, mutta sen ei pitäisi olla suurin osa siitä.

Tiedustelun käyttö

Jokainen oppilas on erilainen. Yksi suurimmista vaikeuksista oli mukauttaa kurssin tempo siten, että se sopisi parhaiten kaikille opiskelijoille. Koska opiskelijoiden taustat ja yleinen taso ottaa uusia ideoita vastaan vaihtelevat, se on lähes mahdoton tehtävä.

Aikataulumme oli 9 kokousta - kertaa 2 päivää kertaa 8 tuntia, joten meillä oli 144 tuntia aikaa siirtyä 0:sta Ruby-heroon. Oli ensiarvoisen tärkeää tehdä koko opetusohjelma tässä ajassa - mikä jo itsessään pakotti meidät melko nopeaan tahtiin. Kolme ensimmäistä kokousta käsitteli Rubya - sitten yksi kokous SQL:ää, sitten RoR:ää ja yksi kokous JS:ää.

Opettajana minun oli aina tiedettävä, kuka enemmän tai vähemmän ymmärtää osan esittelemästäni materiaalista. Joskus riitti, että kysyin, onko asia ymmärretty, joskus tein pieniä testejä. Pyysin esimerkiksi kaikkia oppilaitani lähettämään minulle omat määritelmänsä Ruby-käsitteille, kuten luokka, itse, menetelmä, muuttuja jne., Slackissa. Jos jokin asia oli erityisen epäselvä, palaisin takaisin ja yrittäisin selittää sen uudelleen.

Illuusio ja todellisuus

Yhteenvetona voidaan todeta, että opettaminen oli vielä vaikeampi tehtävä kuin luulin sen olevan. Se voi olla myös hyvin palkitsevaa. Siitä huolimatta se on kovaa työtä ja sen vaikutukset eivät riipu pelkästään opettajasta - oppilaan oma ponnistus on vielä tärkeämpää hänen oppimisessaan. Tämä tekee opettamisesta hyvin erilaista kuin ohjelmoinnista, jossa yleensä voi omistaa kaikki onnistumiset ja epäonnistumiset. On tärkeää muistaa tämä ero.

Se myös pakottaa ajattelemaan asioita, joita ei yleensä ajattele - asioiden selittäminen antaa myös paremman käsityksen niistä. Tällä tavoin opettaminen voi myös tehdä sinusta paremman ohjelmoijan.