Archive | Ohjelmoinnin peruskurssi RSS for this section

Etulinjassa

Taistelu osaavempien opiskelijoiden puolesta jatkuu edelleen, tällä hetkellä sekä Ohjelmoinnin peruskurssilla (osa 2) Aalto-yliopistolla että Human-Computer Interaction-kurssilla Helsingin yliopistolla.

Ensi maanantaina tapaan ohjelmointikurssin opiskelijat ensimmäiseen kertaan kuukauteen ja katson, mitä he ovat saaneet aikaiseksi. Suurinta osaa en ole siis nähnyt välissä, vaan opiskelijat ovat puurtaneet töitä hyvin itsenäisesti. Ohjausta toki olisi saanut viikottain, mutta suurin osa ei ainakaan minun ryhmässä ole käynyt. Perinteisesti tämän välitarkastuksen aika on ollut vain herätellä opiskelijoita, että työn pitäisi edetä — ja odotan sitten, että kuinka moni tyyppi aloittaa maanantaina kertoen, että koodia tuli tehtyä tuossa viikonloppuna.

Tämä on siis melko vapaa ja valvomaton työskentelytapa, missä on omat haittansa ehdottomasti. Mutta, ainakin tämä opettaa ohjelmoinnin lisäksi oman työn suunnitteluun ja aikataulutukseen — mielummin itse vetäisin jotain säännöllisempää kohtaamista opiskelijoiden kanssa…

Human-Computer Interaction-kurssilla taas olen ainoa assistentti ja pystyn määrittelemään melko vapaasti työskentelytapoja ja muokkaamaan tehtävänantoja. Ensimmäinen havaintoni toki on ollut, että hyvien tehtävänantojen tekeminen on haasteellista: haluan, että niissä jää tilaa omalle oivallukselle ja osaamisen näyttämiselle, mutta ensimmäisen viikon jälkeen huomasin, että omaa vaatimustasoaan kannattaa määritellä suoremmin, vaikkei kädestä ohjaisi miten tehtävä pitäisi ratkaista.

Suurempi kysymys Human-Computer Interaction-kurssilla on katoavat opiskelijat. Kurssin Moodleen asti on päässyt 39 opiskelijaa, ensimmäisen viikon tehtäviä palautti 32 ja nyt toisen viikon tehtäviä 27 opiskelijaa. Jokaisessa välissä tietenkin on lähetetty sähköpostia, että mitäs tässä on tapahtunut ja toivonkin, että tuosta 27stä noustaisiin vielä parilla opiskelijalla. Silti hukkuvat opiskelijat aina mietityttää, olisiko ohjausta pitänyt tarjota enemmän, onko tehtävänannot olleet liian epämääräiset tai onko kurssi liian vaativa? Vai, onko opiskelijoilla vaan keväisesti kovin kovin kiire…

Kitinää

Kurssin varsinaiset tehtäväkierrokset päättyivät siis. Edessä on projektin tekeminen, joka alkoi ensimmäiseksi suunnittelulla ja suunnitelmien palauttamisella. Tuokin palautus on jaettu kahteen osaan, ensisijaisesti että kumpaakin palasta tulisi mietittyä ja tehtyä se tarpeeksi ajoissa. Vaativampi tekninen suunnitelma oli noista jälkimmäinen palautus, sitä ennen palautettiin yleissuunnitelma.

Opiskelijat kovasti valittelivat, että aikaa ei ole tarpeeksi. Kyllä, olen itsekin ollut siinä tilanteessa, että useamman kurssin harjoitustehtävät pitäisi palauttaa ja pitäisi venyä suuntaan jos toiseen. Mutta, väitän kovasti, että tuossa ensisijaisesti on kyse opiskelijoiden omista valinnoista ja ajanhallinnasta. Viimeinen kierros venyi monella liian myöhään ja sitten tämä suunnitelma tuli kuin puskasta.

