Ak ste čítali môj prvý článok o tom, ako byť dobrý v tom, čo robíte, mohlo by to znamenať, že máte (alebo hľadáte si prácu), ktorú nebudete neznášať (a oná vás preto nebude ničiť), a že ste nastúpili na dlhú (prakticky nekonečnú) cestu učenia sa nových vecí. A ak ste aj nič z toho neurobili, možnoste sa nad tým aspoň zamysleli. Na začiatok niekedy stačí aj myšlienka, ktorá vás tak trochu posunie mimo každodennej komfortnej zóny a vy sa prichytíte, že uvažujete o niektorých veciach tak trochu inak ako doteraz. To ale zďaleka nie je všetko a stále je čo povedať. Aj preto teraz budeme pokračovať druhou časťou s radami, čo a ako robiť, aby ste boli dobrí v tom, čo robíte.

Rozumejte veciam, s ktorými pracujete, do hĺbky. Takže viete programovať (administrovať, testovať..), áno? Naučili ste sa ako funguje cyklus for, while, čo je if a čo case a API svojho frameworku/knižnice poznáte už prakticky naspamäť. Tak to je vážne dobre. Až do momentu než príde problém. A teraz nemám na mysli taký ten typ každodenného problému, ktorý vyriešite opravou dvoch riadkov kódu alebo zásahom do databázy. Myslím, taký ten typ problému, ktorý chodí raz za čas a keď príde, viete, že dnes nebude dobrý deň. Zavolá vám zákazník a vy zistíte, že server je pretažený a nestíha odpovedať. Alebo že sa z neznámeho dôvodu tratia niektoré záznamy v databáze. Alebo že sa v niektorých prípadoch (skoro náhodne) objavuje nič nehovoriaca chyba niekde z hlbín vášho frameworku. Zákazníkovi poviete (pravdivo), že vy s tým neviete nič robiť, lebo vy len voláte API knižnice a začnete hľadať na internete, čo s tým. Nachádzate diskusie plné callstackov (stacktracov) a pojmov, ktoré vám nič nehovoria. Vitajte do sveta znalosť-vnútra-nutná problémov.

Nemôžete byť dobrý v IT, ak nebudete rozumieť veciam, s ktorými pracujete. A to „rozumieť“ neznamená ovládať API. Znamená to poznať aspoň architektúru a základné vnútorné princípy všetkého, na čom je vaša aplikácia postavená (minimálne od operačného systému smerom hore). Samozrejme, že keď začínate, tak ako prvé sa naučíte API a začnete programovať. Knižnice/frameworky s dobrým API sú aj tak navrhnuté, aby to učenie bolo čo najmenej bolestivé a štart čo najrýchlejší. Problém je, keď na tejto úrovni zastanete.

Akonáhle ovládnete nejakú knižnicu/framework/nástroj zvonku, začnite ho študovať zvnútra (do tej miery, ako sa dá…). Hovorím tu napríklad o tom, že zistíte, že Eclipse beží na OSGi – aha, a čo to OSGi je? Alebo, že Bower beží na Node.js a že Node.js beží na engine V8 – aha, a čo to ten V8 je? Alebo, že Android Studio používa Gradle a že na to, aby spolu fungovali, používa Gradle plugin pre Android, a že Gradle skripty je odporúčané písať v Groovy – aha, a čo to ten Android plugin a Groovy vlastne je?

Nepotrebujete vedieť každý riadok kódu, ale potrebujete rozumieť princípom. Aby keď v logu vášho servera nájdete callstack z knižnice, ktorú používate, tak aby ste v tom neboli ako Alenka v ríši divov. Alebo keď váš aplikačný server zahlási, že mu niečo chýba, tak aby ste rozumeli, čo sa vám snaží povedať.

Môžete svoju kariéru postaviť na prícipe používania API a každý deň pracovať s čiernymi skrinkami, do ktorých nevidíte, ale viete, čo im máte dať na vstupe, aby vykonali, čo chcete. Ale potom sa ľahko môže stať, že jedného dňa príde problém, na ktorý nebudete stačiť a vtedy vás dajú stranou a zavolajú toho človeka, čo tomu naozaj rozumie.

