Potreba zlyhania pred dosiahnutím úspechu

Namiesto recyklovania generického „growth mindset“ bľabotania chcem poukázať na niekoľko mojich vlastných prešľapov (rozhodnutí), o ktorých správnosti som bol presvedčený, že sú správne (neboli), a na lekcie, ktoré som sa pri nich naučil. Tieto (a ďalšie) zlyhania prispeli ku tomu, že som sa vo veku 27 rokov stal senior vývojárom. Dúfam, že tieto krátke príbehy ukážu, že každý senior niekde začínal, robil chyby a odniesol si z nich ponaučenia.

Malé Refaktorovanie
„Hmm, pozri sa na ten starý kód. Vedel by som ho refaktorovať. Nevyzerá to byť také zložité.“

Klasická chyba, ktorú robia iba juniori, však? Nie. Túto chybu som spravil minimálne raz ročne za posledných sedem rokov. Každý. Jeden. Rok. A stále ma dokáže prekvapiť, že to nie je vždy ideálny nápad.

V prvom rade musíte presvedčiť svojho manažéra, aby alokoval čas na refaktor kódu. Verte mi, posledné, čo chce počuť je, že chcete meniť funkčný produkčný kód, ktorý používajú tisíce platiacich zákazníkov, len preto, že sa vám nepáči jeho syntax. Veľa šťastia pri tomto predaji.

Ak ho aj presvedčíte, tak čo potom? Máte deadline. Ste si naozaj istí, že rozumiete každému okraju toho starého kódu? Nie? Je pokrytý testami? Pravdepodobne nie. Takže teraz len dúfate, že vaša vylepšená verzia nevybuchne. A keď vybuchne, ste to vy, kto za to zodpovedá.

Najhorší scenár? Ste až po uši v „neškodnom malom refaktoringu“, nestíhate termíny, stres vám lezie až z uší a ťaháte neplatené nadčasy, len aby ste opravili problém, ktorý ste si sami vytvorili.

Refaktorovanie nie je zlé. V mnohých prípadoch je nevyhnutné pre dlhodobú udržateľnosť kódu. Treba si však byť vedomý rizík, ktoré sa kvôli nemu chystáme podstúpiť. Vždy majte pádne dôvody, pre ktoré chcete refaktorovať., A úplne ideálne –  podporu svojho manažéra. Hlavne však treba pochopiť, prečo daný kód existuje a aké okrajové prípady pokrýva.

Nová Žiarivá Technológia
Raz som bol priradený ku novému projektu ako hlavný vývojár jeho frontend časti. Mohli sme si vybrať celý stack. Frontend, aj backend. Hneď som sa samozrejme začal po večeroch hrať s GraphQL a obdivovať jeho flexibilitu. Písanie vlastných queries na frontende a generovanie TypeScript typov? Vravím si – úžasné.

Vtom mi v hlave skrsla myšlienka: „Keď to funguje v mojich mini projektoch, musí to fungovať aj pre veľkú produkčnú aplikáciu“. Backend tím bol za. Manažment presvedčený. Ideme meniť svet.

O štyri až päť mesiacov neskôr. Všetko bežalo krásne… Na localhoste. Po presunutí na reálne servery boli zrazu všetky queries pomalšie ako štátne stránky. Čo sa udialo? A vtedy to prišlo. Nechválne známy N+1 problém v GraphQL. Databáza kolabovala pod stovkami zbytočných volaní pri každom dátovom vnorení, keďže na frontende sme si sťahovali polovicu databázy pomocou jednej query. Nasledovali ďalšie dva-tri mesiace trápenia, optimalizovania dopytov, refaktoringu a prekopávania časti backendu.

Čo som si z toho odniesol? Uvedomenie, že fakt, že som sa hral s novou technológiou vo vedľajšom projekte ešte neznamená, že som pripravený ju pretlačiť do produkcie. S čím išlo ruka v ruke to, že keďže som to bol ja, kto ju použil, stal som sa zodpovedným za danú technológiu/knižnicu. Byť zodpovedný nie je zlé. Ak vieš, čo robíš. Problém nastane, ak si s tou knižnicou strávil dve hodiny a myslíš si, že si už expert.

Nežiadať o Pomoc
Na začiatku mojej programátorskej kariéry som chcel byť “hardcore Java backend vývojár”. Prečo? Pretože nás to učili na univerzite. Jedného dňa mi však dali malú frontend úlohu na vytvorenie mini appky s dvoma stránkami. Prvá stránka obsahovala len tlačidlá s odkazmi na externé stránky. Na druhej bola tabuľka logov, viditeľná len pre admina.

Skúsený vývojár by to mal hotové za jeden-dva dni. Mne to trvalo tri týždne. Prečo? Pretože som vtedy netušil, čo znamená CORS, Proxy, JWT token, Cookies, Sessions, atď. Prvýkrát som sa taktiež dozvedel, že JavaScript má knižnice. Angular? React?

Namiesto toho, aby som sa spýtal kolegov, začal som googliť. A padol som do nekonečnej informačnej diery. Existuje tenká hranica medzi „nechcem vyzerať ako idiot, tak si to naštudujem“ a „nemám absolútne poňatia, čo robím“.

V juniornej fáze našich kariér je často najväčšou prekážkou nášho progresu naše ego. Radšej spravíme otrasné riešenie po desiatich hodinách trápenia, akoby sme sa mali spýtať niekoho skúsenejšieho a vyzerať päť minút neschopne.

Dnes, ako senior vývojár, viem, že povedať „neviem“ nie je ukážkou slabosti. Je to známka efektivity. Znamená to, že viem, kedy a koho sa spýtať, aby sme spoločným úsilím produkt dokončili čím skôr.

Hlavné Ponaučenia
Úprimne (a smutne) – mohol by som pokračovať ďalej. Ale tu je to podstatné – všetci robíme chyby. Niekedy menšie. Niekedy úplne katastrofálne. Práve vďaka nim však rastieme.

Senior vývojár nie je ten, ktorý pozná odpovede na všetky otázky. Je to ten, ktorý už pozná zlé rozhodnutia, pretože ich sám kedysi urobil. Skúsenosť nás neučí len to, čo máme robiť, ale aj to, čo by sme radšej už nikdy urobiť nemali.

Práve v týchto momentoch zohráva zásadnú rolu prostredie, v ktorom pracujete. Mám šťastie, že som súčasťou Multitude IT Labs – firmy, ktorá tieto princípy nielen chápe, ale ich aj aktívne podporuje. Tu nie je zlyhanie hanbou, ale príležitosťou na rast. Kód sa nerobí len „aby bol hotový“, ale s dôrazom na kvalitu, udržateľnosť a otvorenú spätnú väzbu.

Vo firme vládne kultúra dôvery, otvorenosti a podpory. Skúsenejší kolegovia vás nenechajú utopiť sa vo vlastných chybách. Namiesto toho vám pomôžu pochopiť, ako sa z nich poučiť. 

Multitude IT Labs je miesto, kde sa z chýb nerobí škandál, ale skúsenosť. A to je podľa mňa najväčší rozdiel medzi pracoviskom a skutočným prostredím pre profesionálny rozvoj.