Hyväksytään, meidän osalta viestinnässä myös on taas kerran epäonnistuttu. Monet tuntuvat stressaavan liikaa suunnitelmasta, varmaan koska siitä annetaan arvosana. Suunnitelman varsinainen tarkoitus on vain näyttää, että on hahmoittanut tehtävän oikein ja että on about hajua siitä, että mitä lähtee tekemään ja miten niitä pitäisi tehdä — saada siis opiskelijoita ajattelemaan hommaa ja myös ohjattua opiskelijaa oikeaan suuntaan tekemisessä. Sen ei tarvitsisi olla valmis, mutta monet selvästi panostaa siihen vähän liikaa: suunnitelma kirjoitetaan itseään varten, ei meitä assareita. Ja, sivuilta puuttuu edelleen esimerkit hyvistä projektisuunnitelmista, jospa tänä vuonna muistaisi laittaa noita sivuun ja pyytää lupia julkaisemiseen…

Kitinässä ärsyttävintä tosin on, ettei se ruoho kovin paljon vihreämpää aidan toisella puolella ole. Heti palautusajan jälkeen, perjantaina viiden aikaan käytin noin tunnin omien assaroitavien metsästämiseen, kun oli puututtuvia palautuksia ja puuttuvia ajanvarauksia.

Sunnuntaina käyn läpi ohjattavien opiskelijoideni suunnitelmat, yhteensä 20 työtä ja valmistaudun kommentoimaan niitä maanantaina. Koska olen assaroinut jo useamman vuoden, niin näitä lukee hyvin liukuhihnalta ja aikaa menee varmaan vain neljä tuntia. Samat ongelmakohdat ovat niin tuttuja vuodesta toiseen — tästä ehkä seuraavassa kirjoituksessa.

Ja tietenkin tämän kaiken päälle meillä assareillakin on muutakin kuin tämä kurssi hoidettavana: on töitä, opiskelua, muita kursseja, harrastuksia, ihmissuhteita, … Ihan kuten niillä opiskelijoilla.

Eniten pohdin, että mistä ihmeestä lisää aikaa voisi repiä: tenttiviikko siintää nurkan takana, ja sille ajalle ei voi laittaa henkilökohtaista ohjausta. Tenttiviikon jälkeen ollaankin jo uuden periodin puolella, eli projektin koodaukseen olisi jäänyt varsin vähän aikaa. Toisaalta kierrokset, jos nyt ei ensimmäistä kierrosta lasketa, ovat kyllä pitäneet ihmiset kiireisinä, ja siellä on tietoisesti jatkettukin joitain aikarajoja, että ihmiset saisi harjoitustehtävät tehtyä.

Uliuli!

Kurssilla on päästy kuuluisaan toiseen kierrokseen, missä tehtävät vaikeutuvat. Vaikeusasteen kohoaminen todella näkyy, vaikka en edes tällä viikolla pyörittänyt laskareita. Kävijämäärät nousevat ja ruuhkaakin on, ja mitä olen kuullut, niin hämmentyneitä assareita.

Yksi ongelma on, etteivät ihmiset mieti sitä ratkaisua etukäteen. Tämä mielikuva ainakin minulle aina välillä jää. Sitten lähdetään fiiliksellä koodaamaan, huomataan pari ikävää erikoistapausta, laitetaan erikoistapausten hallintaa ja sataa riviä myöhemmin mietitään, että miksi tämä ei vieläkään toimi kunnolla. Ja, hyvä jos edes itse muistetaan, miten koodi toimii täysin.

Toinen ongelma, varsinkin irkin kautta, tuntuu olevan, etteivät ihmiset edes kuuntele. Vihjeet testaustapojen muutoksista, koodin siistimisestä tai melkein mistä tahansa muusta kaikuvat kuuroille korville. Parhaimmillaan asiaa pääsee jankkaamaan, jolloin minulla ainakin alkaa pinta kiristymään, varmasti myös siellä ruudun toisella puolella.

Noin kokonaisuudessaan, nämä on niitä viikkoja, kun miettii, miksi koskaan edes hakeuduin assariksi…

Kun asiat eivät mene putkeen

