Ľuboš Bosák: Nikto nás neučil ako rozmýšľať o programovaní samotnom

756

S Ľubošom Bosákom pripravujeme sériu večerných školení pre vývojárov. 9 rokov pracoval ako softvérový inžinier a neskôr ako manažér vývoja v amazon.com v americkom Seattle. Aby ste ho mali možnosť lepšie spoznať, spýtali sme sa ho niekoľko otázok o živote a kurzoch.

V rozhovore nájdete aj odkazy na registráciu na kurzy. 

Povedz nám niečo o sebe!
 
Vyrastal som v Nitre. Väčšinu mimoškolského času som strávil hraním hokeja alebo počítačových hier. Prvýkrát som bol v USA ako výmenný študent zo strednej. To mi dalo víziu a cieľ tam ísť aj na výšku. Dva roky tvrdej práce, spolu s know-how starších “ajbíkov” z Gymnázia Jura Hronca v BA, mi pomohli dostať štipko na malú školu v Minnesote. Tam som dostal bakalára z Computer Science.
 
Ako si sa dostal do Amazonu v USA?
 
Amazon si ma “našiel” kým som bol ešte na škole. Nie že by som bol taký super, bola to skôr zhoda náhod. Bolo to prvý a pokiaľ viem jediný krát, čo niekto z Amazonu prišiel robiť nábor na túto malú školu. Normálne sa sústredia na veľké univerzity so silným inžinierskym programom.
Pamätám si ako dnes, keď spolužiak, čo bol na tom neformálnom pohovore predomnou, vyšiel z miestnosti biely ako stena. Nevedel som, čo si mám o tom myslieť. Pohovor som ale zvládol dobre, tak si ma zavolali na formálne kolečko do Seattlu. Tam som za jeden deň absolvoval 4 asi hodinové pohovory, a o týždeň mi ešte poslali “domácu úlohu”. Nakoniec mi predsa len dali ponuku, a tak som mal posledný semester na škole pohodičku.
 
V čom je práca v USA iná ako na Slovensku?
 
Povráva sa, že kým v Európe ľudia pracujú preto, aby žili, v Amerike žijú preto, aby pracovali. Niečo na tom pravdy je. Najväčší rozdiel ale vidím v štýle vedenia ľudí a firiem. Na Slovensku do veľkej miery vládne nedôvera voči zamestnancom, ktorá vyúsťuje do zbytočných byrokratických požiadaviek – ako napríklad vykazovanie činnosti. Alebo sa to prejavuje nedôverou s home officom. Na druhej strane je výnimkou, ak má firma náročné výberové sito alebo relevantný systém vyhodnocovania výsledkov zamestnancov a spätnej väzby. To sa mi zdá byť postavené na hlavu. Do slovenských firiem by som priniesol hlavne zmenu myslenia ohľadom ľudí – ako, kam, a prečo do nich investovať.
 
Čo by si odporučil začínajúcim programátorom?
 
V prvom rade by som odporučil úprimne sa zamyslieť nad tým, či mi programovanie naozaj ide a baví ma, alebo to robím len preto, že sú v tom dobré peniaze, alebo to odo mňa chcú rodičia. Na programovanie treba “mať bunky” a keď ich nemáš, každý deň v práci bude trápenie (a tie dobré peniaze sa stanú pascou). Neznižuje to tvoju hodnotu ako človeka – len to znamená, že tvoje dary sú v niečom inom. Aj ty aj ľudia okolo teba budú oveľa šťastnejší, ak sa zameriaš na činnosť, na ktorú máš talent.
 
Ak si z tých, čo na to bunky majú a programovanie ťa baví, tak by som odporúčal hodnotiť projekt alebo zamestnanie (či už potenciálne alebo súčasné) podľa toho, koľko sa naučíš, a podľa ľudí naokolo. Najcennejšie je mať kouča, od ktorého sa môžeš veľa naučiť. Ak máš k takému prístup, snaž sa byť čo najlepší študent aby ťa aj chcel učiť. Najhoršie je mať projekt, na ktorom sa neučíš, alebo manažéra, ktorý chce uspieť inak ako cez úspech svojho tímu.
 
Prečo si sa rozhodol postaviť pred ľudí a zdieľať svoje skúsenosti z Amazonu?
 
