Archive by Author | Matti Nelimarkka

Kevät alkaa

Viimeistely tämän tekstin osalta jäi vähän, nythän ollaan jo ensimmäisessä opetusviikossa.

Opiskelijoiden joululoma jatkuu vielä viikolla, mutta valitettavasti assarointi pyörii jo, ja välillä käydään maitohapoilla. Edessä on Interactive Systems -nimellä kulkeva maisterivaiheen käyttöliittymäkurssi, missä keskitytään käyttöliittymän luomiseen ja sen empiiriseen testaamiseen.

Käytännössä kurssin ohjelma on muodostunut juuri ennen joululomaa — luennoitsijahan siitä vastaa, mutta teemme tiivistä yhteistyötä. Siitä huolimatta odotan luentoja mielenkiinnolla ja yritän olla niissä itsekin paikalla.

Minun suuremmalle vastuulleni kuuluu sitten hands on-työskentely ja opiskelijoiden ohjaaminen projektityöskentelyyn. Erityisesti projektityöskentelyn osalta mietin. että miten vältetään opiskelijoiden katoaminen ja toisaalta sitten se ilmiö, että minulla on liikaa palloja ilmassa.

Tällä hetkellä mietin väärinkäyttää Moodlea ja pyytää opiskelijoita kirjoittamaan sinne viikoittain oman projektinsa etenemisestä. Moodle, jotta se on edes osittain julkista, toiveeni olisi, että opiskelijat pystyisivät myös auttamaan toisiaan ongelmissa tai pohtimaan niitä yhdessä. Lisäksi sitten pyöritellään jotain ’laskutupa’-tyyppistä asiaa käyttöliittymäkamalle: sinäänsä jännää, että tuonne periaatteessa voi tulla ihmisiä koodiongelmista tutkimusmetodologian tarkistamiseen asti kyselemään apua. Noh, kevään lopussa näkee, että miten tuo toimii.

Lisäksi edessä oli ihana arvostelutuokio aikaisemman Interface Technologies-kurssin osalta. Suurin osa tapauksista oli helppoja, mutta sitten oli muutama, missä jouduttiin pohtimaan asiaa erityisesti. Erityisesti yksi asia, mihin törmäsimme oikeastaan muutamankin kerran on, että tiedämme ihan liian vähän ryhmädynamiikasta arvostelun tukena. Emme kuitenkaan seuraa varsinaista projektien valmistumista, emme ole läsnä ryhmän palavereissa ja koodiakin luemme pintapuoleisesti, se kun ei ole kurssin pääasia kuitenkaan.

Siksi vakuutuin luennoitsijan argumenteistä, että kun emme oikeastaan tiedä mitä ryhmädynamiikalle on tapahtunut ja mitkä ovat varsinaisia syy-seuraus-suhteita, ei noista asioista voi erityisesti rankaista, itse saatoin olla jopa liian kriittisellä päällä. Tämä on ehkä ryhmätyöskentelyn isoimpia ongelmia akateemisessa maailmassa, että kuinka sen arvioinnin saa toimimaan fiksusti. Onko lukijoilla mitään hyviä ideoita tästä?

Mainokset

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…