Ohjelmoinnin peruskurssin ensimmäistä osaa seuraa ohjelmoinnin peruskurssin toinen osa, joka on alkanut ja ensimmäinen harjoituskierros on jo ohi. Toisen osan erikoisuutena on harjoitustyö, joka oikeastaan muodostaa kurssin keskeisimmän osan: alussa käydään läpi parit harjoituskierrokset, mutta sen jälkeen siirrytään itsenäiseen työskentelyyn melkeimpä vappuun saakka.

Ensimmäinen ja toinen kierros ovat olleet mielenkiintoisia kokemuksia, tehtävät eivät ole olleet täysin valmiita ja kiire on ollut. Ikävintä on, että tämä on näkynyt opiskelijoille asti: yhdessä tehtävässä muutimme rajapintaa merkittävästi saadun palautteen perusteella, ja siinä sitten tietenkin tuli omia ongelmia eteen.

Muutenkin askeleet ovat olleet haparoivia suuntaan tai toiseen, tai tälläinen fiilis siitä on jäänyt itselle ainakin. Ja, varmasti se on näkynyt uloskin asti, se on se ikävin puoli. Näin kokonaisuudessaan huokaisen kyllä helpotuksesta kun harjoituskierrokset saadaan pakettiin ja jäljelle jää vain se projekti-mörkö.

Muuten, se mikä on ollut kiinnostavaa ja mielestäni kovin hienoa on se tunteen palo, jolla opiskelijat ovat tuoneet esille löytämiään epäkohtia ja puutteita. Jos ei muuta, niin opiskelijatkin välittävät siitä, mitä täällä käydään läpi ja mitä vaaditaan tekemään. Valitettavasti meidän puolella systeemit ovat rakoilleet enemmän tämän palautteen vastaanottamisessa, mutta kovasti sanoisin, että parannutaan siinäkin.

Arvioinnin kauheudesta

Automaattinen tehtäväntarkastin ei selviä kaiken tarkastamisesta, ja ohjelmoinnin peruskurssilla tälläinen on tekstiseikkailupeli. Ei hätää, kyllähän assarit lukevat koodia — eli, meille tuli kullekin noin kymmenen työtä tarkistettavaksi.

Sellaisenaan koodin lukeminen ja kommentointi eivät ole kovinkaan mitenkään uutta ja erikoista, mutta inhoan yli kaiken pisteiden antamista. Tehtävän pisteet vaikuttavat siihen, minkä arvosanan opiskelija saa kurssista, tällä kurssilla tosin melko vähän, mutta vaikuttaa kuitenkin. Ja, vastuu painaa harteilla — kuuluisiko tämän työn saada 150 vai 160 pistettä?

Vaikka töitä onkin tullut arvosteltua useampi vuosi, ei se ole sen helpompaa. Ehkä se isoin haaste on juuri, että tämä ei ole mekaaninen tarkistus, jossa voisi sanoa, että toimii tai ei toimi, sen sijaan tässä pitää sanoa, että onko joku hyvä vai huono. Ja, nämähän ovat kuitenkin subjektiivisia käsityksiä, omia arvioitani siitä, onko joku toteutus hyvä vai huono, ja minkälaisia toteutuksia tämän kurssin puitteissa pitää odottaa ja vaatia.

Aikuisten oikeasti haluaisin mielummin iteroida näitä tehtäviä opiskelijoiden kanssa, niin, että he saisivat laadukkaamman lopputuotteen, joka täyttäisi tai jopa ylittäisi kurssin osaamisvaatimukset. Eli, kyseessä ei olisi tälläinen lopullinen arviointi, kuten se nyt on.

Toki — meillä on olemassa arvosteluohjeistus ja sitä käytetään hyödyksi. Veikkaan myös, ettei meidän assarien välillä ole suuria eroja loppujen lopuksi, mikä on se tärkein asia. Silti, nytkin kun katson arvostelemieni töiden pistejakaumaa, mitetin, olenko ollut liian tiukka, olenko taas vaatinut kohtuuttomia?

