Kuidas ühe programmeerija tööpäev möödub? Kas mõnusam on ühe püsiva toote ehitamine või tihti projektide vahetamine? Rääkisime selleks LeapINi Java arendaja Egon Naaritsaga.
Milline üks tüüpiline Java arendaja tööpäev välja näeb?
Enamasti algab minu tööpäev hommikul 9 paiku kontorisse jõudmisega. Võimalik oleks tööd teha ka kodukontorist, aga ise eelistan kontoris töötamist, kuna meil on loodud töötamiseks palju paremad tingimused, kui mul kodus oleks võimalik saavutada.
Vaatan üle, mis infot Slackis või e-posti teel on vahetatud ja kas seal on minule mingeid olulisi teateid, seejärel vaatan üle oma pooleliolevate tööülesannete seisu.
Tööülesanded, mis on mulle määratud või mille ma olen ise endale vabade tööde hulgast valinud, võivad olla arendusprotsessi jooksul mitmes staatuses. Kõigepealt on pooleliolev töö tegemisel, seejärel koodi ülevaatusel, seejärel testimises ja alles pärast testi saab töö arendaja jaoks valmis.
Minu jaoks on prioriteetsemad need tegevused, millede puhul ma saan töö ühest staatusest teise tõsta. Näiteks kui töö on koodiülevaatusel ja keegi on minu koodi kohta teinud parendusettepanekuid, siis ma vaatan hommikul kõigepealt need üle, teen vajalikud parandused ära, et ülevaataja saaks muudatused aktsepteerida ja testimisse suunata.
Samuti on prioriteetsed need tööd, kus minu arendatud lahendus on testimises ja sealt on leitud mingeid vigu või kui sinna on vaja mingeid täiendusi teha. Siis ma parandan esimesel võimalusel koodi ära ja suunan uuesti testijale tagasi.
Nende asjadega tegelen esmajärjekorras, et arendustsükkel minu taha kinni ei jääks.
Kui pooleliolevate asjadega on kõik korras, siis enamasti jätkan oma tööülesande arendamist sealt, kus ma eelmine päev pooleli jäin. Vahel on eelmine päev üles jäänud küsimusi analüütikule, vahel arhitektile ja vahel ka meie enda majas olevatele lõppkasutajatele. Üritan esimesel võimalusel nendega suhelda. Teinekord alustan hoopis eelmine päev üles jäänud keerulisest tehnilisest probleemist, millele üritan lahendust leida kolleegidega suheldes, internetist infot otsides või aitab hommikul lihtsalt värske pea piisavalt kontsentreeruda.
Ükski arendaja tööpäev pole päris samasugune nagu eelmine. Iga päev toob mingeid uusi ülesandeid, tehnilisi probleeme, mis tihti tähendavad teadmiste täiendamist ja õppimist. See hoiab mõistuse erksana ja töö rutiinivaba.
Mis vahe sellel on, kui arendad ühte suurt teenust või toodet võrreldes üksikute lühikeste projektidega?
Enne LeapINi ei olnud ma üheski startupis töötanud, pigem olin töötanud suuremates korporatsioonides. Alguses kartsin, et äkki on startupis protsessid paika loksumata, segadust ja stressi rohkem ja kood ajasurve tõttu ebakvaliteetne, aga LeapIN on tõestanud mulle, et kõik võib olla hoopis vastupidi.
LeapINis nägin, et kui õiged inimesed on asju algusest peale korralikult ja südamega teinud, siis võib olla oma toote kood ilusti kommenteeritud, ühtlase stiiliga ning kvaliteetne. Seda on aidanud siin tagada nii wikis olevad kodeerimise stiilijuhendid, koodiülevaatused kui ka koodi analüsaatorite kasutamine.
Samuti on siin väga hästi paika loksunud arendusprotsess, mis meie suurusega ettevõttesse hetkel väga hästi sobib. On loodud töökeskkond ja antud just õiged töövahendid, stressitase on madalam kui mu varasemates töökohtades, sest meil on mõistlik juhtimine ning tööde planeerimine ja puudub väline ajasurve. Saame ise otsustada, mis on hetkel oluline arendusmeeskonna jaoks ja millesse on vaja panustada.
Enamasti on tööd jaotatud väiksemateks tööülesanneteks, mille töömahtu on võimalik hoomata ja enam vähem ennustada, millal töö valmis võiks saada. Samas on meil ka pidevalt töös suuremaid tükke, mille arendus võtab aega mitmeid kuid. Need on nagu väikesed alamprojektid, mis on teemade kaupa jagunenud erinevate arendajate vahel.
Mis sellist tüüpi arendamistöö plussid ja miinused on?
Meie saame ise otsustada, mis järjekorras me lahendusi ehitame, mis tehnoloogiat me kasutame, millal me raamistikke uuendame, kuidas erinevaid tarkvara tükke üles ehitame ja arendust läbi viime. Saame kasutada kaasaegseid tehnoloogiaid ja vahendeid. Tulemuseks on efektiivsem töökeskkond, kus arendaja suudab luua rohkem lisaväärtust ja omab ka suuremat isiklikku arenguperspektiivi.
Kui vaadata võrdlusena alltöövõtu korras suurkorporatsioonidele tehtavaid projekte, siis seal on tihti vaja anda täpseid ajahinnanguid, et töötunde õigesti tasustada. Aga seda on väga raske täpselt teha, kuna töö käigus võib tekkida ootamatuid probleeme. Kuna selliseid projekte võidetakse hangete puhul enamasti vähempakkumiste teel, siis tekitab see pideva surve – aeg ja eelarve on peaaegu alati piiratud. Tihti tuleb koodi kirjutades millegi osas järeleandmiseid teha, kuigi ükski arendaja seda väga teha ei tahaks. Lisaaega kulub kliendile igasuguste raportite koostamisele. Kõik need asjad tekitavadki rohkem stressi.
Oma toodet arendades enamik neid probleeme puudub ja saab täielikult keskenduda rakenduste ehitamisele ja parema koodi kirjutamisele. Kuna sa näed lähedalt kogu ettevõtte arengut ja saad aru suurest pildist, siis tekib ka tootega suurem side ja omanikutunne – sina oled kogu protsessi oluline osa.
Ka projektipõhistes tarkvaraettevõtetes on omad plussid, aga hetkel meeldib mulle startupis olev õhkkond, vähene bürokraatia ja oma platvormi arendus. Tunnen, et olen saanud siin teha kvaliteetsemat tööd ja isiklikult palju areneda. Olen aru saanud, et startupis töötamist pole vaja karta, ja selle meeskonnaga liitumine on olnud minu karjääris üks parimaid otsuseid.
