Miten yhdistää projektioppiminen ja teoriaoppiminen?
Esimerkiksi, jos teen GitHub:iin projekteja, niin miten voin yhdistää niissä sitä, että demonstroin samalla järkevästi sitä, että hallitsen teorian? Sen sijaan, että demonstroisin teoriaosaamista jollain sertifikaateilla ja teoriakokeilla?
Voihan ne tietysti yhdistää omassa päässä, mutta oleellinen kysymys on, että miten yhdistää ne siten, että muutkin näkevät niiden yhdistyvän?
Jos pelkkä koodi ei kerro, miksi jotain tehdään juuri tietyllä tavalla, koodiin kirjoitetaan kommentteja tai erillistä dokumentaatiota, jossa koodin tarkoitus tai siihen liittyvä teoria selitetään sopivan tarkasti. Voisitko antaa selvän esimerkin, jossa tämä ei mielestäsi riitä? Mitä teoriaosaamista ja mille kohderyhmälle haluaisit tällöin tuoda enemmän esiin?
Metabolix kirjoitti:
(13.07.2025 08:09:05): Jos pelkkä koodi ei kerro, miksi jotain tehdään...
Ajattelin vaan, että mikä on tehokas tapa demonstroida tuota portfoliossa tms. Useimmiten lukijoilla ei ole kuitenkaan tuhottomasti kiinnostusta tai aikaa lukea kaikenlaista detailia. Kurssisuoritus tai sertifikaatti on nopea lukea, mutta se ei oikeastaan kerro koko totuutta. Olen esimerkiksi opiskellut jotain ainakin 10 op eli n. 266 tuntia Java:a enkä siltikään osaa Java:aa kovin hyvin. Sen sijaan, jos tekisin vaikka 60 tunnissa Java-projektin, niin voisin ainakin selittää, että mitä konsepteja sovelsin onnistuneesti.
Teoriakokeet eivät ole sama asia kuin sovellusosaaminen.
mavavilj kirjoitti:
Sen sijaan, jos tekisin vaikka 60 tunnissa Java-projektin, niin voisin ainakin selittää, että mitä konsepteja sovelsin onnistuneesti.
Tämä sopii GitHubissa hyvin projektin README-tiedostoon. Jos jostain syystä näitä konsepteja olisi niin paljon, että niiden kuvailu README:ssa vie liikaa tilaa tärkeämmältä tiedolta (kuten käyttöohjeilta), voisi mainita README:ssa jotain tärkeimpiä ja linkittää toiseen dokumenttiin, jossa on lisää yksityiskohtia.
Metabolix kirjoitti:
(13.07.2025 16:24:45): ”– –” Tämä sopii GitHubissa hyvin projektin README...
Kyllä, mutta tämä on vain mekaaninen vastaus kysymykseen.
Mielestäni se on täysin hyvä vastaus. Jos kaipaat jotain muuta vastausta, sinun pitää ensin selittää asiasi todella paljon paremmin. Selvästi Java-projektia koskeva esimerkkisi ei ollut tarpeeksi kuvaava.
Metabolix kirjoitti:
Mielestäni se on täysin hyvä vastaus. Jos kaipaat jotain muuta vastausta, sinun pitää ensin selittää asiasi todella paljon paremmin. Selvästi Java-projektia koskeva esimerkkisi ei ollut tarpeeksi kuvaava.
Esimerkissä on tietysti oleellista, että teoriassa Java:sta ei voi tietää alle 266 tunnissa tms., mutta käytännössä voi tehdä 60 tunnissa Java-projektin, joka käyttää kehittyneitä konsepteja. Teoria ei kuitenkaan ole käytäntö, ja projekti ei ole kuin ne kurssit. Miten voi välittää 60 tunnin Java-projektissa samat asiat kuin 266 tunnin kursseilla + tentillä?
Olisiko mahdollinen tapa vain kirjoittaa README:een, että mitä teoriakonsepteja oli tarkoitus harjoituttaa ja missä ne näkyvät?
Tuossa nyt koko perusolettamus on outo. Ihan kuin kuvittelisit, että rekrytointi tapahtuu yksityiskohtaisilla ja osoitettavilla kriteereillä kuin koulussa arviointi. Mainitsee luokkahierarkian, 1p. Käyttää perintää koodissa, 1p.
Jokainen ymmärtää, että 266 h tai 10 op Javan alkeita on todellakin alkeita ihmisille ilman aiempaa ohjelmointitaitoa. Kurssitodistuksen osoittama osaaminen on työelämän kannalta edelleen nolla. Melkein mikä tahansa hyödyllinen Java-ohjelma osoittaa käytännössä vastaavan taitotason ja usein enemmänkin. Tätä tietoa ei tarvitse erikseen "välittää" omassa projektissa, kunhan teet 10 op kurssien isointa tehtävää isomman ja vaikeamman ohjelman.
Jos nimeät osaamisena, että "int, class ja extend ovat tuttuja ja käytin niitä tässä projektissa, ja jäsenten näkyvyysalueet ovat ohjeiden mukaiset", näyttää siltä, että et osaa juuri mitään ja ohjelma on maksimisuoritus. Eli mitään alkeita ei ole varmasti syytä mainita. Paremman kuvan saa vaikka tekstistä "tarvitsin työkalun X ja koodasin sen huvikseni Javalla oikein yksikkötestien kanssa". Tärkein näyttö tällä tasolla on se, että koodia on tehty ja se toimii. On myös hyvä tilaisuus käyttää kaikenlaisia kirjastoja ja työkaluja ja näyttää, että pystyy omaksumaan ja yhdistämään niitä.
Kukaan ei tule pyytämään töihin sen perusteella, että "GitHubista huomasin, että osaat tehdä MVC-mallin mukaista koodia". Kukaan ei edes pudota rekrytointiprosessista pois siksi, että "tämä GitHub-projekti näyttää tosi hyvältä, mutta tässä ei nyt valitettavasti lue, onko MVC-mallin mukainen". Eli ei varmasti ole suurta merkitystä, mainitseeko tämän tason yleisesti tunnettuja ja käytettyjä konsepteja. Hieno projekti on varmasti edelleen tärkein näyttö.
Enemmän osaamista vaativissa asioissa voi olla parempi kuvailla sisältöä, esimerkiksi isomman projektin kokonaisrakennetta, suunnittelua, kryptografiaa, verkkoprotokollaa tms. Näissä ajatus ja periaate on kiinnostavampi kuin koodi.
Jos taas konsepti on ratkaista kauppamatkustajan ongelma polynomisessa ajassa, se on varmasti hyvä tuoda ilmi eikä vain todeta, että "palasin tämän vanhan ongelman pariin ja tässä taas yksi versio". Hyvä ehkä myös kirjoittaa lehteen.
Eli suhteellisuudentajua, mikä on oikeasti kiinnostavaa ja merkittävää.
Ja kyllä, mielestäni README on edelleen hyvä paikka kertoa näistä tiedoista.
Hyvä huomioida myös tekoäly nyt, kun tekoälyllä voi tuottaa tavallista koodia ja siis pelkkä koodin tuottaminen ei ole enää minkäänlainen ansio. Pitäisi varmaan yrittää erottua tekoälyn tasosta jotenkin tekemällä isompaa ja omaperäisempää tai esittelemällä jotenkin omia taitoja tekoälyn käytössä. Ehkä joku osaa sanoa, miten näihin hommiin nyt rekrypuolella suhtaudutaan?
mavavilj kirjoitti:
Ajattelin vaan, että mikä on tehokas tapa demonstroida tuota portfoliossa tms. Useimmiten lukijoilla ei ole kuitenkaan tuhottomasti kiinnostusta tai aikaa lukea kaikenlaista detailia. Kurssisuoritus tai sertifikaatti on nopea lukea
Tässähän tämä keskeinen ongelmasi piilee, eli sertifikaatissa tai kurssisuorituksessa joku luotettavaksi oletettu taho on tutkinut tekemistäsi ja arvioinut sen. Sillä että laitat projektin johonkin, niin se arviointityö siirtyy sille, jonka haluat arvostavan taitojasi.
Grez kirjoitti:
(14.07.2025 08:41:55): ”– –” Tässähän tämä keskeinen ongelmasi piilee, eli...
Kyllä, mutta näissä on myös ainakin IT-alalla vissi ero. Kokemukseni mukaan juuri kukaan ei palkkaa ainakaan tällä hetkellä pelkällä tutkinnolla, joten nyt teen sitten portfoliota.
Kysymys on, miten voin demonstroida sitä, että minulla on hyvää teoriaosaamista JA sovellusosaamista, kun pelkällä tutkinnolla voi demonstroida vain teoriaosaamista ja ilman tutkintoa voi demonstroida vain tietynlaista sovellusosaamista, mutta ei välttämättä asioiden yleistä ymmärrystä.
Lisäys:
Olen kyllä sitä mieltä, että joillain alueilla se, että sovellus toimii, riittää. Jos tekisin web-sivuja, niin niissä muut kuin tekniset osa-alueet ovat varmasti asiakkaille arvokkaampia. Näin ei kuitenkaan olisi vaikkapa sulautetuissa järjestelmissä tai algoritmeissa, joissa tehokkuus ja oikeellisuus ovat olennaisia. Myös suurien ohjelmistoprojektien kontekstissa pelkän toimivuuden lisäksi pitäisi osata kirjoittaa selkeää koodia, noudattaa annettuja ohjeita/standardeja, osata testata ja osata selittää asioita muille.
mavavilj kirjoitti:
Kysymys on, miten voin demonstroida sitä, että minulla on hyvää teoriaosaamista JA sovellusosaamista
Millaisesta teoriaosaamisesta puhut? Onko jotain muuta kuin 10 opintopistettä Javaa? On vaikeaa neuvoa, kun kirjoitat todella abstraktilla tasolla.
Ainakin algoritmit, tietorakenteet, ohjelmistoarkkitehtuuri, testaaminen ja kääntäjät ovat sellaisia aiheita, joiden osaamista voi helposti demonstroida harrastusprojekteilla.
mavavilj kirjoitti:
ilman tutkintoa voi demonstroida vain tietynlaista sovellusosaamista, mutta ei välttämättä asioiden yleistä ymmärrystä.
Erikoinen väite. Minusta yleinen ymmärrys tai sen puute tulee todella hyvin esille epätriviaaleista projekteista.
Yksi yleinen tapa esitellä omia projekteja ja osaamista on kirjoittaa blogia. Pelkästään tänne putkaan kirjoittamistasi jutuista käy nopeasti ilmi, minkä verran ymmärrät esimerkiksi ohjelmointikielistä ja niiden toteutuksista.
jlaire kirjoitti:
mavavilj kirjoitti:
ilman tutkintoa voi demonstroida vain tietynlaista sovellusosaamista, mutta ei välttämättä asioiden yleistä ymmärrystä.
Erikoinen väite. Minusta yleinen ymmärrys tai sen puute tulee todella hyvin esille epätriviaaleista projekteista.
Tarkoitin, että yleensä teoriaa opiskelemattomat paljastuvat siitä, että he osaavat tehdä vain tietyn asian, mutta heillä ei ole käsitystä siitä, että on muitakin läheisiä tapoja tehdä samaa asiaa.
Minä olen datanomi ja tradenomi ja koulusisa opetettiin paljon muutakin kuin koodamista kuten erim. ER-mallien piirtämistä tietokannoista ja ks. asiasta en ollut koskaan kuullutkaan ja Flash/ActionScript opetettiin joita en olisi itse opppnut kokekeilun ja erehdyksen kautta kun en tajunnut ominavuin Flash:n käyttöliittymää. Tästä oli siis. Flashin oppimiesta taloudellista hyötyäkin kun vielä 2006-2008 sitä tarvittiin paljonkin työelämässä.
mavavilj kirjoitti:
Tarkoitin, että yleensä teoriaa opiskelemattomat paljastuvat siitä, että he osaavat tehdä vain tietyn asian, mutta heillä ei ole käsitystä siitä, että on muitakin läheisiä tapoja tehdä samaa asiaa.
Tähänkin riittää hyvin ratkaisuksi se, että mainitsee, mitä tapaa on käyttänyt ja miksi. Esimerkiksi jos haluaisit demonstroida osaamista taulukon järjestämisessä, voisit mainita, minkä algoritmin teit ja mikä sen aikavaativuus on (ja ehkä, miksi se sopii juuri kyseiseen tapaukseen), jolloin implisiittisesti eli "rivien välistä" käy ilmi, että tiedät, että tähän on eri algoritmeja ja näillä eri ominaisuuksia.
Blogi voi olla hyvä lisä. Monestakin kiinnostavasta elektroniikka-aiheesta tietoa etsiessä päätyy jonkun hakkerin blogiin, jossa kuvaillaan ratkaisun vaiheita, esimerkiksi miten jonkin laitteen komponentit ja protokolla selviävät ja mitä kivaa tiedolla voi tehdä. Samoin joillakin projekteilla on kiinnostavia blogeja, joissa käydään läpi suunnitteluratkaisuja tai johonkin ongelmaan liittyviä kokeiluja. Tällaista tietoa voi olla vaikea kaivaa koodista, ja dokumentaatioon ei usein laiteta työvaiheita vaan lopputulos. Tietysti pienessä demossa voi myös suoraan dokumentoida nämä asiat ilman erillistä blogia.