Loppujen lopuksi tässä ei auta muu kuin luottaa siihen, että osaa arvioida opiskelijoita oikein ja olla tasapuolinen ja reilu. Ei se arvosanojen arpominen ole kivaa, sanallisen arvostelun sain tehtyä kahdessa päivässä ja pisteytys on nyt ollut jumissa pidempään — ei ole vielä onneksi kiire. Ehkä seuraavan kerran käytän suosiolla porrastekniikkaa

Saako opiskelijaa itkettää?

Me kaikki assarit kohtaamme tilanteita, kun eteemme tulee purkkapallo. Epämääräinen viritys-säätö, joka melkein toimii. Vaihtoehtoja voisi olla koko ratkaisustrategian uudelleenpohdinta yhdessä opiskelijan kanssa tai pyrkiä setvimään ja selvittämään, miksi koodi ei toimi. Molemmissa näissä on etunsa ja haittansa, luonnollisesti.

Mutta, miten tämä liittyy itkemiseen? Ei, en ole siirtynyt iltapäivälehtimaiseen otsikointiin, vaan taustalla on tarina, jonka olen kuullut.

Ohjelmointikurssilla oli opiskelija, joka oli useamman tunnin vääntänyt omaa koodiaan toimintakuntoiseksi. Laskareissa assari kohteliaasti suositteli, että ohjelman voisi aloittaa koodaamaan tyhjästä, uudella paremmalla ratkaisualgoritmilla. Tästä seurauksena oli itkureaktio, olihan siihen omaan koodiin käytetty runsaasti aikaa ja vaivaa — nyt se oli arvotonta.

Seuraavana aamuna sama opiskelija ilmestyi laskareihin. Hän tuli kiittämään assaria tästä voimakkaasta kehoituksesta.

Ja, kukapa ei ymmärtäisi opiskelijan näkökantaa tässä: kaikki valvotut tunnit ja työ onkin mennyt hukkaan. Mutta, ymmärrän myös ohjaajaa — epämääräisen purkkapallon debugaaminen ei ole helppoa eikä kivaa.

Mielellään sitä auttaisi ongelman ratkaisussa tavalla, jonka opiskelija on ihan itse keksinyt, mutta aina se ei ole niin helppoa. Ihmiset ampuvat itseään jalkaan tai tekevät muita jännyyksiä. Seuraava esimerkki varmaankin valaisee, mitä tarkoitan (erään kurssilaisen suoritus, luvan kanssa täällä):

if self.is_open():
   i = 0
   for i in range(len(self.buyers)):
     if amount >= self.buyers[i].get_limit():
       if i == len(self.buyers) - 1:
         if amount == self.buyers[i].get_limit():
           self.price = amount
           return False
         x = 0
         for x in range(len(self.buyers)):
           highest_limit = self.buyers[0].get_limit()
           if highest_limit highest_limit = self.buyers[x].get_limit()
             x += 1
             self.price = highest_limit + 1
       else:
         i += 1
    elif amount < self.buyers[i].get_limit():
      return False
  self.buyer = bidder
  self.buyers.append(Bid(bidder, amount))
  return True
else:
  return False

Vaikka kovasti yritin ymmärtää, mitä tämä koodi tekee, se jäi minulle nopealla katsauksella epäselväksi. Onneksi tarkistusjärjestelmämme antoi tuosta täydet pisteet, muuten olisi pitänyt kaivaa tuostakin selvyys esille — luultavasti aidossa ohjaustilanteessa olisin lähtenyt muokkaamaan tuota koodia lähemmäksi malliratkaisun tyyliä.

Niin, jopa siinä tilanteessa, että tämä tuote on opiskelijan itsensä tekemää ja pohtimaa, niin pitäisi arvokkaana sitä, että istuisimme hetken aikaa alas ja miettisimme erilaisia ratkaisutapoja tähän ongelmaan ja niiden eroja toteutustavoissa. Toisaalta, joskus opiskelijat kehittävät hyvin luovia ratkaisuja ongelmiinsa, joista näkee sisäisen logiikan hyvin selvästi. Toisen kurssilaisen toteutus (jälleen luvan kanssa) ongelmaan oli seuraava.

