Per 16 darbo metų IT srityje, kai užrašiau tūkstančius kodo eilučių ir dirbau kartu su nemažai kitų programuotojų, pastebėjau, kad geras programuotojas yra tas, kuris turi tam tikrus geram programuotojui būdingus mąstymo bruožus ir kelis veikiančias darbo vertybes/principus, kurie neapsiriboja tik kodo rašymu.
Džiugu, kad šiais principais vadovaujuosi ne tik aš vienas, bet ir mano kolegos „Tendsign” komandoje. Taip užtikriname gerą darbinę atmosferą ir gebame kurti milžinišką pridėtinę vertę klientui. Mūsų projektas – viešųjų pirkimų sistema, todėl klientai turi daug atsakomybės, nes dirba su didelėmis pinigų sumomis, kur operacijose labai svarbų vaidmenį atlieka laikas minutėmis ar net sekundėmis. Dėl to, sistemos klaidos gali kainuoti labai daug.
Bet apie viską nuo pradžių. Kokie yra gero programuotojo bruožai ir darbo principai?
ENGINEER keeps evolving and perfecting tech competence
Tai pirmasis principas, apie kurį pakalbėsime. Juo vadovaujasi ne tik mūsų, bet ir visos likusios twoday komandos. Kiekviename projekte turime galimybę dirbti su naujausiomis technologijomis.
Niekas nesiginčija, kad programavimas – žingeidžių žmonių reikalas ir kad kompetentinga komanda garantuoja bent pusę geros darbinės atmosferos. Juk nėra geresnio jausmo, už nuolatinį tobulėjimą, kuriam daug įtakos turi ir mus supanti aplinka.
Iš patirties galiu teigti, kad kompetencijos kėlimas greičiausiai vyksta tada, kai ne tik pats domiesi, bet ir turi su kuo aptarti savo pamatytą bei išgirstą informaciją. O dar greičiau, kai tokie pokalbiai vyksta nuolat, t.y. rengiami įvairūs specializuoti hub’ai ar tech pokalbių sesijos su komanda.
Tačiau aklas noras išbandyti viską, kas naujo, gali pakišti koją. Ne tik pradedantieji programuotojai, bet kartais ir seni vilkai įsivelia į troškimą išbandyti vis daugiau naujų technologijų ar programavimo kalbos subtilybių, nepaisydami poreikio ar aplinkybių. Tai priveda prie to, kad pradedama galvoti, jog svarbiausia darbe yra kuo greičiau ir moderniau atlikti užduotį ir kuriamas klaidingas įsitikinimas, kad panaudojus kuo daugiau funkcijų ir „kietų“ bibliotekų tapsi geresniu specialistu. Tame yra tiesos, bet svarbu suprasti, kad tik to negana.
ENGINEERS always voice their opinions
Dar vienas principas būdingas geriems programuotojams. Šį principą drąsiai jungiame prie pirmojo, nes tik geroje komandoje vyksta konstruktyvi diskusija apie naudojamas technologijas, projekto ateitį ir vystymą.
Laikas gali būti iššvaistomas, jei programuotojas tiesiog aklai vadovaujasi duota dokumentacija.
Kartais tikrai gali būti situacijų, kuomet būna blogai paruošti reikalavimai. Todėl, jeigu programuotojas mato, kad galima padaryti kažką geriau arba tai gali sukelti problemų ateityje - būtina apie nelogiškus reikalavimus kalbėtis su komanda. Labai svarbu kuo skubiau juos pakeisti, nes ateityje vis tiek gali „išlįsti” ir reikės pakartotinai ties tuo dirbti. O perdarinėti funkcionalumą dažnai užtrunka ilgiau, nei naujai suprogramuoti.
ENGINEERS are pragmatic
Trečioji gero programuotojo vertybė. Pritaikome optimalius sprendimus realiems klientų poreikiams, surasdami geriausią kokybės, laiko ir kainos derinį. Tikras programuotojas mąsto nesudėtingai, bet tuo pačiu darbus atlieka kokybiškai.
Visas mūsų jau išvardintas vertybes jungia vienas bendras bruožas, kurį galime įvardinti paprasčiausiu atsakomybės jausmu. Kitaip tariant, tai yra supratimas, kad jau nuo pat pirmos kodo eilutės tu pats esi atsakingas už savo parašytą kodą.
Įsivaizduok tokią situaciją: programuotojas gauna užduotį, kurią turi atlikti per dvi dienas. Ją įveikia per dieną, tačiau neskiria pakankamai laiko testavimui ir keliauja prie kitos užduoties, mintyse galvodamas: „koks aš šaunus programuotojas“. Šios hipotetinės situacijos bėda ta, kad jis neskyrė papildomo laiko testavimui ir paliko tam tikrų spragų, kurias pastebi kodą peržiūrinėjantis kolega. Nutinka tai, kad pirmasis programuotojas prisiėmęs kitą užduotį, dar papildomai turi taisyti senąją. Pritrūksta laiko, dar reikia atsiminti, ką ir kodėl daro. Sugaištamas papildomas pusdienis, o kodas vėl tuo pačiu procesu grąžinamas peržiūrėti kolegai.
Rezultatas: programuotojas ne tik sugaišo anksčiau sutaupytą laiką ar net daugiau, bet dvigubu darbu apkrovė kolegas, kurie tą laiką galėjo panaudoti kitiems darbams. Svarbu ne kaip greitai gali ką nors suprogramuoti, bet kaip greitai visa komanda atliks užduotį kokybiškai.
Mūsų komandoje tokios peržiūros atliekamos nuolat, o proceso efektyvumą užtikrina atsakomybės už savo kodą jausmas.
Deja, bet per visą programuotojo karjerą teko susidurti ir su ydingu mąstymu, kuris kenkia visos komandos efektyviam darbui. Jeigu galvoji, kad atidavęs savo kodą peržiūrai esi daugiau už nieką neatsakingas – klysti. Nustok taip mąstyti. Net jeigu tiek kodą tikrinantis programuotojas, tiek testuotojai nerado klaidų, nesėkmės atveju už blogai veikiantį kodą, turės atsakyti visa komanda. Dažnu atveju, esame linkę dalintis atsakomybe. Tačiau, kai pradėjau asmeniškai prisiimti atsakomybę už kode padarytas klaidas, tai man padėjo apie rašomą kodą pagalvoti bent kelis kartus.
Mano patarimas – nebijok prisiimti atsakomybės už parašytą kodą ir kuo ankstesnėje karjeros stadijoje atsikratyk šių žodžių: „tai ir taip turėtų veikti“ bei „vėliau pataisysiu, jeigu bus blogai… “.
Būtent toks mąstymas tau padės tapti daug geresniu savo srities specialistu.
Ypatingai ilguoju karjeros laikotarpiu, kuriame reikėtų neužmiršti ir paskutinio gero programuotojo prinicipo:
ENGINEERS build trust and create value for customers
Jeigu sugebėsi pritaikyti visus šiuos principus savo kasdieniniame darbe, tai ilgainiui įsitikinsi, jog turi vienus iš pagrindinių gero programuotojo mąstymo bruožų.
Tad pabaigai mano esminiai patarimai šia tema:
- Programuotojas yra komandos dalis ir turi mąstyti komandiškai, o ne bandyti kuo greičiau atlikti užduoti ir jos atsikratyti.
- Nevertėtų dirbti pernelyg lėtai, taip stabdant visos komandos darbą.
- Svarbu ne tik atlikti savo užduotį, bet ir padėti kitiems, jeigu kažkam reikia pagalbos.
- Taip pat privalu pagalvoti apie laiko sąnaudas bei kokybės rizikas, eksperimentuojant su naujomis technologijomis ant produkto, kuris jau naudojamas klientų. Niekada nebandyti dalykai dažnai kelia kokybės rizikas, todėl reikia arba skirti daugiau laiko arba įvertinti tai prieš naudojant. Jei komanda su tuo sutinka – pirmyn.
- Na ir visada, kaip įmanoma atidžiau, testuokite savo parašytą kodą. Programas kuriame vartotojams, tad stenkis, kad mūsų darbas nekeltų jiems neigiamų emocijų ar problemų.