Keď som začal pracovať na Slovensku, bol som zhrozený, ako sa tu kóduje lážom-plážom. V prvej firme som vedeniu navrhol, že by sme mohli urobiť pár stretnutí na tému best practices – síce prikývli ale nikdy sa s tým nič neurobilo. Na ďalšom projekte to bolo trochu lepšie, ale pri práci s juniormi som si začal uvedomovať, ako veľmi sú závislí na kopírovaní kódu (aj ja som toho hojne nakopíroval, keď som začínal). Dôvodom je to, že síce sme sa naučili programovať, ale nikto nás neučil ako rozmýšľať o programovaní samotnom. Keď mi vtedy môj projekťák povedal, že “susedia” majú záujem o neformálne softvérové školenia a či by som zvládol o niečom porozprávať, rozhodol som sa ísť do toho. Nakoniec som pre nich pripravil 13 rôznych školení, a pozitívna odozva potvrdila, že mám čo povedať.
 

Zásady krásneho kódovania

V čom je krása kódovania?
 
Kým obyčajný kóder sa snaží napísať program tak, aby fungoval, majster píše kód, ktorý sám vypovedá o svojom zámere, je jednoduché mu porozumieť a ľahko sa dá pozmeniť.
 
Podľa čoho poznáš kvalitný kód?
 
Toto je základná otázka, od ktorej sa celé školenie odvíja. Teórii je viac – ja sa najviac prikláňam k tejto formulke: 1/Qc ~ WTF/min
 
Čo donúti programátora riešiť v kóde niečo viac ako len funkčnosť?
 
Je veľmi frustrujúce keď mám urobiť zmeny v kóde, ale snaha pochopiť čo ten kód vlastne robí mi zaberie 5x dlhšie, ako samotná zmena.  Ešte horšie je keď sa pozriem na “blame” a zistím, že ten kód som písal ja pred pol rokom…
 
Ktorý moment to bol u teba, keď si sa začal týmto zaoberať?
 
V amazone som mal v tíme kolegu, ktorý aktívne presadzoval best practices pre kvalitný kód. Nie len dogmaticky, ale vždy vedel dobre vysvetliť, prečo je tá-ktorá zásada dôležitá. Ale taktiež keď sme ako manažéri v amazone vyhodnocovali návrhy na povýšenia vývojárov, kvalita kódu bola jedna z rozhodujúcich kritérií.
 
Školenie už 19.6.2019 v Campus Cowork Mlyny o 18:00. Facebook podujatie. Registrácia na školenie.
 

Zásady programovania komponentov

O čom bude tento kurz?

 
Komponenty sú ako kúsky stavebnice, ktoré tvoria aplikáciu, ale aj celý systém. Ich rozhrania diktujú, ako jednotlivé komponenty spolupracujú. Pomocou príkladov z bežného života si prejdeme princípy a zásady ako správne komponent vytvoriť a ako navrhnúť celé rozhranie. 
 
Prezraď jednoduchý tip pri architektúre komponentov?
 
Podstata každého komponentu by sa mala dať vyjadriť jednoduchou vetou.
 
Ako si objavil princípy, o ktorých budeš hovoriť.
 
V amazone som zažil čas rozbíjania monolitických aplikácií a dizajnovanie distribuovaných servisov na ich nahradenie. Rýchlosť, akou zároveň biznis napredoval ma naučila, že aj keď teraz si nemyslíme, že “toto” sa môže použiť ešte na niečo iné, o rok bude na stole požiadavka to prepoužiť. Odlepiť dobre nadizajnované komponenty je oveľa ľahšie ako rozbíjať monolitickú aplikáciu.
 
V čom je lepšie byť pri návrhu komponentov opatrný?
 
Treba si byť vedomý, do akej vrstvy ktorý komponent patrí, a mať jasno v jeho úlohe/podstate.
 
Školenie sa uskutočnilo už 5.6.2019 v Campus Cowork Mlyny o 18:00. Facebook podujatie. Registrácia na školenie.
 

Typy komunikácie v distribovaných systémoch

