13.10.2021

Ensimmäinen kuukauteni Druidilla – JavaScript-kehittäjän aatoksia

Ensimmäinen kuukauteni Druidilla on nyt takana päin. Uudessa paikassa aloitettua on luonnollista pohtia, miten työpaikka on vastannut omia odotuksia. Nyt onkin hyvä hetki hieman koota ajatuksia siitä, millaista työskentely Druidilla on, ja mitä on tullut opittua ensimmäisten viikkojen aikana.

Pitikö ensivaikutelma kutinsa?

Vierailin Druidin toimistolla Pasilassa ensimmäisen kerran tänä keväänä. Rento mutta jämpti toimitusjohtaja Mikko loi tervetulleen vaikutelman. Druidilla vaikutti olevan lähes olematon hierarkia, jossa työntekijät saivat äänensä kuuluviin. Näytti siltä, että työntekijöihin luotetaan ja heille annetaan suuresti sekä vapautta että vastuuta. Kokemus oli kaikin puolin positiivinen. Niinpä päädyinkin aloittamaan Druidilla syyskuussa JavaScript-kehittäjänä.

Voin hyvillä mielin todeta, että ensivaikutelmani piti paikkansa. Vapaus ja vastuu sekä luottamus työntekijää kohtaan ovat Druidin kulttuurin ytimessä. Talo on täynnä huippuluokan osaajia, jotka saavat keskittyä olennaiseen. Voin huoletta suositella Druidia näitä asioita arvostaville kehittäjille.

Mitä olen tähän mennessä oppinut?

Druid on maailmanluokan Drupal-talo ja nyt pitkän tähtäimen tavoitteena on saavuttaa sama asema JavaScriptin parissa. Toki druideilla on jo pitkä historia tämän varsin yleisen ohjelmointikielen käytössä, mutta nyt siihen halutaan panostaa entistä enemmän. Olenkin ensi töikseni päässyt kehittämään JavaScript-toimintaa Druidilla ja luomaan kestäviä lähtökohtia tulevaisuuden menestykselle.

Tähän mennessä olen oppinut uutta ainakin kolmesta eri teemasta: rekrytoinnista, myynnin tukemisesta ja sovellusten ylläpidosta. Tässä ajatuksiani niistä.

1. Strategia mielessä ja katse koodissa, kun rekrytoidaan

Olen päässyt vastuulliseen rooliin rekrytoimaan lisää JavaScript-osaajia taloon. Olen aiemminkin tehnyt hiukan rekrytointia, mutta vasta Druidilla tajusin pitäväni siitä. Se tuli ohjelmistokehittäjälle yllätyksenä.

Olen oppinut huomioimaan rekrytoinnissa yrityksen strategiset tavoitteet parhaiden kandidaattien löytämiseksi. Rekrytoinnissa järjestelmällinen hakijoiden arvioiminen yhdistyy laadulliseen arvioon hakijan sopivuudesta tehtävään. Vaikka haastateltava vaikuttaisi osaavalta tekijältä ja mieluisalta työkaverilta, on pystyttävä pitämään mielessä myös liiketoiminnan realiteetit ja toimittava sen asettamissa raameissa. Kielteisen päätöksen antaminen toiveikkaalle hakijalle ei tietenkään koskaan tunnu hyvältä, vaikka päätös olisikin liiketoiminnan kannalta hyvin perusteltu.

Ohjelmistokehittäjänä pystyn katsomaan hakijoiden osaamista ansioluetteloa syvemmälle: esimerkiksi kehittäjien harrasteprojektit ja tekniset haastattelut tuovat tärkeän näkökulman arviointiin. Rekrytointiprosessissa kannattaakin hyödyntää ohjelmistokehittäjien ammattitaitoa. Vaikka hakijalla olisi vaatimaton työhistoria, voi timanttinen harrasteportfolio korvata lyhyen ansioluettelon enemmän kuin hyvin. Koodikatselmoinnin avulla voidaan joskus saada hakijan osaamisesta jopa parempi kuva kuin työhistorian perusteella.