if self.is_open() and self.get_minimum_bid_amount() <= amount:
  self.bid_list.sort()
  self.highest_bid = self.bid_list[-1]
    if len(self.bid_list) == 1:
      self.bid_list.append(amount)
      self.highest_bidder = bidder
      return True
    else:
      self.bid_list.append(amount)
      self.highest_bidder = bidder
      return True
else:
  return False

Tuossa on piilossa yksi virhe, minkä takia se ei toimi kuten oletettua. Jätettäköön tarkempi virheen etsiminen harjoitukseksi. Kuitenkin, tässä kohtaa olisin luultavasti erottanut tämän virheen erikseen ja selostanut, mistä se johtuu ja sitten olisimme ratkaisseet vain tämän yksittäisen ongelman.

Mikä sitten erottaa nämä kaksi tapausta toisistaan? Ensimmäisen opiskelijan kohdalla minun on vaikea seurata ratkaisua, siellä on myös mukana ohjelmointikikkoja, joita ei normaalisti haluaisi nähdä. Toisen opiskelijan ratkaisu taas on melko suoraviivainen ja sen logiikan ymmärtää heti.

Ideaalissa maailmassa molempia tapauksia olisi tietenkin autettaisiin samalla tavalla, koska on aina hyvä rakentaa opiskelijan oman ajattelun ja ongelmanratkaisun päälle asioita. Käytännössä, opiskelijan omat ratkaisut voivat olla ongelman luonteeseen sopimattomia tai hyvin vaikeita toteuttaa, jolloin on helpompi vääntää ratkaisua oikeanlaiseen suuntaan. Erityisesti, jos opiskelijan koodi aiheuttaa mielenkiintoisia (lue: vaikeita) erikoistilanteita, joiden hallinta sitten muuttuu suoksi.

Opiskelijoiden itkettäminen ei välttämättä ole paha asia. Erilaiset ratkaisutavat toivottavasti myös laajentavat opiskelijan kykyä ratkaista ongelmia tulevaisuudessa, varsinkin jos pystyy kriittisesti arvioimaan omaa ratkaisuaan. Ainakin minulle kriittinen arviointi ja vaihtoehtojen puntarointi on keskeinen osa ammattiosaamista. Ehkäpä The Daily WTF tulisi ottaa pakolliseksi lukemistoksi kurssille…

Milloin tehtäviä tehdään?

Kurssimme automaattinen tarkistusjärjestelmä Goblin tarkistaa tehtäviä väsymättä viikon jokaisena päivänä kellon ympäri. Tähän mennessä palautuksia on tullut yhteensä yli 25 000 kappaletta. Määrä on niin suuri, että tilastojen tekeminen Excelillä ei sujunut enää kovin jouhevasti, vaikka lopulta sitten homma onnistuikin…

Jakautuvatko palautukset tasaisesti eri viikonpäiville tai kellonajoille? Entä voisiko huoltokatkon järjestää helposti johonkin tiettyyn aikaan, jolloin se ei haittaisi opiskelijoita?

Vastaus molempiin kysymyksiin on ei. 24/7 toimivaa tarkistusjärjestelmää hyödynnetään kaikkina päivinä ja kaikkina aikoina. Luonnollisesti tiistaina klo 12:00 oleva tehtävien määräaika näkyy jakaumassa selkeästi, mutta sellaista hetkeä ei juuri ole, että palvelin saisi levätä.

Tarkastellaan ensiksi, mihin vuorokauden aikaan palautuksia tehdään eniten:

Palautusten jakautuminen vuorokauden aikoina

Kuvaajasta näkee selvästi, että palautuksia tehdään eniten iltapäivällä. Toisaalta käyttäminen on vilkasta noin kello kymmenestä eteenpäin aina pitkälle yöhön saakka. Teekkarit nukkuvat tilaston perusteella todennäköisimmin klo 4-8, vaikka silloinkin tehdään joitakin palautuksia. Lounasaika taas laskee käyttöastetta merkittävästi juuri ennen pahimman ruuhkahetken alkua.