Robte si domáce úlohy. Jedna z vecí, ktoré oddeľujú skutočného profesionála od človeka, ktorý len vie programovať, je v akom stave odovzdáva veci hotové. Môžete ovládať špecifikácie naspamäť, architektúry sypať z rukáva a programovať ako drak, ale ak odovzdávate polodokončené veci, tak skôr alebo neskôr vás prestanú mať radi (zákazník, šéf, kolegovia…) a začnú hľadať niekoho, kto by vás nahradil. To, o čom tu hovorím, je kvalita. To je ten neviditeľný atribút všetkého, čo odovzdávate a ktorý vyžaduje o trochu viac snahy, ako len vec vytvoriť. Kvalita je niečo, načom sa strašne rado šetrí (lebo ju naozaj nie je vidno). Kvalita je ale niečo, čo váš zákazník/šéf ocení z dlhodobého hľadiska.

Čo je teda tá kvalita? Že vám zákazník nájde málo chýb (ideálne žiadne) po tom, čo mu svoju prácu odovzdáte. Že aplikáciu nezhodia nejaké okrajové stavy. Že pôjde dobre aj pri vyššej záťaži. Že ju v budúcnosti nebude problém ďalej upravovať – aj niekym iným ako ste vy. Že k aplikácii existuje dokumentácia, ktorá je aspoň ako-tak schopná naštartovať iného vývojára na projekte, atď.

Tak čo teda máte robiť, aby ste dosiahli kvalitu? Robte si domáce úlohy. To znamená, že nenechávajte kód nedokončený. Nechávať TODO v kóde si vyžaduje veľmi silný proces vývoja, aby sa k nemu niekto cielene vrátil a vyriešil ho. Buď to je niečo, čo má byť pred odovzdaním do produkčného prostredia hotové a vtedy to treba spraviť, alebo je to nejaká nová vlastnosť/vylepšenie a vtedy by mal skončiť vo vašom systéme na správu úloh. Ak to necháte len tak v kóde, tak to najskôr aj takto pôjde zákazníkovi. Testovanie je ďalšia z často vynechávaných vecí. Je to nuda, ja viem. Ale kvalita nie je obed zadarmo a vy pre ňu niečo musíte urobiť. Spustiť kód aspoň raz po tom, čo ste ho zmenili je reflex, ktorý by vás mal sprevádzať rovnako ako ten o umývaní rúk, keď opúšťate toaletu. Mali by ste to mať v sebe zakódované tak hlboko, že vám to nedovolí zavrieť zmenený zdrojový kód, kým ste to neurobili. Otestovať okrajové prípady je tiež niečo, čomu ste mali venovať pozornosť. Miera testovania je daná okolnosťami, ale snažte sa vyhnúť softvéru, ktorý by mal nálepku „tested by customer“.

Dokumentujte a komentujte kód. Ja viem, aj toto je nuda. Ale je to nutné, pretože nie ste sám v tomto svete a tiež neočakávajte, že si budete pamätať veci naveky. Refaktorujte kód ak je to nutné. A keďže to často nutné je, naučte sa techniky refaktorovania a začnite používať nástroje, ktoré to uľahčujú. Základné pravidlo je, že kód by ste mali vždy nechávať v lepšom stave, ako ste ho našli. V opačnom prípade bude jeho kvalita degradovať a vám sa na pleciach začne kopiť technologický dlh, ktorý vás skôr alebo neskôr dostane.

Ja viem, môžno mi teraz poviete, že je to síce všetko pekné, ale vo vašom projekte na to nie je čas a miesto. Tak v takom prípade sú tu dve možnosti. Prvá je, že projekt má naozaj napätý časový rámec, ale stále je šanca niektoré veci zmeniť. Plán má rezervu a váš šéf vám načúva. V tom prípade vezmite, čo máte k dispozícii a začnite konať, čo je možné. Môžete napríklad zautomatizovať nejakú opakujúcu sa prácu, ušetriť časť a ten použiť niekde inde. Alebo zrefaktorovať kód modulu, ktorý sa často mení, aby vám to nabudúce trvalo kratšie a ušetrený čas investovať do vytvorenia základnej dokumentácie. Dokonalé to nebude, ale bude to lepšie ako keby ste sa na kvalitu úplne vykašlali.

