Jyvät akanoista: mistä tunnistaa taitavan devaajan?
Viime aikoina on ollut puhetta koodaripulasta ja siitä, miten erityisesti taitavista koodareista on kova kysyntä. Vielä tiukemmin kiven alla ovat taitavat koodarit, joilla on koodin kirjoittamisen lisäksi silmää myös bisnesnäkökulmille.
Bisneksen ja miksei myös yleissivistyksen näkökulmasta on kiinnostavaa pohtia, mikä tekee devaajasta taitavan. Läheskään ainahan devaamista tarvitseva liiketoimintajohtaja ei erota laadukasta koodia harakanvarpaista. Jos sitten jälki on harakanvarpaita ja niitä pitää lopulta kirjoittaa alusta uudelleen (tai parsia hitaasti ja kiroillen), se maksaa paljon enemmän kuin homman tekeminen kerralla kunnolla. Viimeistään tämän pitäisi tehdä hyvän devaajan tunnistamisesta kiinnostavaa muillekin kuin toisille devaajille.
Eli: miten koodaa ’taitava devaaja’? Kysyin Rakettitieteilijöiltä, mitä he arvostavat kollegassa. Saamani kommentit niputin kolmeen ryhmään: Itse koodin laatuun, kokonaisvaltaiseen suunnitteluun sekä yhteistyökykyyn. (Niputus on omani, ja sitä saa haastaa!)
Koodin laatu
Itse arvostan siistiä ja ylläpidettävää koodia, jossa ei kikkailla turhan paljon, mutta ei myöskään tehdä asioita erityisen tyhmästi.
Jos softa on tehty ylläpidettäväksi, hyvin tehtyyn palaa itsekin mielellään siihen verrattuna, että se olisi "nyt vain nopeasti valmiiksi jotain" -tyylisesti kasattu, jolloin paluu koodia tunkkaamaan lähinnä nyppii.
Ehkä ’rivikoodarilla’ tarkoitetaan tyyppiä, joka ei niin pohdi isoa kuvaa, kunhan tekee kohtuullista jälkeä ja palkka juoksee 8-16. Ja sekin voi olla joskus ihan ok.
Suunnittelu ja kokonaisuuden hahmotus
Design (eli miten softa on rakennettu, mitä abstraktioita on tehty ja miksi) on iso juttu, mutta sitä kannattaa ehkä hakea vasta kokeneilta tyypeiltä. Design on aika hyvä erottava tekijä rivikoodarin ja kokeneemman välillä.
Designin evaluointi on myös käytännön elämässä melko hankalaa, ainakin järjestelmissä jotka eivät ole mitään MVP:itä enää, vaan ovat törmänneet oikeaan maailmaan useamman vuoden. Ulkopuolisena on vaikea sanoa, onko jokin ratkaisu hyvä, koska voi olla ihan järkevät syyt miksi jokin on miten on, vaikka olisi hieman epäelegantimpi koodausratkaisu.
Kova tekijä on se joka ymmärtää, milloin projektinjohdon järjettömät ohjeet kannattaa heittää roskiin, mutta onnistuu silti tuottamaan systeemin, johon asiakas on tyytyväinen. Jälkikäteenhän kukaan ei muista vaatimuksista tuon taivaallista. Vrt. monesti kuultu kommentti ’ei tämän pidä olla hyvä, nyt vaan nopeasti jotain kasaan’.
Koodaamisen tasoa voi lähestyä myös eri aikamääreillä. Jos tarkoitus on tuottaa arvoa nopeasti tai toisaalta pitkäjänteisesti, keinot ovat monesti erilaisia. Vanhempana pidän enemmän jälkimmäisestä, mutta maailma tuntuu menevän tuon ensiksi mainitun kyydissä.
Pitkäjänteisyys tulee vastaan aika nopeasti; minun kokemukseni on, että nopeasti kasaan heitetty viritelmä kostautuu jo muutamassa päivässä tai viimeistään viikoissa.
Kommunikointi ja yhteistyö
Kommentoimaton koodi rautaohjelmoinnissa on iso punainen huutomerkki minulle, vaikka olisi kuinka siistiä.
Siinäkin on aika iso ero, onko koodi yhden henkilön show, vai onko sitä ylläpitämässä useampi eri henkilö. Erityisesti silloin pitää ottaa huomioon erot eri tekijöiden taidoissa ja kokemuksessa; muuten kaikki hienot kikkailut ja template-magiikka saattavatkin ampua omaan jalkaan hyvin nopeasti.
Itse yritän pitää riman omassa koodissa siinä, ettei minulle tarvitse soittaa perään ylläpitämään koodia sen jälkeen, kun olen projektista poistunut.
Kuten eräs Rakettitieteilijä huomautti, tavallaan yllä mainittujen kolmen ryhmän yläpuolella on vielä ”konteksti”: Kukaan ei ole niin erinomainen, että tuottaa huippupalkan arvoista työtä ihan vain omaa nerouttaan, vaan asia vaatii sen että huippuosaamiselle on aito tarve ja mahdollisuus. Joskus se voi tarkoittaa vaikkapa sitä että ”rividevaajat” hoitavat hitaampia ja tylsempiä juttuja pois alta, kun juhlittu sankari käy vetämässä isolla siveltimellä.
Tasokas koodaaminen ei oikeastaan paljon poikkea vaikkapa instrumenttien soittamisesta tai jalkapallon peluusta: Jotta pystyisi varsinaiseen taituruuteen (muutenkin kuin satunnaisesti ja tuurilla), pohjalla täytyy olla reilusti aivan perusasioiden hinkkaamista ja käytännön toteuttamista sekä yksin että joukkueessa. Sille pohjalle voi sitten rakentaa hienouksiakin. Tjaa. Ehkä taitava koodari on yksinkertaisesti se, joka on koodannut 10 000 tuntia?Ja lopuksi – koska olen itse kirjoittanut lähinnä aanelosille enkä komentoriville, vertaan huvikseni yllä kuvattuja pointteja kirjoittamiseen:
”Koodin laatu”: Jos ei osaa kieltä ja tunne kielioppisääntöjä, on vaikea kirjoittaa laadukasta tekstiä. Check.
”Suunnittelu ja kokonaisuuden hahmotus”: Kirjoittajakin joutuu aina miettimään, kenelle ja miksi kirjoittaa, miten teksti strukturoidaan loogiseksi ja helposti luettavaksi, kuinka pitkäikäinen teksti tulee olemaan, ja milloin ehkä joltain toiselta saatu speksi kannattaa ajatella kokonaan uudestaan. Check.
”Kommunikointi ja yhteistyö": Tekstitkin vaativat joskus sivuhuomautuksia ja selvennyksiä, tai vaikkapa linkkejä lähteisiin. Jos tekstiä tuotetaan yhdessä toisten kanssa, sillä on vaikutusta termistöön, tyylilajiin, näkökulmaan, jne. Check.