Priblíž nám tému tohto školenia!

 
Väčšina dnešných systémov komunikuje cez sieť s inými systémami. Kým sa touto komunikáciou nemusíme zaoberať, vystačíme si so všeobecnými pomenovaniami ako “remote call” alebo “message processing”. Keď sa však začneme podrobnejšie zaoberať tým, ako systémy spolupracujú – buď pri odstraňovaní problémov alebo pri tvorení niečoho nového – zrazu potrebujeme oveľa hlbšie pochopenie základných konceptov a ich potenciálneho využitia. 
 
Kedy zvyčajne zlyháva komunikácia v distribuovaných systémoch?
 
Niekde medzi 1% a 0.1% pokusov. Ak systém spracováva len 100 požiadaviek za deň, potenciálne raz za deň niečo zlyhá. Distribuované systémy si vyžadujú veľmi presný a cielený dizajn, aby sme vedeli správne reagovať v prípade zlyhania komunikácie. Aj keď tento seminár nie je o fault tolerance, hovorí o základoch bez ktorých dobré distribuované systémy nevybudujeme.
 
Ako predísť problémom v takomto type komunikácie?
 
Tu sa problémom predísť nedá. Práve naopak, dizajn musí s problémami počítať, aby mohol na ne správne zareagovať, aby ten problém nijakým spôsobom neprebublal k užívateľovi.
 
Pri riešení akého problému si to musel začať riešiť?
 
Mal som systém, ktorý spracovával veľké množstvo update-ov z rôznych systémov, ktoré mali rozdielne požiadavky na rýchlosť, frekvenciu, a spoľahlivosť. Keď sme to nastavili tak, jedna skupina mala taký problém. Ale keď sme to nastavili inak, druhá skupina mala iný problém. Museli sme vyskladať kombináciu tak, aby sa aj vlk najedol aj koza ostala celá.
 
Školenie už 20.6.2019 v Campus Cowork Mlyny o 18:00. Facebook podujatie. Registrácia na školenie.
 

Git v pohode

Prečo máš školenie o Git-e?

 
Git je ten najužitočnejší “version control” systém, aký bol kedy vytvorený. Ale vedel si, že v skutočnosti nie je postavený ako verziovací systém? To by mohlo vysvetliť, prečo sa niekedy zachová tak nepredvídane. Počas školenia sa Git-u pozrieme pod kapotu a vysvetlíme si nie len ako funguje, ale aj ako s ním dobre pracovať.
 
3 dôvody prečo si vybrať Git?
 
Ak niekto nepracuje na osobnom projekte alebo nezačína startup, asi si VCS vybrať nemôže. Ale hlavné 3 výhody Git-u sú, že nepotrebuje centrálny server, je distribuovaný, a hlavne že umožňuje veľmi flexibilný workflow. V konečnom dôsledku zjednodušuje tvorenie kvalitného kódu.
 
V čom nás môže Git zaskočiť?
 
Git nerešpektuje základné princípy fungovania počítačového file systému, na ktoré je našinec zvyknutý. Klik, a zrazu mi zmiznú veci, na ktorých som práve pracoval. Ale aj keď ich neviem nikde nájsť, vôbec nie sú stratené. Dokonca tvrdím, že pri dodržiavaní pár malých zásad je prakticky nemožné s gitom stratiť kus práce.
 
Školenie už 13.6.2019 v Campus Cowork Mlyny o 18:00. Facebook podujatie. Registrácia na školenie.
 

Ďakujem za rozhovor. Budem vďačný za Vaš komentár.

Dobrý článok? Chceš dostávať ďalšie?

Už viac ako 6 200 ITečkárov dostáva správy e-mailom. Nemusíš sa báť, nie každé ráno. Len občasne.

Súhlasím so spracovaním mojich osobných údajov. ( Viac informácií. )

Tvoj email neposkytneme 3tím stranám. Posielame naňho len informácie z robime.it. Kedykoľvek sa môžeš odhlásiť.

Martin Ďurina
Mám rád ľudí aj svet okolo seba. Prial by som si, aby sme si rozumeli a dokázali spoločne vytvárať zmysluplné veci. Prirodzene má to vždy tiahlo ku komunikácii, mám vášeň pre online svet, zbožnujem hudbu. Pracujem na robime.it a ak sa vám rozsvieti nápad, že by sme mohli spolupracovať, neváhajte a hneď mi napíšte.