Entäpä sitten viikonpäivät, mitä sieltä voidaan havaita:

Tehtävien palauttamisen jakautuminen eri viikonpäiville

Ei liene mitenkään yllättävää, että maanantai erottuu noinkin selkeästi muista päivistä. Suurin osa opiskelijoista tekee tehtäviä siis vasta edellisenä päivänä. Lauantai näyttää olevan se päivä, jolloin koulutöitä tehdään vähiten. Sunnuntaina tehtäviä kuitenkin tehdään innokkaammin kuin perjantaina.

Jos maanantai on vilkkain päivä, niin kuinka aikaisin opiskelijat sitten tekevät tehtäviä noin yleensä? Tutkitaan seuraavaksi, milloin palautuksia tehdään viikon aikana ennen DL:ää:

Eri kierrosten palautusaktiivisuus viikon aikana ennen määräaikaa. Y-akselilla on vuorokausien määrä ennen määräaikaa ja X-akselilla kierroksen numero. Määräaika on kuvaajan yläreunassa.

Kuvaajassa on esitetty, milloin palautuksia on tehty. Havaitaan selkeästi, että viimeinen vuorokausi on varsin tiivistä aikaa tehtävien tekemiseen. Viiden ensimmäisen kierroksen määräaika on ollut klo 12, mutta kierrosten 6 ja 7 määräaika oli klo 20. Tästä johtuen yön vaikutus näkyy hieman eri tavalla. Eri kierrosten välillä ei ole juurikaan eroa, milloin palautuksia on tehty.

Tutkitaan viimeistä vuorokautta vielä tarkemmin:

Palautukset viimeisen vuorokauden aikana

Tästä kuvaajasta voidaan nähdä, että tehtäviä on tehty tiiviisti edellisenä iltana ja yönä sekä sitten juuri ennen kierroksen sulkeutumista tulee vielä viimeinen palautussuma. Kuudennen ja seitsemännen kierroksen osalta koko päivää on hyödynnetty ahkerasti, kun kierros sulkeutui illalla.

Meidän assareiden näkökulmasta on periaatteessa samantekevää, milloin tehtäviä tehdään, mutta luonnollisesti tämä näkyy myös kurssin harjoitusryhmien kävijämäärissä. Jos porukkaa on paljon, niin avun saaminen kestää pidempään ja aikaa neuvoa on vähemmän. Eri harjoitusryhmien ruuhkaisuus näkyy seuraavassa kuvassa:

Eri harjoitusryhmien ruuhkaisuus

Maanantain kohdalla on aivan selvä piikki ja loppuviikon harjoitusryhmissä on selvästi hiljaisempaa. Kahden viimeisen kierroksen DL:n siirtyminen keskiviikkoon ja torstaille näkyy myös siten, että parina viime viikkona myös keskiviikon ryhmissä on ollut enemmän opiskelijoita.

Mitä tästä kaikesta voisi siis sanoa? Jos et tee tehtäviä klo 4-8 aamuyöllä, niin on varsin todennäköistä, että jokin muukin tekee tehtäviä samaan aikaan. Ilmiö näkyy myös kurssin IRC-kanavalla: noihin aikoihin on hiljaista, mutta muuten keskiyön jälkeenkin kanavalla on vielä suht aktiivista keskustelua.

Mikäli tehtäviin kaipaa neuvoja, niin on suositeltavaa aloittaa hyvissä ajoin, jolloin assareilla on harjoituksissa enemmän aikaa neuvoa. Maanantaina aloittaminen ei ole muutenkaan hyvä idea, jos esimerkiksi Aallon tietokoneet hajoavat tai tehtävien kanssa tulee vastaan muita ongelmia. Jos taas olet ihan varma, että kaikki sujuu suunnitelmien mukaan, niin tehtävät saa kyllä kasaan, vaikka aloittaisi vasta tiistaina aamulla. 🙂