2. Teknologisten valintojen on tuettava tehokkuutta

Toinen teema liittyy yrityksen käyttämien teknologioiden valintaan ja myynnin tukena toimimiseen. Oikean teknologian valinta asiakkaan ongelman ratkaisemiseen ei ole yksinkertainen asia. Yksi tapa toteuttaa asiakkaan toimeksianto voi joskus olla objektiivisesti parempi kuin toinen, mutta usein merkittäviä eroja valintojen välillä voi olla vaikea löytää. Sama toiminnallisuus voidaan toteuttaa yhtä hyvin usealla eri teknologialla. Tällöin ratkaisun tueksi nousevat esiin muut asiat, kuten organisaatiosta löytyvä osaaminen ja ylläpidon merkitys.

Asiakkaalle käytetty teknologia ei useinkaan ole prioriteettilistan kärjessä, vaan tärkeintä on halutun tuotteen toteuttaminen toimivalla ja tehokkaalla tavalla. Tehokkuutta lisää keskittyminen organisaation ydinosaamiseen sen sijaan, että valitaan jokaiseen asiakkuuteen eri välineet. Myös projektien ylläpidon kannalta keskittyminen pieneen määrään teknologioita on äärimmäisen tärkeää. Tästä hyötyy yhtä lailla asiakas kuin toteuttajakin. Myyntiä tukevan koodarin on tehtävä sellaisia teknologisia valintoja, jotka tuottavat parhaan lopputuloksen kokonaisuuden kannalta.

3. Kattava testaus helpottaa ylläpitoa

Kolmanneksi teemaksi ensimmäisen kuukauteni aikana nousi ylläpito. Verkkopalveluiden ja -sovellusten ylläpito tuo yrityksen toimintaan aivan erilaisia haasteita kuin uudet toteutusprojektit. Ylläpito ja uusien projektien kehittäminen ovat vahvasti riippuvaisia toisistaan. Jos ylläpitoa ei huomioida jo projektien aloitusvaiheessa, voi lopputuloksena olla hankalasti hallittava sekasorto useita erilaisia ylläpidettäviä projekteja, jotka vaativat paljon organisaation resursseja. Automaatiolla ja yhtenäisillä teknologioilla voidaan saada kaaos kuriin. Riippuvuuksien päivityksiä voi automatisoida esimerkiksi Renovaten avulla.

Riippuvuuksien päivittäminen ei kuitenkaan aina mene nappia painamalla. Erityisesti JavaScript-maailmassa on tyypillistä, että projekteissa käytetään useita ulkopuolisia paketteja, jotka puolestaan koostuvat useista paketeista omine riippuvuuksineen. Joskus kaikkien pakettien yhdenaikainen päivittäminen rikkoo sovelluksen toiminnallisuuden, sillä päivitetyt paketit eivät välttämättä toimi yhdessä. Ylläpidossa joudutaan miettimään vaikeita kysymyksiä, kuten ovatko kaikki päivitykset tarpeellisia, ja mistä löytää aikaa mahdollisten ongelmien ratkaisulle.

Kattavasta testauksesta voidaan saada paljon apua näihin ongelmiin. Sovelluksen toiminnan tarkistaminen manuaalisesti päivitysten jälkeen vie paljon aikaa. Kattavat testit tuovat varmuutta sovelluksen päivittämiseen ja jatkokehittämiseen. Silti myös testauksessa on pidettävä järki päässä. Oma linjani on ollut just enough software testing, eli keskittyminen ydintoiminnallisuuksien ja suurimpien riskien testaamiseen. Ylläpidon ja päivitettävyyden kannalta saattaa olla aiheellista harkita tuon filosofian muuttamista entistä kattavampaan testaukseen.

Haluaisitko sinäkin liittyä joukkoomme?