Työpaikkana Bitcomp – Koodarin uran ensimmäiset 12 vuotta
– Eikös tuollaiset kirjoita yleensä se ensimmäistä viikkoa töissä oleva harjoittelija, jolle totuus moderneista tietotöistä ja ohjelmistoista ei ole vielä paljastunut?
– Siksi tästä tuleekin syväluotaavampi, kun saadaan tuollainen 12 vuoden aikaperspektiivi tähän hommaan.
Uran alku
Jo opiskeluaikana törmäsin yliopiston kanssa tehtyyn projektiin, jossa tehtiin karttasovellusta Nokian kommunikaattorille. Tämä oli vaikuttavaa, sillä vuosituhannen alussa ei ollut Googlen tai vastaavien julkisia karttapalveluita. Lähimmäksi vastaavaa päästiin navigaattoreilla, mutta toisin kuin kännykät, ne eivät olleet aina mukana, kartta-aineisto ladattiin niille etukäteen, eikä niiden päälle voinut tehdä omia sovelluksia.
Firman nimi ei vielä tuolloin ollut Bitcomp ja projektin johtopäätös taisi olla, että tekniikka ei ollut vielä tarkoitukseen valmis, mutta mukana olleet henkilöt ja edistynyt ratkaisu jäivät mieleen.
Opiskelujeni loppuvaiheilla aloin sitten katselemaan työnantajia. Bitcompilla oli heti positiivinen ensivaikutelma puolellaan. Lisäksi yritys teki (ja tekee yhä) sovelluksia luonnonvara-alalle. Omat juureni kun ovat maaseudulla, innostuin ajatuksesta tehdä sovelluksia, jotka hyödyttävät ihmisiä kotikonnuillani. Enää vanhalla kotipaikallani ei ole maatiloja ja Bitcompkin on laajentanut toimialaa enemmän metsäpuolelle. Metsätalouden merkitys nousee kuitenkin jatkuvasti niin taloudellisesti kuin ilmastollisestikin, joten en ole katunut työpaikkavalintaani. Myös hyvillä kollegoilla on ehdottomasti ollut merkitystä työpaikassa viihtymisen kannalta.
Koodarin työ
Bitcompilla aloittaessani yritys oli huomattavasti nykyistä pienempi. Olenkin päässyt tekemään vuosien aikana kaikenlaista ja useammassa erilaisessa roolissa. Haastekerroin on vaihdellut paljon ja erilaisille toimijoille tehtävien järjestelmien erot ovat tulleet tutuksi.
Reilun vuosikymmenen aikana on tullut omaksutuksi myös laaja setti erilaisia ohjelmoinnin, versionhallinnan ja jatkuvan julkaisun työkaluja. Juuri tällä hetkellä toimin scrum masterina erään toiminnanohjausjärjestelmän ylläpito- ja kehitystiimissä ja nautiskelen pilvisiirtymän haasteista.
Laajat toiminnanohjausjärjestelmät kun eivät muutu pilvinatiiviksi vahingossa. Ajattelemattomasti tehtynä siirtymä voi lisätä ylläpitokustannuksia. Siirtymää kuitenkin kannattaa suosia niin käyttäjänä kuin kehittäjänä, koska parhaimmillaan se tekee työstä juuri sellaista, mitä sovelluskehityksen mielestäni tulisi olla. Taustapalikoiden ollessa paikoillaan tekeminen muuttuu vuokaaviomaiseksi hyväksi havaittujen mallien ja komponenttien yhdistelyksi liiketoiminnan tarpeisiin. Pidän kovasti myös siitä, että vuosien myötä tietoturvan on huomattu ja asiakkaatkin osaavat sitä jo vaatia. Nykyään sen nimissä ei pelkästään saa vaan myös tulee tehdä säätöä ja iterointia.
Ohjelmointi ja valinnat – tiukka kontrolli vs helppokäyttöisyys
Tein opiskeluaikoina samaan aikaan yhtä harjoitustyötä SDL-kielellä ja toista Symbianilla. Ero tekemisessä oli valtava.
Molemmissa tehtävissä tehtiin valintoja ja laskettiin tuloksia annettujen parametrien perusteella – tämä malli vastaa sitä, mitä teen nykyään palveluihin palvelinpuolelle. Molemmat käänsivät hyvin suorituskykyisen lopputuloksen, joka olisi tarvittaessa ollut käytettävissä muissa projekteissani.
Kuitenkin siinä, missä toinen työkalu generoi koodit piirtämäni kaavion mukaan, toista kääntäessäni jouduin aina toistamaan puolenkymmentä kasausaskelta ja ottamaan tarpeettomasti kantaa muistinhallintaan ja muihin alhaisen tason asioihin.
Uskon, että mitä suurempaa kokonaisuutta olisi lähdetty tekemään, sitä varmemmin kuvauksestani generoitu koodi olisi ohittanut laadussa tekstieditorilla tekemäni. Kaavioilla olisi ollut ehdottomasti rajoitteensa, mutta tämäkin olisi vain ohjannut tekemään rajattuja ja modulaarisia komponentteja. En tutustunut generaattoriin syvällisesti, mutta oletan että monet kielen mahdollistamat virheet oli huomioitu generaattorin puolella. Näin varmistettaisiin, että esimerkiksi generoidulle ohjelmointikielelle tyypillisiä puskurien ylivuotoja ei pääse tapahtumaan.
Eipä jäänyt epäselväksi, kummalla työkalulla työskentelisin mieluummin.
Kun sitten kuuntelin tutkimusapulaisena professorien ohjelmointipyyntöjä, ajattelin että heidän kuvaamansa pyynnöt voisi teetättää heidän oman alansa opiskelijoilla, jos heillä olisi hyvät työkalut. Nyt on kulunut 15 vuotta eikä maailma ole täysin saavuttanut tuota visiota, mutta vähäkoodisuus ja GraphQL tekevät tästä vuosikymmenestä ainakin meille kehittäjille miellyttävän.
Kenestä on koodariksi?
Uskon, että vuorovaikutustaidot ovat aina olleet keskeisiä hyvin edenneissä projekteissa. Tämä asia on kyllä entisestään korostunut jo minunkin näkemänäni aikana. Toisilla mantereilla olevat kollegat ja asiakkaat, ketterät menetelmät, pilvi sekä alhaisen tason koodauksen vähentyminen nostavat niiden haasteiden tasoa, joita yleensäkään pystymme ratkaisemaan. Ongelman avaaminen toimivaksi ratkaisuksi vaatii molemmilta osapuolilta kykyä keskustella sekä liiketoiminnan että tekniikan haasteista vapautuneesti. Varsinkin paineiden noustessa pitää edelleen pystyä puhumaan ja etenemään järkevästi.
Koodariksi haluavan ihmistyyppi ei mielestäni ole ratkaisevaa, itsetuntemus on. IT-alalla ja sovelluskehityksessä on kyllä töitä kaikenlaisille ihmisille, niin introverteille kuin ekstroverteille ja niin koneista pitäville kuin niitä epäilevillekin. Sopivan roolin löytäminen on sitten työntekijän itsensä ja esimiesten yhteinen tehtävä.
Tietynlainen nöyryys on kuitenkin alalla tärkeää, sillä kaikkiin tehtäviin ei toki voi päästä ilman riittävää näyttöä kokonaisuuden ymmärtämisestä. Lisäksi on paha virhe sivuuttaa kollegoiden osaaminen oman pätemisen tarpeen takia. Esimerkiksi käytettyihin pilvialustoihin tulee satoja ominaisuuksia vuodessa ja kaikkien niiden sisäistäminen on lähestulkoon mahdotonta käyttöönottoon erikoistuville konsulteillekin.
Työpaikan valinta
Olen työskennellyt isossa yrityksessä ja pienessä yrityksessä ja huomannut pitäväni pienemmistä työnantajista. Jotenkin minulle on jäänyt käsitys, että laajassa organisaatiossa koulutukseni olisi pakottanut minut erikoistumaan johonkin työkaluun tai tekniseen haasteeseen, jota olisin sitten tehnyt vaihtuville hankkeille ja asiakkaille maailman tappiin asti. En usko, että näkymättömän taustatoiminnon ylläpito tai yksittäisen tulosteen toimittaminen projektin versionhallintaan antaisi samanlaista onnistumisen tunnetta kuin isomman kokonaisuuden julkaisu ja käytössä näkeminen. Tekniikka ei ole minulle itseisarvo vaan tärkeää on se, mitä toteutuksella saadaan aikaan.
Aloitin opiskeluni tietoliikennepuolella, mutta suuntautumiseni siirtyi ohjelmistoihin huomatessani arvostavani softaa enemmän kuin kaistanleveyttä ja optimisignaalia. Tekniikan rajoitteita pystyy kiertämään sovelluskerroksella, mutta yksin prosessoritehoilla tai sukupolven x tietoliikenneverkolla ei maailmaa pelasteta. Osallistuin yliopistolla hankkeeseen, jossa tehtiin ensimmäisiä versioita monien tuntemasta opetuspelistä nimeltä Ekapeli. Siinä ei todennäköisesti ole enää riviäkään minun koodiani, mutta tieto, että osallistuin johonkin tuollaiseen, lämmittää minua edelleen enemmän kuin pöydälläni makaava viikon vanha tehokannettava.
Työskentely Bitcompilla
Päivät Bitcompilla ovat joskus venyneet pitkiksi, mutta elämääni on mahtunut koko työsuhteen ajan myös muuta. Aikanaan aktiiviseen pyöräilyharrastukseen löytyi kavereita firmasta, ylimääräiset vapaat Keski-Euroopan pyöräsafarille järjestyivät ja paluumuutto kotiseudulle ei vaatinut mitään muuta kuin avaimen toiselle toimistolle.
Olen tässä viimeisen tusinan vuoden aikana mm. ostanut asunnon, mennyt naimisiin, saanut kolme lasta, remontoinut lukemattomia tunteja ja jopa perustanut oman osakeyhtiönkin liiketoimintaa ja asiakkaita ymmärtääkseni. Viimeisestä on toki hyötyä Bitcompillekin, mutta kaiken kaikkiaan työnantaja on jättänyt tilaa omalle kasvulle ja tukenut niin elämän myötä- kuin vastamäessä, jo 12 vuoden ajan.
