.net-osaaja testaa koodinsa jo ennen kuin kirjoittaa sen – ”Työssäni kaikkein tärkein asia on laatu”

Jani Koskela on vuoden vaihteessa Compilessa aloittanut software specialist, jolla on 13 vuoden kokemus alalta. 

Jani, miten päädyit Compilelle?

”Aiemmin tein inhousekehitystä. Kiinnostuin Compilesta, koska täällä halutaan tehdä laatua ja ollaan suoria asiakkaan suuntaan. Itselleni laatu on kaikkein tärkein asia omassa työssäni.”

Sinulla on erikoinen tapa koodata. Kerro siitä.

”Aloitin urani testaajana. Se on muokannut tapaani kirjoittaa koodia. Yleensä devaajat testaavat koodinsa jälkikäteen. Itse kirjoitan ensin testin – eli mitä koodin pitäisi palauttaa – ja vasta sen jälkeen varsinaisen softakoodin. Metodia kutsutaan nimellä TDD, ”test-driven development”. Minulle se on tapa varmistua laadusta. Uskon, että varsinkin monimutkaisemmissa projekteissa tämä lähestymistapa säästää aikaa. Kirjoittamani testi myös dokumentoi, miten softakoodi toimii.”

Teet backend-kehitystä nimenomaan .netillä. Miksi se eikä Java?

”Olen tykännyt .netistä urani alkuvuosista lähtien. Nimittäin testaajana katsoin sivusta, millaisia muistinhallinnan haasteita silloinen Java aiheutti. Kun tutustuin .netiin, vastaavia ongelmia ei silmiini osunut. Java on varmasti kehittynyt vuosikymmenessä, mutta .net tuntuu omalta ja siksi haluan syventää osaamistani siinä.”

Onko viime vuosilta jäänyt jokin projekti mieleen?

”Muistan erään hankkeen, jossa asiakas halusi Microsoftin lisenssikuluista eroon. Samalla kun kehitimme tiimin devaajien kanssa tuotteeseen uusia ominaisuuksia, muokkasimme muutaman kuukauden aikana koodia niin ettei siinä enää ollut riippuvuuksia Windows-alustaan. Oli magee hetki kun .net-sovellus saatiin pyörimään Linuxilla ja asiakas saattoi lopettaa lisenssien maksamisen.”

Seuraa meitä Linkedinissä niin tiedät aina, mitkä ovat ohjelmistokehityksen toimivimmat käytännöt juuri nyt.

Tuntuuko, että...

 …teidän softakehitystiimissä sekä palautteen antaminen että vastaanottaminen on vaikeaa?

Tilaa ilmainen miniopas tilanteen ratkaisemiseksi tästä:

    Kun tilaat oppaan, liityt samalla uutiskirjeemme tilaajaksi, ja saat lisää inhimillisen johtamisen vinkkejä. Voit poistua listalta koska vain.

    eNPS-mittaus perustuu Fred Reichheldin kehittämään Net Promoter Score -mittariin, jolla alunperin tutkittiin yritysten asiakaskokemusta ja asiakastyytyväisyyttä. Myöhemmin sitä on alettu käyttää myös työntekijätyytyväisyyden tutkimiseen (e niin kuin employee + NPS).

    Näin mittaus tehdään.

    Kysymme työntekijöiltämme kerran kertaa vuodessa, että “kuinka todennäköisesti suosittelisit työpaikkaasi ystäville tai tutuille asteikolla 0-10?”. Sen jälkeen pyydämme tarkennusta avoimella kysymyksellä: ”mistä syystä annoit tämän tuloksen?”.

    Niitä, jotka antavat luvuksi 9 tai 10, kutsutaan suosittelijoiksi. Niitä, jotka antavat luvuksi 0-6, kutsutaan kriitikoiksi.

    eNPS-tulos lasketaan vähentämällä suosittelijoiden suhteellisesta prosenttiosuudesta kriitikoiden suhteellinen prosenttiosuus. Muut vastaukset saavat arvon 0.

    Mittarin tulokset voivat olla mitä vain -100 ja +100 väliltä. Yli nollan nousevat tulokset ovat tyydyttäviä. +10 ja +30 välillä olevia tuloksia pidetään hyvänä, ja yli +50 olevia tuloksia pidetään erinomaisena.