Mikä ihme saa tykkäämään koodaamisesta vielä 17 vuoden jälkeen? – Näin ohjelmistoarkkitehti vastaa

Ohjelmistoarkkitehti Marko Pukari näyttää iaidon, japanilaisen miekkailulajin, perusliikkeitä. Hän kilpailee lajin Suomen maajoukkueessa.   

 

Meillä Compilessa kehittäjillä on kokemusta alalta vähintään vuosikymmenen verran.

Se on pitkä rupeama.

Luulisi, että siinä ajassa ehtii kyllästyä moneen kertaan.

Mistä ihmeestä senioritasoiset kehittäjät löytävät palon tekemiseen yhä uudelleen?

Kysytäänpä tammikuussa aloittaneelta järjestelmäarkkitehti Marko Pukarilta.

 

Marko, olet koodannut 17 vuotta. Mikä tässä työssä innostaa vieläkin?

”Uuden oppiminen ja se, kun saa oman tiimin tai asiakkaan oppimaan uutta.

Kerron esimerkin. 

Jokunen vuosi sitten olin mukana projektissa, jossa otettiin käyttöön Javan versio 8.

Sen sisään rakennettu Stream API toi dramaattisen muutoksen aiempaan verrattuna:

kun vanha tapa käsitellä listoja tuotti vaikeaselkoista koodia jonka lukeminen oli hidasta, uusi API teki koodista nopeasti silmäiltävää ja muutosten testaamisesta helpompaa.

Sattumalta olin edellisessä projektissa koodannut sovellusta Streamia hyödyntäen, joten ymmärsin sen arvon. 

Mutta tiimin toinen koodari, joka oli minua selvästi kokeneempi, halusi edelleen käsitellä listat tavalla, joka oli tuttu jo Javan versiosta 1.5. 

Kerroin hänelle, miksi työ kannattaisi jatkossa tehdä uudella APIlla. 

Puhuin siitä, miten työlään alun jälkeen se säästäisi aikaa ja helpottaisi työtämme pitkällä tähtäimellä. 

Lopulta koodari suostui kokeilemaan uutta tapaa, vaikkakin pitkin hampain.

Niin aloimme työt.

Mutta seuraavien viikkojen ajan sain kuulla jokaisen koodikatselmoinnin jälkeen, miten hän olisi tehnyt kaiken vanhalla tavalla jo moneen kertaan.

En halunnut antaa periksi, joten tsemppasin ja sparrasin kollegaani jatkamaan.

Sen täytyi olla hänestä todella ärsyttävää 🙂 

Viimein, noin kuukauden kannustamisen jälkeen, koodari oli nähnyt omakohtaisesti helppolukuisuuden hyödyt ja oivaltanut uuden APIn paremmuuden käytännössä.

Eräänä aamuna kun olin ottamassa kahvia, kollegani tuli automaatille ja kiitti minua siitä, että olin jaksanut potkia häntä eteenpäin.

Siitä tuli hyvä mieli. 

Olin iloinen, että kollegani oppi uuden taidon ja ajattelutavan.

Itse opin sen, ettei muutosta voi runnoa läpi, vaan toisille täytyy antaa aikaa kokea itse muutoksen tuomat hyvät puolet.”

 

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.