IT-alan ongelmana on ilmiselvästi sen koulutuksessa. Tämä on ilmiselvää, koska IT-ala on hyvin laaja ja epämääräinen. Siinä missä jossain lääkiksessä tai kieltenopetuksessa homma on erittäin selkeää mitä opetetaan, IT-alalla asia ei ole näin. Tekniikka kehittyy huimaa vauhtia ja se mitä osaat nyt, on muutaman vuoden päästä museotavaraa. Siks toisekseen erilaisten tekniikoiden tarpeet vaihtelevat hyvin nopeaan tahtiin, joten hyvin vaikeaa siinä on tietää mikä on oleellista. Juuri näistä syistä koulut muistuttavatkin hyvin pitkälti jotain Hrutsevin Neuvostoliittoa.
Mielestäni olisi hyvä, jos keskityttäisiin enemmän niin sanottuun ongelmien ratkomis/havaitsemis kykyyn ja innovatiiviseen ajattelutapaan. Siis luovuuteen sen sijaan että tuijotettaisiin vain mitä asioita hallitaan.
Mielestäni olisi hyvä, jos keskityttäisiin enemmän niin sanottuun ongelmien ratkomis/havaitsemis kykyyn ja innovatiiviseen ajattelutapaan. Siis luovuuteen sen sijaan että tuijotettaisiin vain mitä asioita hallitaan.
Vastaukset 7
Vanhimmat
"Mielestäni olisi hyvä, jos keskityttäisiin enemmän niin sanottuun ongelmien ratkomis/havaitsemis kykyyn ja innovatiiviseen ajattelutapaan. Siis luovuuteen sen sijaan että tuijotettaisiin vain mitä asioita hallitaan."
Sillä ei työllisty mihinkään IT-alan yritykseen. Alalla tarvitaan jatkuvan koulutuksen ja opiskelun mallia. Nyt koulujärjestelmä laahaa jossain 50-luvun maailmassa, jossa opiskeltin yksi ammatti ja mentiin duuniin ja jäätiin siitä työstä eläkkeelle.
IT-ala vaatii jatkuvaa kouluttautumista, eikä työntekijöillä ole aikaa työnohessa nykymallilla opiskella. Alan työntekijöistä on tullut kertakäyttötyövoimaa, mikä käy yhteiskunnalle kalliiksi.
Koulujärjestelmässä on kyllä tilaa aikuisopiskelijoille, mikäli työnantajilta löytyy joustoa. Kaikilta ei, mutta joiltakin kyllä. Tuon "50-luvun maailman" liittäisin kyllä tarjolla olevaan koulutukseen siinä mielessä, että oppilaitoksilla ei yksinkertaisesti ole mahdollisuuksia mennä kehityksen kärjessä. Opetuksessa käsitellään vähän pakosta ei välttämättä kaikkein kilpailukykyisimpiä juttuja eikä laitteistot ja työkalut ole rahapulan takia välttämättä kaikkein viimeisimpiä. Silti, tietoa ja taitoa on tarjolla ja melko edullisesti. Kun vain pääsisi niitä työssään heti käyttämään.
Kyllähän teoreettiseksi haukutut yliopisto-opinnot aikoinaan juuri keskittyivätkin tuohon ongelmanratkaisukykyyn ja innovatiiviseen ajattelutapaan. Välillä kävit rekrytointitilaisuuksissa, missä kysyivät että osaatko jotain SCS:ää tai XXT:tä tms. Jos et tunnustanut osaavasi, niin et muka ollut mitään. Työnantajat eivät lukkiutuneisuudessaan ymmärrä, että jos hallitsee taustaperiaatteet niin ei sillä väliä mitkä ovat vuoden hypekirjainlyhenteet. Kaikki on lopulta sitä samaa paskaa ja uudet "innovaatiot" melkoisia itsestäänselvyyksiä kun viitsii vähänkin paneutuu asiaan.
Näin juuri. Se on vain harmi, että ammattikorkeat haraavat juuri tuolla menneessä. KK:ssa jo pelkästään tutkimuksen takia on oltava kehityksen kärjessä ja vielä tutkimuksen kärjessä. Kehityksen kärki ei karkaa jos on pari vuotta poissa, mutta tutkimuksen kärki karkaa jo vuodessa.
(ootko aamuvirkku 05:48 vai yökyöpeli 05:48?)
Takana on useita sovelluskehittimiä ja ohjelmointikieliä sekä koneissa 7 erilaista tietokantaa.
Kysyin asiakkaalta, että millä tietokannalla järjestelmä halutaan toteuttaa: Oracle - OK, ennestään tuttu.
Entä millä ohjelmointikielellä järjestelmä halutaan toteuttaa?: ASP, ei ennestään tuttu. Vastasin että kyllä onnistuu.
Tutkailin siinä 4h asp-esimerkkejä ja manuaalia, ja löysin esimerkeistä bugit ennen niiden testaamista.
Järjestelmä kuvattiin ensin toimintoina objekteihin ja luotiin tietokantaan objektien mukaiset tietueet. Käyttöliittymän suunnitelmaa käytettiin sellaisenaan käyttöliittymänä ja sitten ohjelmoitiin sovelluksen logiikka ja raportit. Käyttöliittymä oli samaan aikaan loppukäyttäjien testattavana ilman logiikkaa. Kun testi päättyi, eikä suurempia muutoksia haluttu, niin käyttäjät pääsivät suoraan kokeilemaan alpha-versiota. Muutama muutos tietokantarakenteisiin ja laskentaosan kaavoihin ja sitten alkoi testaus, desimaalipilkkujen ja pisteiden hyväksyntä mukaan kenttien syötteisiin ja tuote asiakkaalle käyttöön. Loppuaika menikin dokumentaation puhtaaksikirjoituksessa ja aikaa meni 1hlöltä kaikkiaan 3kk - räätälöity järjestelmä käyttöön.
Toteuttaa voi millä vaan, jos tietää perustekniikat ja riittävän hyvin useita toisiaan vastaavia järjestelmiä sovelluskehityksessä.
"Tekniikka kehittyy huimaa vauhtia ja se mitä osaat nyt, on muutaman vuoden päästä museotavaraa."
Siis eihän tekniikka vanhene, jos puhutaan ihan oikeasta tekniikasta. Olio-ohjelmoinnin käytäntö on ollut samaa toistakymmentä vuotta. Arkkitehtuurien puolellakaan ei ihan joka vuosi mitään mullistavaa tapahdu.
Onkohan tässä nyt oireita siitä, että jossain kouluissa opetetaankin sovelluksia soveltamisen sijaan? Kun nuorelta koodarilta kysyy mitä on periytyminen saa vastaukseksi että se on Java-kielen ominaisuus. Oikea vastaus olisi tietysti ollut, että se on olio-ohjelmoinnin ominaisuus. Kun opiskelee 10 opintoviikkoa Javaa tulee "siinä sivussa" opiskelleeksi oliomenetelmät eikä päinvastoin. Tai sitten ei tule. Siis oikeastihan koulutuksen pitäisi olla sellaista, ettei ole hirveästi väliä onko kieli C :aa, Javaa, SmallTalkia tai jotain Nokian mopsivopsia. Jos sellaista koulutusta olisi, silloin myöskään osaaminen ei vanhenisi muutamassa vuodessa.
Opetettiinko teille siis koulussa Javaa vai olio-ohjelmointia?
ja kaveri pökäisi itse oman kokeellisen olio-ohjelmointikielen. Heitin läppää, että laitatko prosessit pinoon ja jokaiselle oma ikkuna, josta painikkeella voi sammuttaa ja käynnistää toisia prosesseja.
Hetki - kas näin! OK, mitä vaan voi näköjään tehdä.
Optimoin tuon kielen käskyt seuraavaksi assemblerille ja ajoimme sitten nopeustestit 4 muuhun C-kielellä toteutettuun variaatioon ja totesimme assembler-version ajavan nelinkertaisella nopeudella. Kaveri tuli kotiin asti tarkistamaan profiloimaan, etten puhunut puutaheinää ja uskottava se oli.
Menetelmän kun kerran oppii, niin se on enää syntaksista (leikkaa-liimaa) sitten kiinni.