Ten druhý prípad je, že to nedokážete zmeniť. Projekt má nereálne termíny, v ktorých sa s kvalitou na začiatku ani neuvažovalo alebo že jednoducho váš šéf niečo ako kvalitu nepotrebuje a nič také nepodporuje. Ak je to tak, tak je to vážny problém. Nie preto, lebo projekt bude mať problémy a zákazníci budú z toho nešťastní. Ale preto, lebo hrozí, že ak budete dlhodobo fungovať v takomto systéme, tak vám to začne pripadať normálne. A to je ten moment, v ktorom ste naozaj prehrali. Ak vás systému núti odovzdávať nekvalitnú prácu a šanca na zmenu je minimálna, je na čase aktualizovať si životopis a začať sa obzerať niekde inde. Život je len jeden, ak sa vám stane, že sa pristihnete ako sedíte v nesprávnej kancelárii, riadi vás nesprávny človek a núti vás robiť veci, ktoré viete, že sú zlé, musíte konať.

Automatizujete opakujúcu sa prácu. Takže ste sa narodili do tohto krásneho sveta. Od mala sa o vás starali rodičia, krmili vás a učili vás žiť. Potom vám spoločnosť dala možnosť študovať na niekoľkých stupňoch školy (čo nie je úplne samozrejmé v celom svete) a vďaka tomu všetkému máte v hlave nástroj, vďaka ktorému ste schopní tvoriť úžasné veci alebo nachádzať riešenia aj komplikovaných problémov. A vy ho teraz každodenne používate na to, aby ste vykonávali dookala tú istú, monotónnu prácu. Aká škoda.

Monotónna práca, kde dookola robíte to isté, je zlo. Zlo je to preto, lebo takáto práca vás nikdy nebude baviť, alebo ju dokonca začnete nenávidieť (vyhnite sa zamestnaniu, ktoré budete nenávidieť, pamätáte?). Zlo je to preto, lebo to odoberá čas na kreatívnu prácu, pri ktorej by ste sa učili niečo nové a ktorá by vás posúvala dopredu. A zlo je to preto, lebo skôr alebo neskôr začnete strácať trpezlivosť a pozornosť a potom urobíte chybu (čo môže viesť k tomu, že to celé budete musieť spraviť odznova – s ešte väčším odporom). Ak sa nebudete vedieť vysporiadať s opakujúcou sa prácou, tak nikdy nebudete dobrí v tom, čo robíte.

Kdesi som čítal pravidlo, že ak tú istú činnosť robíte tretíkráť po sebe, je na čase ju automatizovať. Ale ako k iným, aj k tomuto pravidlu treba pristupovať triezvo. Ak niečo robíte raz, za pol roka, netrvá to viac ako hodinu-dva a automatizácia toho by zabrala viac ako deň, tak to možno za tú námahu nestojí (pol roka je dosť dlhá doba, po uplynutí ktorej už môžete byť niekde úplne inde). Ale ak niečo robíte denne alebo niekoľkokrát do týždňa, tak je na čase začať hľadať spôsob automatizácie (aj v prípade, že to v sumáre nestojí veľa času – riziko, že sa pomýlite a ubíjajúci pocit sú tu stále).

Aby ste boli schopní automatizovať si prácu, potrebujete nástroje, ktoré vám to umožnia a prax (skúsenosti s automatizáciou). Čím viac nástrojov na automatizáciu budete poznať, tým lepšie pre vás. Každý má totiž iné vlastnosti a dokáže fungovať v inom prostredí. Znalosť vhodného nástroja a skúsenosti vám umožnia zautomatizovať nejakú časť svojej práce. Takto vám prinesú ďalšie skúsenosti a uvoľnený čas sa dá použiť k naštudovaniu niektorého ďalšieho nástroja. Schopnosť automatizácie je tak akási špirála, po ktorej viete ísť oboma smermi. Čím menej budete automatizovať, tým menej času budete na ňu mať a bude vám pripadať menej a menej reálna („To si neviem predstaviť, ako by som toto automatizoval…“).

Toto je záver druhého článku o tom, ako byť dobrý v tom, čo robíte a jeho hlavný odkaz je: nesmiete sa prestať snažiť. Nesmiete sa prestať snažiť pochopiť veci, s ktorými pracujete. Nesmiete sa prestať snažiť doťahovať svoju prácu do konca – teda vkladať do nej toľko kvality, koľko si vyžadujete. A nesmiete sa prestať snažiť odbúravať monotónnu prácu. Práve tá snaha niečo zmeniť, prichádza ako prvá a postupne vás môže doviesť do sveta, v ktorom keď sa ohliadnete na to svoje staré ja, budete sa musieť sami seba pýtať ako to, že som to pochopil a začal sa snažiť až teraz.