7: Clean Code, ale naozaj: Igor Liška (CEO Panaxeo)

[0:01] Ahojte, vítame vás v epizóde 0101 podcastu. Je to taký náš kofitálok o technológiách, o tom ako technológie riešia biznisové

[0:15] výzvy a v neposlednom rade aj o ľuďoch, ktorí sa týmito riešeniami stoja. Dnes privítame Igora Lišku, ktorý je CTO a spoluzakladateľ Panaxeo a zároveň aj spoluzakladateľa, človek s technickou kompendenciou indie gamingového štúdia Atomic Realm.

[0:42] Vítaj Igor. Ahojte, ďakujem pekne za pozvanie. A od ďalších dvoch mikrofónov vás zdravím ja, Daniel a Oliver. Čaute. Takže ahojte, pustíme sa teda do toho. Začnem, Igor, vitaj ešte raz, vďaka za čas aj za priate pozvania. Začnem možno na začiatok LEGO témou, nie takým klasickým predstavaním, lebo keď sme sa bavili minule a pripravovali sme sa na podcast, tak ty si tam mal takú veľkú policu, alebo veľký regál lega, asi aj teraz je po tvojej pravej ruke. Zároveň aj na LinkedIn máš taký cover image, kde máš LEGO zvýraznené.

[1:39] Jedno zo slov, ktoré ťa popísuje a okrem toho ešte máš aj v rámci LinkedIn, top skill-ov LEGO Robotics, tak myslím si, že to môže byť niečo, čo nám pomôže teda nám aj posluchačom odkryť trošku tvojho osobnoho a povedať niečo o tebe také iné a to LEGO Robotics je, Je technické to zároveň, takže povedz. Ty, LEGO, LEGO, hociaké LEGO Robotics, skladanie vecí. Hociaké LEGO je v podstate, je to určite jedno z mojich najobľúbenejších hobby. Venujem sa tomu v podstate od detstva s nejakou menšou prestavkou tam okolo puberty. A ja som sa k tomu vlastne vrátil v dospelosti a odtedy ma to vlastne drží. A je to pre mňa jeden zo spôsobov, ako vlastne viem trošku vypnúť od práce. Jeden z takých štandardných oddychov je, že si pustím film, ktorý som už videl veľmi veľakrát a stačí mi ho počúvať a do toho skladám nejakú

[2:41] novú stavodnicu alebo niečo, niekedy vlastné niekedy také čo kúpite Ok, a koľko, keby si mal takú štatistiku odhadnúť že koľko si toho už poskladal.

[2:56] Sú to stovky setov Stovky setov, a tie všetky máš aj doma alebo niekomu daruješ? Tie mám všetky prevažne doma. Niečo mám ešte odložené u rodičov, niečo mám v byte, niečo je rozložené, niečo je poskladané a je toho celkom dosť. Takže desiatky metrov štôrcových. Áno. Ja to skôr na kila počítam a sú to desiatky kilogramov. To je presne oly, ako hovoríš, že keď tie ženy si kúpujú také tie veľké šatníky na oblečenie, tak Igor si prikúpuje izby by na LEGO. No, krabičky, do ktorých sa to triedi, áno. Myslím si, že som ich vykúpil v jednom obchode. A tie skňahovanie bude radosť potom, nie?

[3:42] Ako so všetkým. Tak je, ale budeš plánovať, predpokladám, vlastnú miestnosť. Je taký plán a uvidíme, ako to vypáli, ale áno, je niečo také na pláne. Hej, alebo môžeš, tie, ktoré sú teda tie LEGO robotické môžeš naprogramovať a nechťa nasledujú pri tom vzťahovaní, nechťa nebudeš mať prácu. Programuje sa pri LEGO Robotics, že potrebuješ tam aké tam potrebuješ technické skilly.

[4:12] Programuje sa to úplne normálne ako čokoľvek iné, že ak niekto pozná napríklad Arduino, tak dá sa to k tomu trošku napodobiť, že tiež tam viete ovládať nejaké motory, čítať nejaké senzory, robiť s premennými forcyklami, kadečím a ovládať v podstate niečo. Ja som so prvýkrát s nejakou Robotics stavebnicou vlastne s Mindstorms som zabával už vlastne koncom 90. Rokov ešte ako dieťa a veľmi ma to chytilo a veľmi ma to bavilo v rámci toho že som sa aj učil programovať a zrazu som vedel to LEGO nejako ovládať nejako viac ako len sa s tým hrať a robilo to zrazu niečo samostatne a nejak to reagovalo na cenzory a to bolo veľmi zábavné a aj zaujímavé čiže je to určite jeden z dôvodov, prečo ma aj chytilo programovanie časom a potom som vlastne prešiel niekoľkými ďalšimi tými Mindstorm stavebnicami a dneska v podstate ľubovolný LEGO Technic, ktorý má taký ten bluetoothový hub na ovládanie tak ten sa dá programovať v podstate a sú už na to aj celkom pekné open source-ové nástroje takže obyčajný Python, Ok, to som sa práve chcel spýtať.

[5:24] Jedna vec, či ti pomohlo ako keby tá práca s tým Legom sa dostať vlastne k tomu softwaru inžinieringu a aký jazyk teda Python, hej, takže všetci Pythonisti sú natívni legoví vojári. V podstate áno, tam je to taká vec, čo sa volá, že MicroPython a je to v podstate Python, ktorý je trošku taký osekaný. Ale to všim stále sa to dá programovať tým vizuálnym programovacím. Áno, áno. Bo ten si pamätám, ja som tiež v tých 90-tých rokov, tancujúci LEGO robotov na nech súťažach mal a spolužiak dá sa to tým len tam už je skôr problém s podporou tých nástrojov lebo dneska už je to celé odkazané len na third party nástroje že tie oficiálne odlega už akože pre tie staré sety proste nefungujú lebo to ani nainštalujete na moderný počítač, takže je to odkazané naozaj na podporu komunity a tá komunita je veľmi silná okolo toho hej v podstate čo je taká tá First LEGO League.

[6:29] Občas to okolo mňa prebehne, ale všimám, že je to veľký event, veľké podujatie a ľudia sa tomu akože seriózne venujú aj tie decka že to tam skúmajú teda, že riešia tú súťaž a, Takže to je zaujímavé. No, potom sa treba učiť od lega, ako stavať komunitu tým pádom, že keď si mohli dovoliť oni prestať vyvíjať ako keby ten tooling a iba samotný produkt a ostatní, im vyvinú tie tooli, tak to je skvelé.

[7:08] Dobre. No, Igor? Ja len, že tam sa bavíme o veciach, čo sú naozaj, že už niektoré je 20-25 rokov staré a tým pádom ja aj rozumiem, že nedáva im zmysel to ako keby podporovať, hlavne keď prinašajú nové a nové stavebnice každý rok. Čiže je to naozaj o tom, že tí ľudia, ktorí to majú doma a chcú to ešte stále používať, lebo to funguje, tak sú proste nástroje tretich strán, ktorými sa to dá programovať a tí ľudia, čo to vlastne vtedy mali ako deti sú dneska dospeli ľudia a možno, že polovica z nich programátory, to som si vymyslel samozrejme to číslo, tak, chápem, že hľadali ale proste iné cesty. Dobre, dobre. Teda, LEGO je aj hra, je tam to programovanie, potom je vlastne to hernevyvojarské štúdio.

[7:55] Súvisí aj to, že si co-founder a že sa venuješ vývoju hier nejakým spôsobom s Legom, alebo to už je úplne z iného sudka a k tomu tej vášnej si zadostal inak? Skôr to asi nesúvisí, alebo nikdy som tam asi a súvis nevidel ak to aj spolu nejako súvisí je to asi o tom, že ma vždy bavilo hrať sa počítačve hry na strednej škole ma bavila vektorová matika to znamená nejaké predstavovanie si 3D priestoru a nejaké operácie v ňom, nejaké posúvanie vektorov rotácie a niektoré ďalšie zložitejšie veci to ma vyslo nebavilo na škole no a.

[8:39] Akože pri tom vývoji hier, že to je vysolnenie čo ma baví, že tam vlastne pracujeme z Unity, programujeme v C-Sharpe a treba na to vedieť aj trošku viac ako len programovať, že to programovanie tam je skôr.

[8:56] Spôsob prejavu, ale nie je to tá kľúčová časť, že v Unity niekto vie veľmi dobre robiť s animáciami, niekto vie programovať, niekto vie robiť so zvukmi, niekto vie robiť s 3D modelmi, so scénami a tak ďalej. Že nie je to len o tom programovaní, je to aj o nejakej kreatívnej činnosti s tým spojené. A preto mi to príde zábavné a samozrejme to aj úzko súvisí s tým, že dodnes hrávam počítačové hry, som veľký fanušik Nintendoa.

[9:23] Mám od nich vlastne niekoľko konzol, ktoré aj dodnes používam. Nedávno vyšiel Steam Deck, to je úplná pecka, takže toto som okamžite kupoval hneď ako sa dalo. Ale ho celkom často používam. Takže súvisí to asi s tým, že sa aj rád zahrám nejaké počítačové hry alebo konzolové hry. No a vždy ma fascinovalo, že ako sa také niečo dá vytvoriť. Ok, ok, pozrám Steam Deck, o tom som ani nevedel, že niečo také existuje Veľká škoda Ale preň mi to podobné ako Nintendo Switch, niečo také však? Akurát tam máš celú svoju Steam library dostupnú, čo je akože veľmi silný presviečiací argument. Čiže vlastne všetko, čo beží na Steam-e, beží aj tam. Máš celú svoju Steam library do sebou niekde, kde chceš. A oni urobili nejaké hardware-ové limity na tie hry, ktoré sú z tej platforme alebo správili tak výkonnú výkonné zaradenie? Asi niečo medzi, že dali tam rozumne malý a zároveň veľký display, tak aby žral rozumne málo elektriky, ale zároveň aby mal celkom dobré rozlišenie.

[10:36] Je tam od AMD-čka grafická karta a stačí to na to rozlišenie a na baterku to vydrží dve, tri hodiny, ale zahráte si na tom aj relatívne.

[10:50] AAA tituly, ktoré normálne kedy si vyžadovali akože celkom seriózny hardware. Ja som na tom nedávno hral nejaký Need for Speed, alebo celkom dobre sa na tom hrajú rôzne plošinovky, ale aj akože trijačkové tituly, Assassin's Creed, kadečo ďalšie. Musím si to vyskúšať, lebo že presne nejaký experience toho nejakého Assassin's Creedu, alebo niečoho, takže teda ja sa priznám, že ja sa až tak veľa teraz už nehrávam, ale mal by som asi začať, ale vieš, že Tomáš, tak mám doma nejaké playko, nejaké VR-koje, ale hrám sa tam len exevalá to mečovanie Beat Saber a to je tak celé, som nedisciplinovaný, mal by som byť disciplinovanejší v hraní sa a vieš, že Tomáš tradične ako keby nejakú, veľkou obrazovú experience a že aké to je vlastne na tom, na tej malej ručnej konzole, Je to super, keď to máš doma na gauči, v obyvačke, niekto iný chce možno pozerať film, ty si dáš sluchátka a vieš sa pri tom zahrať. A ďalšia vec je, že úplne, že tá killer feature pre mňa je, že keď tú hru hráš a vypneš ju akože tlačidlom, ako telefon proste, že ju len vypneš, tak to zhasne nič. Odložíš to a keď to znovu zoberieš o dve hodiny a znovu to zapneš, tak pokračuješ presne tam, kde si bolo žiadne loadovanie, načítavanie, nič.

[12:11] Čiže keď sa s tým hráš a dojde za tebou dieťa, niečo potrebuje, tak sa vieš venovať, ale zase vieš sa do toho rýchlo dostať, takže je to také, že práve, možno pre dospelých ľudí dokonca možno lepšie, lebo si na to netreba vyhradiť ten čas, že teraz sa hráma. To znie ako silná user experience.

[12:32] Akože nechcem im robiť vyslovene ambasadora, ale myslím si, že je to moja momentálne najulbenejšia konzola a to som bol veľký fanušik Nintendo Switch. Mne to lákavo, ale z mojich skúseností viem, že by som také niečo domov nemohol doniesť. Lebo už som si musel kúpiť aj druhú ktoré som chcel byť detkami, brali to moju. Takže s takýmto ešte blikajúcim zariadením. Puuu, to by bolo. Hej, Igor, keď sa bavíme o hrách, tak poďme možno, že len tak, keby si krátko si povedal, že ako také indie.

[13:10] Vývojárske herné štúdio funguje, koľko titulov napríklad vydáte, z čoho sa to financuje, či je to Ivan, alebo, takú tú nejakú biznizovo-produktovú vec, aj keď si hovoril, že sú tam animácie, potrebuješ tam nejakých game designerov, nejaký skript, asi závisí od typu hry. Potom by sme možno sa pozreli na to, čo to znamená jedna ľadiska technológií. My sme maličké štúdio, to znamená, každý robí všetko a to je aj to, čo máme radi, tak nás to baví. Neviem, či by som povedal, že máme ambície z toho urobiť gigantické štúdio, ale to sa asi ani nedá úplne plánovať, to zavisí od toho, jak by sa nám darilo. Čiže teraz sa bavíme o tom, že sme deviati a to vlastne firma existuje rovnako dlho ako Panaxeo, čiže v podstate 5 rokov. A...

[14:10] Herný priemysel na Slovensku je určite ťažší ako softwarový vývoj a to softwarový vývoj vôbec nie je ľahký, takže je to naozaj také, že.

[14:22] Nepovedal by som, že vydávame strašne veľa titulov, že máme proste za sebou nejaké vlastné tituly, do toho robíme trošku outsourcing, aby sme zase mali aj samozrejme nejaký príjem do firmy, trošku stabilnejší ako je z hier a snažíme sa nejako vyvažovať vlastne vlastnú tvorbu a outsourcing tak, aby aby sme to mohli zvládať. Takže my vlastne pracujeme na vlastných hrách, ktoré veľakrát niekedy skončia vo fáze prototypu, niekedy to posunieme ďalej a keď si veľa veci sadne naraz, tak sa to dostane vlastne až von. Ale to, čo sa vlastne dostane von, to je možno každá, neviem koľká tá hra, alebo vyskúšame veľa rôznych vecí a zistíme, čo funguje, čo nefunguje, čo nás baví a nebaví a tak. Teraz aktuálne pracujeme vlastne na novom titule pre MetaQuest 3, to znamená, ideme trošku do mixovanej reality.

[15:16] Meta nedávno vydala vlastne MetaQuest 3, prvýkrát je tam vlastne pass-through, čiže vidíte ze skamery svoje okolie a už to nie je také, že ste v 3D svete len, ale vidíte vlastne, čo sa okolo vás deje a viete umiestňovať predmety do 3D priestoru okolo vás, takže viete vlastne nejakým spôsobom pracovať s tým okolím. A meta robí na rôznych veciach, aby sa rozpoznávalo, čo je stena, čo je stúl, čo je gauč, čo je polica. Takže vám dáva veľa rozumných nástrojov, ktoré sa na to dobre používajú. No a potom viete v Unity normálne programovať cez ich SDK-čko pre takéto okuliare. A samozrejme je tam potenciál ísť aj na Vision Pro od Apple-u.

[16:01] No a to sú vlastne platformy, na ktoré sa teraz zameriavame a na ktoré skúšame nejaké prototypy takže tento rok by sme rádi vydali vlastne jednu maličku hru ktorú aktuálne na nej robíme a podľa toho ako by sa jej darilo, by sme videli, že čo s tým potom ďalej, že či je to platforma, na ktorej chceme stávať ďalej, alebo nie no a popri to máme skúsenosti teda veľa skúseností s mobilným vývojom, a tam vlastne cez outsourcing robíme vlastne na hrách pre iné štúdia. No a tam robíme asi na šiestich alebo siedmých hrách aktuálne. Jo. To sú hry, ktoré majú normálne hráčov, ktoré normálne fungujú a vlastne my ich vyvíjame a staráme sa o to, aby fungovali. To znie, že tam je veľa veci, ako keby paralelne sa robí. Takže je to také niečo, čo že nestáva sa to pri bežnosti vývoj, že máš toľkoto veci rozpracovaných naraz, alebo možno sa to niekedy aj stáva, ale je to potom náročné na to, aby to bolo, efektívne, alebo v angličtine je takéto efficiency a efektivne, že sa to rozlišuje, ale že v podstate, lebo máš tam context switching.

[17:19] Zrejme nejaké, ako je takéto niečo organizované, že toľkoto veci paralelne na toľkýchto veciach paralelne ste schopní pracovať? Alebo je to vďaka tomu, že je tam tých 10 ľudí a oni majú v podstate akože skôr fokus na niečo, na jednu, dve veci, hej? A deje sa takéto niečo? Je to presne tak, že väčšina ľudí vlastne má fokus na svoju vec, alebo proste jednu, dve, tri veci max. A potom sme tam tým, že je to malá firma, tak ako majiteľia, sme tam vlastne trája majiteľia a my skôr riešime tú manažerskú časť, game design časť alebo čokoľvek, čo neriešia iní ľudia. Takže kontext switching je v podstate po písmovej práce či v Panaxeu, či v Atomic Realm, lebo bez toho sa to vlastne nedá robiť. Pre mňa je celá práca o tom zvládať vlastne kontext switching. Áno. Ale vy asi predstavíš, že nie pre každého toto môže byť ako keby.

[18:26] Produktívne alebo efektívne alebo pri každom type práce že je alebo je to nejaká fičura celkovo aj, panaxiáckych ľudí aj atomik realmáckych ľudí že sú takíto veľmi schopní nechcem to povedať, že multitaskery alebo nie je to multitasking, hej, je to niečo iné, alebo je to len ja neviem, týka sa to teba, nejakých vybraných ľudí, ktorí možno, že majú, nejdu úplne do hlbky vo všetkých veciach. Verím, že v jednej aj v druhej firme sú hlavne naskylení ľudia, že to áno. Naša snaha v obidvoch firmách je minimalizovať kontext svičík, prečo najviac ľudí. Nie je to efektívne a niektoré role sa tomu nevedia vyhnúť z natúry tej role, ale ja osobne si nemyslím, že to je akože niečo, čo by trebalo používať ako nástroj, to je niečo, čo tu je a nedá sa okolo toho úplne ísť a za mňa čím menej toho je, tým lepšie, hej, čiže, to, že náplň mojej práce je context switching, to je skôr z natúry tej práce a, než, že by som bol rád, že to tak je, hej, že to je skôr ako.

[19:43] Dôsledok, nie, že by som čo som tu žil potom. Čiže keď sa sumarizujeme, máš dve firmy. V gamerskej firme tam máte viacero projektov vlastných a viacero projektov robí ťa pre svojich zákazníkov. No a vlastných sa snažíme vždy robiť na jednom čase, čiže skúsime, vyjde, nevyjde, ideme ďalej. Trošku menej kontaktsvičím. Tak. Potom následne, tvoj daily job je veľká firma, kde máš 70 ľudí.

[20:17] To je relatívne už veľké. A ak som to správne pochopil aj tvoj pohľad, najmä tie, čo som niekde inde videl, alebo ťa počul rozprávať, tak aj teraz, čo si povedal, ak som to správne pochopil, tak, snažíte sa o to, alebo a ty sa snažíš o to, že posúva ten context switching a svyšie na ten management a ideálne ja to som teraz práve pochopil, tvojou hlavnou vôľou ako si povedal je context switching, tým pádom vlastne ty zachraňuješ ľudí, svojich ľudí pred context switchingom a presúvaš sa na seba na to vedenie, myslíš, že je to takto, alebo ak je to takto, myslíš, že to je dobré riešenie context switchingu? Nenazval by som to asi, že zachraňujem, to je, že viem, že ak by napríklad developeri, dizajneri, testeri mali veľa kontext switchingu, tak by neboli úplne efektívni v tom, čo robia a nebolo by to dobre pre celú firmu. Naopak pri projekťakoch, produkťakoch, portfolio manažéroch alebo akýkoľvek majiteľských roliach, tam sa tomu nedá úplne vyhnúť, lebo v podstate je nejaká bublina veci, ktoré treba spraviť. Čo najviac nech z toho urobia developeri a všetci ostatní, ktorí vlastne potrebujú robiť na jednotlivých projektoch a potom ostanú tie drobné, ktoré proste treba, aby všetko bežalo, aby sa veci manažovali, aby sme riešili problémy, aby sme.

[21:41] Predvídali problémy, aby sme plánovali čo v budúcnosti. Čiže znať, že skôr proste to sú tiež veci, čo treba aby niekto spravil a na čo vo firmách nemám ľudí, tak to spravím ja alebo to nespraví nikto. To je asi celá logika nad tým. Čiže môj mindset je skôr nastavený, že na všetko ideálne nájsť človeka, ktorého z odpovednosti je daná vec, tak aby to dávalo zmysel aj tomu človeku, aj nám. A ak niečo iné treba urobiť, tak potom už neostáva, ako keby nikto iný, kto by také niečo mohol spraviť. Ak to dáva zmysel, tak to. Ide aj o to, či sú to jednorazové veci alebo nie, že závisí to naozaj od toho. Ale akože vo všeobecnosti si myslím, že čím menej kontext switchingu, tým lepšie. A ja sa musím snažiť vyjíbať do takých milí, do akých sa dá. Niekedy je to nemožné a niekedy je to také, že výslovene, keď potrebujem niečo správiť na štýl niečo naprogramovať alebo spraviť nejakú špecifikáciu alebo naceniť nejaký projekt alebo čokoľvek tohto typu, tak si musím proste urobiť normálne.

[22:49] Kde viem, že mi tam nikto nedá žiadny meeting a budem mať proste x hodín času sa venovať jednej veci. A to je môj boj s context switchingom, že jednoducho na chvíľku ho nerobím. Myslíš, že sa dá povedať 3, 5, 10 rád ako bojovať s context switchingom? Na vyššej pozícii, ale súčasne nejaký programátor alebo nejaký človek? Neviem, či by som chcel úplne, že dávať všeobecné rady, ale to, čo funguje mne je delegovať, čo sa dá delegovať a spolahnúť sa na ľudí, že sú zodpovední, schopní a múdri a urobia to dobre. A netrvať úplne na tom, že všetko musí byť po mojom, lebo buď môžem veci robiť po mojom ja, alebo my s nimi môžeme pomôcť iní ľudia a bude to trošku ináč, ale stále dobre. To je také to, že niekto niečo urobí ináč, ja by som to urobil ináč, ale ono je to vlastne dobré v obidvoch prípadoch. Takže netrvať úplne na tom, že aby veci boli podľa mňa. Tu by som bol zviedavý, či by to tak povedali aj iní ľudia, čo ma poznajú, ale tak verím, že áno.

[23:52] Čiže delegovať, netrvať úplne na tom, aby sa veci robili podľa jedným spôsobom, ale proste nehať to na ľudí a dôverovať im. A potom si naozaj robiť nejaké fokus okna, keď človek potrebuje. Aj na úkor toho, že niekto potrebuje riešiť niečo súrné, no tak, nedá sa robiť všetko naraz. Takže nič lepšie asi nemám, že to je čisto v nejakom pragmatickom pohľade. Dobre, spomenuli sme pán Axel, ale nepovedali sme, čo to je. Kto to je? Predávate teplá rožky? Programujeme teplá rožky, áno.

[24:32] Predávame alebo teda vytvárame software na mieru pre rôznych zákazníkov z rôznych odvetví, čiže je to aj trošku generické, ale zároveň je to v podstate, vývoj softveru, tak ako si ho niekto zadefinuje, príde za nami zákazník a povie potrebujem takú a takú vec, my to vieme odhadnúť, nejak naceniť zamyslieť sa nad tým aj produktov aj technicky a dotiahnuť to v podstate od zadania do hotového projektu, alebo máme rôzne spolupráce, kde pracujeme priamo s zákazníkom a s jeho týmami na nejakom ich produkte a druhá väčšina vlastne našich spolupráci z zahraničia a naopak celý tým je v podstate na Slovensku, prípadne v Čechách a je nás okolo 70 a máme asi 5 rokov.

[25:19] A robíte remote alebo máte office? Všetky mieste ti sedíte viac menej. Áno, obidvoje správne. Robíme remote a máme 4 alebo 5 office-ov. S tým, že tie office-y sú naozaj skôr o tom, aby tam mohli byť ľudia, keď proste sa im nerobí dobré remote alebo, neviem, doma majú malé deti a lepšie sa im robí v kancelárii alebo sa len chcú stretnúť s kolegami a ísť s niekým aj na kávu na obed a tak. Čiže skôr to má ten socializačný faktor alebo unik zbytu než že by to bolo, že my na tom trváme.

[25:54] A my v podstate nemáme tie kancelárii dimenzované tak, že by sa tam zmestila celá firma, lebo, to by sa ani nevyužilo, to by bol úplný waste. A väčšina firmy vlastne robí remote, lebo nám to tak vyhovuje a vidíme v tom veľkú pridanú hodnotu. A zároveň máme pocit, že je to niečo, čo aj ľudia v nejakom bode už na to viac počúvajú, aj to trošku vyžadujú, aj si uvedomili, že v dobe rýchleho internetu a silného notebooku je to možno celkom dobrá cesta. Igor, keď sa bavíme vlastne o tom, že Panaxium servisuje teda rôznych klientov, tak tá diskusia bola, že je veľa legacy systémov pomerne, kde vy potrebujete ako keby, že prídete a neprepisujete alebo nenávrhujete nové riešenie, ale teda tá technológia je podrenia.

[26:54] Biznisu a to znamená, že vkladáte nové a postupne nejako refaktorujete. Čo je taký akože, čo sú také vaše best practices, ktoré ste sa naučili aby ste na legacy projektoch, možno že aj pre regulované odvetvia, alebo odvetvia kde je veľmi dôležitá bezpečnosť kde je veľmi dôležitá.

[27:17] Nelen bezpečnosť ako taká, ale aj bezpečnosť dát užívateľov.

[27:23] Aby ste boli vlastne úspešní v takýchto projektoch. Ja by som asi začal nejakým takým mindsetom, že ako na tým vlastne rozmýšľame, lebo keď bolo Panaxa menšie, tak som sa zúčastňoval väčšiny pohovorov, čiže za svoju éru som ich už urobil niekoľko stoviek. A s tým, s čím som sa veľakrát stretával pri hlavne mladších vývojároch alebo vývojárkach, bolo, že preferovali takzvané Greenfield projekty. To znamená, že projekty na zelenej lúke, čiže prídete a ono to tak pekne znie, že to môžete postaviť na nových technológiách a moderných technológiách a tie technológie včera vyšli a oni videli dobrý tutoriál alebo si o tom niečo prečítali a strašne to chcú niekde použiť a to je super, že to je dobré, že používajme nové technológie. Nechcem, aby to znalo, že nie. Len Greenfield projekt je Greenfield projektom v podstate prvých pár týždňov, možno pár mesiacov a potom vlastne sa už to stáva regulérny projekt, kde keď príde každý nový vývojar, tak už vlastne prichádza do niečoho, čo už niekto iný písal a musí nejako upravovať veci a chcem tým povedať, že trvácnosť tej vlastnosti, že je niečo Greenfield projekt, je relatívne krátka a väčšina úspešného softwaru je úspešný preto, lebo prinaša niekomu nejakú biznisovú hodnotu, zarába mu peniaze nejakým spôsobom slúži nejakým zákazníkom a.

[28:48] Z toho celého life cycle, toho životného cyklu, toho softwaru, tá Greenfieldová vlastnosť je prvých pár týždňov až mesiacov a tá celá hodnota leží niekde úplne inde v tom, v tej trvácnosti toho softwaru. Hej, že nikto si asi nekupuje nové auto každý mesiac, alebo rozhodne to nie je asi úplne bežný stav pre bežného človeka. Naopak, chceme niečo vybudovať a mať z toho hodnotu čo najdlhšie. No a z tohto titulu je tým pádom naši zákazníci sú práve tí, ktorí už majú niečo hotové, alebo väčšinou majú niečo a na tom chcú nejako stávať, chcú nejako rozširovať. Majú s tým nejaký problém a potrebujú s tým nejako pomôcť, alebo nemajú dosť ľudí a potrebujú viacej nárast, alebo riešia rôzne problémy, ale druhá väčšina projektov, na ktorých sme už existovali a my ich pomáhame nejako rozvíjať. No a ono to nie sú nutne len legacy systémy, samozrejme sú tam aj také veci, ale za mňa to umenie toho celého spočíva v tom vedieť takýto systém posúvať ďalej, nejak sa zamyslieť nad tým, ako funguje, povedať si, čo na ňom funguje, čo na ňom nefunguje a ako ho vlastne technologicky ťahať dopredu, tak aby sme práve nezostali na tých starých technológiách a aby sme tam mohli používať aj nové veci.

[30:05] Ale zase, aby to nebolo o tom, že teraz povieme zákazníkovi, že to máte celé zlé, to musíte celé zahodiť a my vám to napíšeme odznovu a lepšie a my to nenapíšeme odznovu a lepšie, my tam len vyrobíme nové chyby, tak ako každý jeden vývojar výraba proste chyby v tom softveri. Čiže za mňa je to o tomto mindsete, že proste pozrieť sa na to, čo funguje, stávať na tom ďalej a nerobiť ako keby waste na tom softveri.

[30:31] To je, ak sa hovorí, že každý riadok kódu je potenciálny potenciálny bug. Možno, že keď sa Čo? Keď si to nazval takto, že softwarový projekt má vlastnosť, ktorá je vlastnosť Greenfield, ktorá potom po meseci alebo dvoch už tam nie je. Čo sú tie vlastnosti dobreho softwarového projektu na to, aby sa s ním dal dlho pracovať, aby sa dal maintainovať, aby sa dal možno postupne refakturovať? Je ich veľa, ja ich určite nechcem hovoriť všetky, lebo nechcem úplne znieť ako kniha. Ja poviem také, čo sa nám posvedčili alebo ukázali ako tie problémové a na ktoré je dobre sa za mňa zamerať. Je lepšie, keď sa nebavíme o jednom veľkom softveri, ale o veľa menších softveroch. Dáva to určitú slobodu v tom, ako sa ten softver potom dá posúvať dopredu technologicky, lebo keď máte jeden veľký komponent, ktorý má proste, kopu histórie v sebe a treba ho nejako meniť, tak väčšinou ten zásah spôsobuje, veľa, alebo teda má vplyv na veľké časti toho systému. Keď máte viac menších komponent, či už sa bavíme o mikroservisoch alebo o serverless spôsobe, tak viete meniť menšie celky, uchopiteľnejšie celky, ktoré sú možno menej previazané a dokonca máte aj návyber v tom, že.

[31:58] Špeciálne pri serverless spôsobe alebo pri mikroservisach, vy môžete kľudne každú jednu z tých servis napísať aj v inom jazyku. Nehovorím, že by som toto odporúčal, len hovorím, že že zrazu tam vznikajú aj takéto možnosti. A niekde dávnejšie som čítal, že napríklad Facebook celkom ťaží z takéhoto niečoho. Oni sa ani nepozerajú úplne na to, či niekto Python vyvojá C Sharp alebo Java alebo čo. Proste píš kód v tom, v čom vieš a napíš komponentu a proste niekto iný po tebe napíše v inom jazyku. To je možno extrém.

[32:31] Až taký kouboj by som možno nebol. Ale rozhodne tam vzniká menej prepojení a je jednoduchšie alebo teda je, je uchopiteľnejšie, treba spôsobať technologicky takýto projekt dopredu. Samozrejme sú tam zase možno aj iné problémy, ale neexistuje úplne silver bullet riešenie na tento problém. Čiže toto je jedna vec, že rozbiť to proste, alebo teda uchopiť to ako menšie celky. Čiže napríklad, keď aj stávame nový projekt, tak sa nad tým zamýšľame skôr týmto spôsobom, než by sme robili jeden veľký monolitický systém. No a veľa automatizácie, čo sa týka deploymentu, automatických testov a podobne, to je niečo, čo sa ukazuje ako proste kľúčová vlastnosť každého dobrého projektu. Proste eliminovať buildovanie u ľudí. Na čo to majú robiť ľudia, keď toto sa dá krásne zautomatizovať. Rozmýšľam, čo by som tam spomenul ešte.

[33:30] Nejaké riešenie incidentov v produkcii je veľmi jednoduchšie, keď máte správne veľmi dobré logovanie v zmysle ani všetko, ani nič, hej, že ani jeden extrém, ani druhý, ale proste, že sa tie logi nejako rozumne zbierajú, že sa naozaj dajú pozrieť a že to nie je také, že ja vlastne netuším, čo sa v tej produkcii deje, hej, že stretávame sa aj s takýmito vecami.

[33:53] A kľúčová vlastnosť tých veľa malých komponentov je, že ako vedieť povedať, že keď sa niečo udeje naprieč tým systémom, takže tie veci spolu súvisia, čiže že nejaká, ono sa to volá, že traceability, to znamená, že viem povedať, že keď mi nejaký request, alebo nejaká požiadavka niečo tečie cez veľa malých komponentov, tak vedieť ju nejako poprepájať, že toto je ona a toto spolu súvisí. Takže takéto veci sa ukazujú celkom ako zaujímavé a je ich tam milión ďalších. Mne to príde ako taká skratná verzia Clean Code. Neviem, či si čítal. Poznám, poznám pojem. Čo je pre tých starších, no starších, pre tých programátorov, ktorí začali, povedzme, že na začiatku tohto storočia a nie na začiatku tohto desaťročia. A nedávno tak je to už pomaličky automatika. Ale veľa ľudí to nepozná. Že ten Clean Code pekne opisuje nejakú moduľu. Dekuplovanie. A menej dependencies a takéto veci. Áno. Tá literatúra existuje, že to nie sú nové veci, hej, že to je skôr, že reálne ich treba aj používať, lebo dneska, existuje, že je extrémne veľké množstvo kurzov, YouTube-tutorialov, kadečoho a ľudia majú, že množstvo proste veci, ako sa vedia ponoriť do programovania, len.

[35:13] Nie každý ide nutne do hĺbky a nie za každým je nutne to rozmýšľanie a to reálne učenie nastáva, až keď niečo beží v produkcii a my vlastne ten systém musíme nejakým spôsobom sa o nej starať. Že to reálne niekto používa a tam vznikajú nejaké problémy. Nie je len o tom, ako je ten výsledok. Niekto chce mať iba delivery, klient vidí, je to funkčné, je to klikateľné, je to použiteľné, robí to, čo má, ale nie je to len o tom. Je to aj o tom o tých črevách, čo je vnútri a čo je za pozadí. A to je niekedy tvojitejšie a podstatnejšie, ako že to naozaj funguje v danom čase. Určite áno. Čo je zaujímavé, že teraz sú firmy, ktoré hlácajú návrat k monolitu.

[36:01] Rieši to niektoré problémy. Máš na to ty, Igor, nejaký názor? Alebo je to tak, že ty máš tú svoju preferovanú stranu, nejaké, nazývame to microservisy, aj keď to vôbec nemusia byť microservisy, ale ide o to len, že je to nejaký komponentový systém. Akokoľvek už komunikujú a je tak aj manažovaný, pričom obrovský benefit tam je hlavne z tej automatizácie, že bez tej automatizácie asi to môže byť veľký pain in the ass. Ak som sa niečo naučil za celú tú dobu, tak to je, že nech spoliehať sa na jeden typ spôsobu, patternu, technológiu alebo niečo také, lebo presne ako hovoríš, že kedysi monolit bolo jediné a hlavné riešenie a tam sa narazilo na škáľovateľnosť, prišli microservisy, tie priniesli vlastne nové problémy, ale aj vyriešili niektoré staré. A dneska zase, ja už tiež som akože počul aj to, že však monolit vlastne je riešenie, lebo však servere zase trošku zosilňali a tak, ale tam sa zase vrátiť, tam sa zase vrátiť k tej škáľovateľnosti.

[37:09] Ja to mám podobne zase, ja som vlastne začínal ako webový vývojar, hej, a kedy si sa začínalo PHP-čkom a toto vyplúvalo HTML-ko a to sa načítalo do browseru, potom sa zistilo, že browsere sú silné a ľudia majú silnejšie notebooky, tak poďme pušťať javascriptové single page aplikácie a dneska je zase v mode server-side rendering a je to jak nová fíčura, keby to existovalo a pritom tým sa to zase začalo, hej, čiže.

[37:35] Ono sa, ono je to taká sinusolida, že proste niečo sa používalo, potom sa to zmenilo, teraz sa zase k tomu vraciame a to isté je s tými monolitmi, čiže za mňa to nie je ani tak o tom, že čo je lepšie, lebo tam sa dostaneme do debaty, že že ja si myslím a ty si myslíš a niekto iný si myslí. Za mňa, ja sa na to pozrám, že úplne ináč, že nám zákazníci povedia, že máme takýto problém a mojou úlohou je dať im na to, čo najviac kostefektív riešenie, ktoré vyrieši ich problém. Ak to bude monolit, tak to bude monolit, ak to budú mikroservisy, tak to budú mikroservisy. A my nemáme jedno jediné riešenie na všetko. My máme sádu nástrojov, ktoré nejako proste používame a pod nástrojmi nemyslím len programovacie jazyky, myslím tým postupy, myslím tým spôsob manažovania projektu, myslím tým spôsob nasadenia do produkcie, myslím tým spôsob preváckovania v produkcii a tak ďalej. A na toto vroste máme ako firma nejaké postupy a podľa toho, aké je zadanie a aký je problém, vyberáme technológiu, postup a tak ďalej. A to je za mňa jediný správny spôsob, ktorým budem ja nejako rozmýšľať, lebo to znamená, že sa prispôsobujeme a využívame svoju expertízu na to.

[38:44] Keď sme sa bavili teda o tých ešte properties, ako keby systémov, ktoré, aby sa dobre dali spravovať, vyvíjať, aby sa dobre vývojárom s nimi pracovalo, tak čo sa týka automatizácie, buildov, riešenie incidentov v produkcii, logovanie traceability, čo sú tvoje preferované nástroje, hej? Robíte s tým, čo treba, ale keby si si mal vybrať a vyskladať vlastne taký stack pre tvoj ideálny projekt. Čo by tam... Keď ide... Jeden typ projektov, s ktorým sa stretávame je, že menší zákazník v zmysle živnostník, malá firma alebo niečo podobné, väčšinou ne-IT firma, to znamená ľubovoľné iné odvetvie, chce mobilnú aplikáciu, ale, to vie byť celkom nákladná vec, treba sa o to starať a tak ďalej. A väčšinou ku každej mobilnej aplikácii treba nejaký back-end alebo proste niečo, čím ju naplníte, z čoho čerpa dáta, kam niečo uploaduje a tak ďalej.

[39:48] Nestredol som asi už dávno mobilnú aplikáciu, ktorá by nemala nejaký backend. No a na toto používame Firebase ako backend od Google, čiže to je vlastne taká, nadstavba nad Google Cloudom, respektive také zjednodušenie Google Cloudu, lebo Firebase je v podstate čistý Google Cloud. Tam práve používame serverless, to je jedno z tých riešení, že veľa malých ich komponentov, lebo môžete si predstaviť, že každý endpoint, každá URL adresa, alebo každé nejaké volanie je samostatná JavaScriptová funkcia, ktoré sa dajú deplejovať nezávisle, ktoré fungujú nezávisle, robia z jednou databázov, ale je to veľmi príjemné v tom, že píšete veľmi maličké kúsky kódu, ktoré proste niečo robia a tak. Čiže backend je Firebase, Firebase funkcie, Firestore databáza, alebo nejaká SQL databáza a.

[40:40] Firebase projekt potrebujete tak, či tak, ak robíte mobilnú aplikáciu kvôli push-notifikáciám a keď už ho máme, tak prečo nevyužiť aj tie ostatné veci, čo ponúka. A platí sa podľa toho, ako sa využíva. Čiže keď sa využíva málo, tak vie to byť aj zadarmo. Keď sa využíva viacej, tak sa platí podľa použitia a samozrejme je na našej šikovnosti, ako efektívne napíšeme ten systém, aby bol šetrný k tým zdrojom.

[41:05] Čiže jeden z bežných technických stackov, ktoré používame na takéto typy projektov, že mobilná aplikácia vo Fluttery, aby bola na obidve platformy, aj Android, aj iOS. A k tomu Firebase-ový backend, ktorý proste rieši čokoľvek, čo treba v rámci tej mobilnej aplikácie na prepojenie, naplňanie dát a tak ďalej. Potom máme veľké projekty, kde robia niekedy desiatky ľudí pre rôzne firmy a tam sa väčšinou spoliehame buď na .NET ako backendový stack, kombinovaný buď s Reactom alebo s Angularom na frontende. Obydve sú vlastne robustné frameworky, dlhodobo používané. Zadodne to mají Microsoft, to znamená všetko stabilných hráčí a má to vyriešené asi všetky problémy, ktoré by sme mohli riešiť, takže vieme, že o tej technológii sa proste vieme oprieť a že tam proste sú a sú dobré. A prípadne ešte potom používame Node.js, TypeScript na back-endy, React, Angular na front-endy. To je taký náš najtypickejší stack, tieto dve veci. No a na mobilnom svete buď natívny vývoj v Kotline, alebo v Swift, alebo kombinácia vo Fluttery.

[42:19] A kde je ten LEGO Python? To je v mojom srediečku iba. To je moje hobby. Čo sa týka natívneho vývoja a flatru, tam je tvoj take aký? Versus teda flater. Pragmaticky.

[42:39] Flater, React Native prešli dlhou cestou. Keď si bol poznať rozdiel v performance v aplikácii, ktorá bola urobená takýmto spôsobom versus natívnym.

[42:53] Dnes ten rozdiel už taký nie je. To znamená, keď urobíte flater aplikáciu s pekným dizajnom, tak je veľmi ťažké spoznať, že to nie je natívna aplikácia v praxi. Bude rýchla, bude svižná, bude pekná, bude mať pekné animácie a bude napísaná jednou codebase na dve platformy, čo je niečo, čomu sa ťažko argumentuje z ekonomického hľadiska. Môj osobný názor, samozrejme, nejak už nemám kryštálovú gulu, ale môj osobný názor je, že toto nie je niečo, čo sa dá úplne ignorovať.

[43:27] Každému jednomu zákazníkovi záleží na tom, koľko jeho projekt stojí a koľko ho to bude stať a ako sa to udržiava. A ťažko sa vysvetľuje, že tu vám niečo naprogramujeme dvakrát v dvoch rôznych technológiách, keď sa to dá urobiť raz. Hoď samozrejme nie je to úplne ako, že netamatika nie je, že je to dvakrát rýchlejšie, ale je to rýchlejšie. Takže môj pohľad je čisto pragmatický a je to o tom, čo sme schopní predať, tak aby sme boli konkurencieschopní a ak to splnia všetky technické náležitosti, tak prečo to nepoužiť. Ešte si spomínal o jednom z takých mojich obúbených vecí, čo sú tracings. Keď nevidíš, ako funguje produkcia, čo je v produkcii, tak si v princípe máme pohľad o slepy a nevieš pomaly ani pokračovať s vývojom. Nie, to je úplne slepá cesta za mňa. A že tak o logi a tracing. Máš nejaké tooli, alebo nejaké koncepty, alebo nejaké prístupy, ktoré rád používaš? rádi používate ho? My sa spoliehame do veľkej miery práve na klaudy, to znamená, či už Amazon alebo Google Cloud, tak oni tieto tooli v sebe majú.

[44:35] Napríklad pri tom Firebase-i mne úplne stačí ten toolkit, ktorý je v rámci Google Cloudu. Tam sú veľmi podrobné logiky, ktorá funkcia kedy zbehla. V kóde si viem napísať, čo potrebujem zalogovať a kedy a ako. A je to robustné, je to prehľadné, dajú sa tam dať spoločné identifikátory, aby keď nejaká funkcia púšťala inú funkciu a dá pušťaľa inú funkciu, tak to celé bolo tradisované dokopy ako jedna cesta. Čiže Amazon a aj Google to majú vyriešené relatívne dobre.

[45:07] Nebojíte sa v rámci projektov vendor locku? Napríklad toho Firebase, že jednoducho zrazu vám klient zauva, že no zrazu máme viac klientov, používateľov, ale ten bill z Google prišiel extrémne vysoký, musíte to ťať. Ako všetko je to trade-off, že, malé projekty robiť cloud agnosticky, čiže tak, aby boli nezávislé od toho, na ktorom k laude bežia, je za mňa nerentabilné pre tú malú firmu. Takže ja na ich mieste by som do toho aj neinvestoval, lebo ak majú malo zákazníkov alebo ak je to menšia firma, tak sa im to proste neoplati, že to je drahá vlastnosť softveru. Pre väčšiu firmu sa niekedy môže dokonca oplatiť aj nebyť len na klaudie, ale mať naozaj nejaké vlastné, či už dedikované virtuálne mašiny alebo nebude aj fyzické železo. Viem si predstaviť, že je tam nejaká matika, ktorou sa dá dosiahnuť, že možno to vychádza aj lacnejšie, ale to sa bavíme o genetickej škále. A ja si zase nemyslím, že je to taký problém, lebo ak niečo raz nápišem cez Firebase funkcie.

[46:18] Takže nemyslím si, že je to až tak výrazný rozdiel oproti Lambda funkciám od AWS-u, prípadne keby som chcel ísť do nejakého open source-ového riešenia ako je Supabase alebo niečo podobné. A jasné, stojí to nejaký čas. Treba si proste vždy zvážiť, či je pre mňa dôležité byť cloud agnostik, alebo optimalizovať tie kosty pri tom vendorovi, ktorý mám, ktorého mám. A môj názor je, že keď už som u nejakého vendora, tak ja chcem z neho využiť čo najviac toolov, lebo vlastne tam ja hľadám tú efektivitu a oni to dobre vedia, oni tak tie tooly robia. Oni chcú samozrejme, aby sa tam ľudia čo najviac do toho zainvestovali a boli čo najviac akože používali ich tooly, ale to nie je len tá zlá vlastnosť toho, to je aj tá dobrá, lebo ak sú tie tituly dobré, tak reálne nám prinašajú nejakú efektivitu. Čiže dá sa skladať aj z rôznych klaudov, dá sa skladať aj, že nebude to na žiadnom klaude, bude to na Kubernetes a budem si ten Kubernetes niekde prevádzkovať, lenže tým si pridávam nové kosty. Niekto musí prevádzkovať ten Kubernetes, niekto sa o to musí starať a teraz otázka je, stojí mi tento kost za to, že som loknutý alebo nie som loknutý? To je celá rovnica. A môže byť tak aj tak. Čiže to je o tom, že čo je pre mňa dôležité. A jedine čo, my vždy zákazníkom toto vysvetľujeme, že takáto je situácia, toto sa deje, takéto to má trade-offy, toto je benefit, toto je podmienka, čo s tým ide ruka v ruku. Ja si myslím, že nie je to taký ortodoxný. Nie, lebo.

[47:48] Už sme sa stretli s tým, že niekto proste potreboval mať väčšiu kontrolu nad tým, musel splňať možno nejakú legislatívu, alebo čokoľvek a tým pádom viac si veril vlastným virtuálnym mašinám, sú hostované zase v nejakom datacentre. Čiže kam chceme ťahať ten vendor lock-in, lebo, Keď máš servere v konkrétnom datacentre, je to vendor lock-in, alebo akože môžem ich preniesť niekde indzie, zase stojí nejaká peniaza. Tak hej, ten effort, ktorý musíš spraviť, aby si preniesol... Presne tak. Je trošku iný. Má to, ako hovoríš, trade-offy, že musíš niekde investovať. Preto by som to nechcel uzavrieť jednoznačnou odpoveďou, lebo za mňa to proste záleží od konkrétnej situácie a od toho, čo si ten človek alebo zákazník vlastne viac cení. Či je pre ňo cennejšie nebyť loknutý na vendora, alebo naopak zoptimalizovať náklady. Ty si spomínal, že si začínal ako webdeveloper. Vedel by si popísať, ako si ty začal s programovaním a možno aj načeknúť, ako vznikol samotný plan Axel? Jasné. A ja by som možno ešte tam pridal to, lebo ty si vlastne spomínal, Igor, že po skončení vysoké školy už si mal vlastne 8 rokov práxe alebo také niečo, takže.

[49:06] 6 tuším, ale presne to nedorátam asi ja som rád nezačal s takým, že programovaním za peniaze v zmysle na strednej škole na strednej škole som vlastne robil prvé projekty také, že niekto mi za to niečo aj zaplatil a tým pádom to rátam ako už nejakú takú začiatočníckú prax a v podstate počas celej výšky som reálne pracoval a venoval som sa vlastne jednemu aj druhému. Tam vlastne začala moja kariéra kontext výčinku.

[49:39] Takže študoval si medicínu, študoval si medicínu, veterínu a to už naprogramoval. To nie, to bol matfiz, denne štúdium a popri tom vlastne práca. No a to programovanie ťa bavilo veľa evidentne, hej? Stále ešte programuješ? Stále ešte programujem, ale je to oveľa sporadickejšie ako v minulosti, že nie je to proste môj full-time job. Je to, že musím si tu a tam ukradnúť nejaký čas zo svojho iného času na to, aby som sa k tomu dostal. Ale zase o to viac sa snažím byť efektívny. To znamená, že o to menej sa s tým vyslovene tak, že zabávam. Že teraz skôr fungujem asi v takých režimoch, že, Ja si najprv relatívne presne premyslím, čo chcem naprogramovať, ako to chcem naprogramovať, že v podstate to najprv vymýšľam, aby som si potom skôr len sadol za ten kód a napísal čo najviac z toho. Ono sa to samozrejme nedá, že niečo zistím až počas toho, jak to programujem, ale napríklad pri tom vývoji hier sa celkom dá vymyslieť veľa stejmatiky pred tým, ako to reálne začnem písať a potom až opravovať nejaké chyby, ktoré z toho vzniknú.

[50:50] Ja som vlastne začal ako webový vývojar. to bolo front-endy, back-endy, PHP, HTML, CSS, JavaScript, jQuery také veci, jQuery myslím dneska ešte stále existuje, ale neviem a dokonca je ešte aj celkom silno používané ale nie som si istý, či je to zrovna niečo, čo si vyberajú ľudia na nové projekty musel by som sa pozrieť do nejakých štatistik, A tak určite, keď si vezmeš nejaký WordPress, čo je možno najpoužívanejší tak určite, alebo takéto nejaké frameworky, jQuery, silnú závislosť a oči je to najzťahovanejší NPM projekt, to asi nebude. Neviem, ale niekde čítam teraz, že je to nový článok z januára 2020-2024, že je to stále top JS library, aj keď je to ma neprekvapuje, ale asi kvôli tomu WordPressu. Je to podľa Stack Overflow Survey že je 22-23 Stack Overflow Survey je jedno z najlepších, ktoré sa robia, lebo je naprieč celým sovietom a naprieč všetkými technológiami a oni majú 10 tisíce respondentov, čiže je aj relatívne presná. Abo teda je to také, že je to jeden z najväčších takých zdrojov týchto dát. A tam som práve v tej poslednej mysli čítal, že JQuery je stále akože celkom dobrý hráč. Ale to boli moje začiatky vlastne. Potom tam bol Ruby on Rails, nejaký vývoj. No a dneska, keď niečo programujem, tak je to buď C Sharp v Unity.

[52:18] Alebo nejaký Node.js-ový serverlessový backend, prípadne nejaká frontendová vec?

[52:25] Tentú afinitu ľudí k JavaScript TypeScript kombu a teda akože aj Node.js a potom Next si veľmi všimám, že aj je to z pragmatických dôvodov, že ľudia na to prechádzajú, aj keď nie je to o tej prepoužiteľnosti, ale čo by ma zaujímalo, si spomínal, že bol si či Rubičkár a tak ďalej. K tomu C-Sharpu si sa dostal vyslovene kvôli hrám, alebo tam bol aj nejaký iný dôvod? C-Sharp má u nás celkom silné firmné zastúpenie, ale ja som sa k nemu dostal paradoxne skôr kvôli hrám. Ale aj mi to celkom teraz výrazne pomáha, lebo vlastne rozumiem tomu ekosystému a uľahčuje mi to nejakú prácu v rámci Panaxeo. No a ako si sa vlastne dostal z toho univerzitného kontekstu výčingu v práci na založenie firmy zase?

[53:21] Programoval som, potom som bol projektový manažér, potom som bol engineering manažér a v nejakom bode som si povedal, že ma baví riešiť vlastne celý taký nejaký životný cykl kus toho softwaru, aj po nejakej salesovej rovine, aj po nejakej manažerskej rovine. A uvedomil som si, že ako jednotlý vec viem urobiť projekt o nejakej veľkosti, ako projekt o trošku väčšej veľkosti a ak by som chcel robiť ešte na väčších projektoch, tak vlastne na to potrebujete väčší tým ľudí so všetkým. A nejak ma to prírodzene ťahalo k podnikaniu, že.

[53:56] Dáva mi to najviac zmysel v kontekste mojej práce, že ja som sa v každej práci, že či som bol zamestnanec, alebo proste či robím vo svojej firme, tak ja robím tým istým spôsobom, že ja na tým nerozmýšľam ináč. Alebo, že keď som bol u niekoho zamestnaný, tak som nerobil iným spôsobom, ako robím teraz.

[54:17] A vždy do toho dávam, čo sa dá. No a tým pádom mi dávalo aj zmysel možno skúsiť podnikať a nejak to funguje už v posledných 5 rokov. To sú teda tvoje profesionálne začiatky, aj cesty a súčasnosť. A ja by som sa ešte možno vrátil, lebo mali sme tam dve dobré témy, keď sme sa bavili minulé, že jednak Legacy Monolity to sme si a mikroservisy to sme si trošku prešli, ale ty si hovoril o... Veľa, alebo si načrtoval aj, že veľká téma pre teba je vlastne akože defenzívne programovanie, čo rovnako ako hovoríš, spomínal knižku Clean Code alebo Dokonalý Code, tak myslím, že je tam čo je defenzívne programovanie spomínané v obidvoch, alebo minimálne v jednej z tých kníh. Ja sa priznám, že ja neviem, či to je pojem. Ja to tak volám z natóry toho, čo to je. Je to, podľa mňa, akože je to reálne, je to pojem a je to way of thinking kým zasa, hej, alebo nejaký spôsob, ako nad tým rozmýšľať, myslím, že to je úplne validná, validná, validný mindset, aby som to takto nazval, ktorý možno, že nie všetci poslúchači, sú na ňa, sú s ním oboznamení, ale tá úplná pointa je, že treba byť superparanoidný, hej, ale.

[55:45] Zasa chceš aj nejakú produktivitu. Ako sa ty teda pozeraš na tie defensívne? Tak to, že ja len chcem povedať, že ja som nebol istý, alebo teda nevedel som to teraz, že či to je reálny pojem, že ja som tak volal jeden štýl, ktorý sme použili v konkrétnom projekte a súvisí to naozaj s tým, že je to trošku také paranoidnejšie programovanie, kde počítaš s tým, že každý riadok kódu je bug a potenciálne môže spôsobiť problém a ten projekt si ho vyslovne vyžadoval, čo môžem spôsobiť za chvíľku. Ja sa len ospravedlňujem, že ak je to reálne nejaký pojem a ja teraz vlastne po tým pojem niečo úplne iné, tak aby z toho znevniklo, že vlastne tu predefinovali pojmy, že toto znie. Ja som to vyslovene použil ako pojem na štýl, ktorý sme nejako použili, ale znie mi to z toho, čo si povedal, ako vlastne podobný alebo rovnaký mindset. Vieš to zadefinovať z tvojho pohľadu? Zábudni, že sme ti povedali niečo a teraz iba poď písať. Ja som to použil pri jednom projekte, kde išlo o to, že sme programovali mobilná SDK-čka a celá pointa toho je, že mobilná SDK-čka je niečo, čo je vlastne kus kódu, ktorý si niekto môže integrovať do svojej mobilnej aplikácie, aby získal nejaké funkcie navyše, ale v podstate sa na to dá pozerať ako na nejakú knižnicu tretej strany. No a teraz problém je, že keď my urobíme chybu v takomto SDK-čku, že tam proste spravíme nejaký bug.

[57:09] Tak najprv to uvediem napríklad, že v webovej aplikácii, že keď urobíme chybu vo webovej aplikácii, tak ju opravím, redeploynem a všetci, čo ju používajú hneď alebo do hodiny, alebo do desiatich hodín, alebo do pár hodín, proste môžu používať bez tej chyby. Keď urobím chybu v klasickej mobilnej aplikácii, už to prechádza cez nejaký App Store review, cez App Store, cez Google Play Store, už sa na to pozera nejaký externý človek, oni vám garantujú alebo negarantujú, že koľko to bude trvať, v lepšom prípade dve hodiny, v horšom prípade tri mesiace, už sme sa stretli naozaj, že skáde čím a.

[57:45] Najdlhšie zakladanie App Store účtu bolo tuším 8 týždňov. Apple vymýšľal nejaké veci. Takže chcem tým povedať, že sú tam také veci, ktoré sú mimo nášho dosahu a tým pádom, keď urobíme chybu v mobilnej aplikácii, už tu prechádza takéto niečo, no a potom vy nemáte zaručené, že ľudia si hneď stiahnú ten update. Niekto si ho stiahnuje niekto, niekto si ho stiahnuje o týždeň, niekto si ho stiahnuje o mesiac a niekto si ho nestiahnuje nikdy. Hej, čiže to je realita. No a teraz, keď vy urobíte chybu v mobilnom SDK-čku, ešte o stupeň ďalej, tak kým sa to mobilné SDK-čko, tá nová verzia dostane do všetkých mobilných aplikácií, kde je používané a tie sa všetky tým procesom, čo som práve popísal, dostanú k zákazníku a tak ďalej, tak nejaké dáta, ktoré sme mali k dispozícii, nám ukázali, že niekedy trvá aj 6 mesiacov od opravy našej chyby, po to, kým tá opravená verzia mobilného SDK-čka je majoritná verzia medzi všetkými užívateľmi. Čiže je najviac používaná. Nie, že ju všetci majú, ale že je len najviac používaná. 6 mesiacov je príša nedlhá doba. To znamená, v preklade čo to znamená, je, že robiť chyby je extrémne drahé. A ako náhle mi niekto povie, že robiť chyby je extrémne drahé, tak to znamená, že ja musím urobiť všetko preto, aby sme ich čo najviac nerobili. Lenže všetci vieme, že proste za mňa je proste zrejme, že že nedá sa nerobiť chyby.

[59:04] Poviem taký príklad, že ešte aj Boeing má teraz problémy softwarového charakteru, práve preto, že je to ťažké, samozrejme, oni majú problémy aj so šobikmi teraz, ale určité problémy mali aj v tom softveri, kde by sme čakali, že lietadlo, že tam nechce mať žiadny bug nikdy.

[59:22] Alebo keď nás sa robí raketoplán, tak tam si nemôžu dovoliť mať proste bug, ale ich odpoved na to nie je nemať bug, ale mať tam tri záložné systémy. Že oni nikdy nevedia, že proste ktorý kedy vypadne, preto ho tam dajú trikrát proste.

[59:38] Čiže tento štýl mindsetu je niečo, čo som ja nazval akože defenzívne programovanie a to je, že nie, že nerobme chyby, ale dajme tam ešte 5 safety netov, ktoré každú našu chybu niekde nejako proste zachytia a niečo s ňou robia. Čiže to, čo sa reálne stalo je, že v tom mobilem SDK-čku sme neprestali robiť chyby, lebo to sa nedá, ale spravili sme tam vlastne takú nejakú ochrannú vrstvu, že keď sa tam niečo aj pokazí, tak by to malo silently failnúť. Čiže tak, že to exploduje v rámci tej mobilnej aplikácie, obrazne povedané, ale nezoberie to zo sebou celú tú mobilnú aplikáciu a nestiahne ju to ku dnu. A to je jedna z tých point, že keď sa niečo aj pokazí, tak je lepšie, keď to silently krešne, ako keď to ešte užívateľovi zhodí apku a povie mu to, že prepačte, aplikácia prestala fungovať a tak ďalej. No a na to, aby takýto safety net nejako fungoval, tak tam presne predpokladáme, že všetko môže failnúť. Aj to, čo nemôže failnúť, môže failnúť. Aj keď predpokladám, že ste videli niekedy nejaký kus kódu, tak keď máte nejaké riešenie vynimiek, hej, try, catch, tak aj ten catch blok môže reálne failnúť.

[1:00:55] Čiže to nie je, že dobre, dám niečo do try-catchu, ale čo keď v tom catchí sa niečo zle stane, tak tam treba zase niečo vymyslieť. No a tento štýl mindsetu sme vtedy som si povedal, že to je proste také defenzívne programovanie. Alebo keď mobilná aplikácia niečo ťaha z back-endu, tak jeden spôsob je, že má napevno nadefinované, že očakávam, že prídu takéto dáta a stačí, že jeden field je iný, alebo nul, alebo niečo a už sa mobilná aplikácia k tomu nevie nejako postaviť. Pričom možno si mohla len domyslieť tú hodnotu alebo mohla proste nebyť tak rigidná v zmysle, že očakáva presnú dátovú štruktúru, ale čo keď nepríde napríklad jeden field, hej? A toto je napríklad veľmi dobré pri mobilných aplikáciách je toto veľmi dobré, hlavne vtedy, keď potrebujete udržiať viacero verzií.

[1:01:45] Ak mobilná aplikácia ťaha z back-endu nejaké dáta, čaká nejakú štruktúru a teraz zrazu nepríde niektorý z tých fieldov, tak z môjho pohľadu je lepšie, keď to nejakým spôsobom buď odignoruje, alebo treba zniezobrazí nejakú časť dát, ale nemále by krešnúť. Lebo vy, keď udržujete mobilnú aplikáciu pri živote, aj back-end tiež, tak buď ten back-end držíte späť nekompatibilný, čo býva náročné, alebo ho musíte verziovať, čo znamená, že držíte niekoľko endpointov rôznych verzií, čo je zase náročné. Pričom možno stačilo tú mobilnú appku spraviť trošku defenzívnejšie, čiže keď nepríde nejaký field, tak sa z toho hneď nezrúti. To je tá výhoda a nevýhoda silnej typovosti. No ale to nie, akože typovosť je jedna vec, ale vy viete aj silne typový programovací jazyk napísať tak, že keď tam tento field nie je, tak proste OK, tak ho len nezobrazím v nejakom výpise dát alebo niečo. Ak to nepokazuje samozrejme nejakú integritu, len hovorím, že tento mindset je niečo, čo umožní ľuďom potom to API trošku voľnejšie upravovať a nie je to proste o tom, že, pane Bože, my z tohto endpointu nemôžeme ani len odstrániť jeden field, lebo rozbijeme, 5 živých verzií aplikácie.

[1:03:00] To je akože tá myšlienka za tým, že to je to, čo volám defenzívne programovanie, to je proste, že predpokladám na nič sa nespolieham a snažím sa nekrešnúť. Tak by som to zhrnul. A na druhej strane, že tu si mám predstaviť, že potrebuješ vlastne extrémne silnú práve tú, ten logging a traceability, alebo nejakú telemetriu, pretože ty síce akože nekrešuješ, na druhej strane chceš vedieť o všetkých týchto o všetkých týchto ako keby, potlačených krešoch, aby si bol schopný.

[1:03:34] Meanwhile pracovať na tom, že to vytúniš. Ideálne áno, ak to má byť rozumná telemetria, tak ak chcete ju zbierať, tak tam sa potom väčšinou robí nejaký sampling, to znamená, nezbierate každú jednu vec, ale proste každú tisícu pri nejakej škále, lebo vlastne si myslíme, že keď sa urobí len sample z nejakej celej populácie, tak to podáva obraz, ak je to náhodné.

[1:04:00] Ale áno, akože v zásade to sedí tak, ak si to povedal, že proste chceš vedieť aj o tých prípadoch, ktoré akože sa nesprávali úplne štandardne a, najviac je to práve pri tých mobilných aplikáciách, kde malokedy sa drží backend pre jednu verziu, ale väčšinou sa drží pre 3-4 proste staršie verzie že, keď vám tretina zákazníkov beží na starej verzii, tak buď ich donutíte k updatu nejakým forced updatom, že im zobrazíte okno a proste buď si updaten, že alebo sa nedá používať apka, ale zase to nie je nutne vždy preferované, to si môžu dovodiť možno bankové aplikácie, ktoré akože potrebujú, aby mali pod kontrolou ten update proces, ale bežná aplikácia by nemala moc úspech, keby furt takto nutila usera. Že predstavte si, že si otvoríte YouTube a furt sa nám zobrazí, musíš si uploadať na novú verziu, lebo neviem, my sa nechcelo upravovať back-endy. Len, aby som pochopil, ale pri nejakých akože error reporting-och, alebo že ja neviem, vám nejaké nejaké exceptions loguje, tak tam asi sampling nerobíte. Či aj tam dáva zmysel robiť sampling? Jasné. Z môjho pohľadu už dýdava robiť sampling, keď už je userov toľko, že.

[1:05:21] Ako keby neoplať, že ak mám tisíc userov, kľudne sa dá zbierať všetko, ale ak mám milión userov, tak nemá zmysel zbierať kreše proste z milióny úzrov, lebo aj bugy väčšinou v produkcii sa neopravujú tak, že mám bug, okamžite ho ideme opravovať. Všetky aplikácie, ktoré používate aj dneska, majú milión bugov, len väčšinou o tom proste neviete, lebo buď krešnú Silently, alebo krešnú, vy ich zapnete znovu a nerešíte, idete ďalej. A tie firmy neopravujú ten bug, že tu mám jeden bug, tak ho idem opraviť. Oni si pozrú, že tu mám 20 reportov, tento má výskyt 200 tisíckrát, tento má vyskyt tisíckrát a tento má vyskyt dvakrát, tak ten, čo má vyskyt dvakrát, je tak drahý na opravu, že to nikto nikdy neopravi. A tiež je tam vysoká podmnoženosť, že sa opravi aj sám nejakou aktualizáciou alebo nejakou inou zmnoženosť. Pretože to je pravda. Hej, hej. V závislosti od škály, koľko má aplikácia užívateľov, niektoré problémy, keď proste, že ak má, poďme príklad, tak má apka 200 tisíc užívateľov a dvaja majú bug v nejakej situácii a keď je refrešli apku, tak apka funguje ďalej. To nikto nikdy nebude riešiť a hľadať, lebo cena toho bugu proste, že oprava toho bugu je nerentabilná a v podstate úplne zbytočná. Naopak, keď má z 200 tisíc ľudí 2000 ľudí bug, to už je tak vysoké percento, že to samozrejme niekto musí opraviť a čo najskôr a najrychlejšie.

[1:06:43] Ja sa vrátim späť k tej téme toho defensívneho programovania. Tam je zaujímavý topik a prepovedne na to. Nemôžem si spomenúť teraz na ten design pattern, ktorý sa toho týka, ale v tomto design patterne alebo v tomto návode alebo prístupe sa spomína napríklad.

[1:07:02] Americká elektráreň, tuším, že jadrová elektráreň, ktorá vlastne musela riešiť každú jednu situáciu. Chladia tento jadro, čo ak dojde voda, Čo ako prestane vytiekať horúca voda a neviem čo všetko a že vlastne na základe tohto dizajnu, ktorý musel niekto robiť v tejto jadrovej elektrárne, tak vznikol aj nejaký spôsob toho programovania ako prispôsobovať sa zmenám, ktoré nemôžete ovplyvniť a ja si myslím, že to je priamo spojené aj týmto defenzívnym programovaním. Toto je taká zaujímavá téma, ktorú by sme asi vedeli dosť rozprávať. To je celkom zaujímavé, to by som si prečítal. No určite, keď dáme to, tak budem to vyhľadávať, lebo teraz na rýchlo som to nenašiel, ale mám na mene predstavé v hlave, že som videl ten článov, kde je tam náčrtok atomovej elektrárne, jadrovej elektrárne, aj tam vlastne popisuje to, je to use case aj o tom, ako tam zlyhalo.

[1:08:01] Nejaká technická vec. Na základe tej technickej veci, čo zlyhalo, tak bolo vlastne popísaný nejaký softwarový vývoj. Ďakujem.

[1:08:10] Tiež by som chcel spomenúť, že napríklad to, že o to defenzívne programovanie, čo si spomínal, konkrétne tú časť, ktorú si hovoril, že je to o tom, že aj keďž ty môžeš krešnúť a niekedy je lepšie krešnúť celú aplikáciu, aby si zachránil niektoré veci, tak toto je aj reálny prístup, ktorý sa nevolá defenzívne programovanie, ale ľudovo sa volá Let it crash or Let it die.

[1:08:39] Niektorí ľudia to inak volajú a toto je dosť populárne aj v 90-tých rokov a hlavne keď sa budovala celosvetová infraštruktúra a internetu. Keď si ponovil nejaké káble do mora alebo nejaký rútar, keď sa to pokazilo, nemohol si tam vymeniť ho alebo splačiť baton alebo niečo také. To je rovnako ako aj do vesmíru. Ale aj samotné rútare. Keď máš väžu, ktorá má 190 metrov, tak vyliesť tam niekto, aby reštartoval nejaký Wi-Fi rúter, to nebude také jednoduché. Toto je ďalší koncept, ktorý není niečo nové, ale je to veľmi staré a tu sa pekne ukazuje to, že tie staré veci, či už knížka, alebo niekoľko ľudí, kde sú dobré a dajú sa používať. S týmto rozhodne súhlasím, lebo napríklad je taká kniha, ktorá zazvala, že programátor pragmatik, to je stara, stara, akože fakt, že brutál stará za mňa, že ktokoľvek si aj dnes prečíta, tak polovica z tých vecí, a hlavne takých koncepčných, tak je platná.

[1:09:44] Možno, že však samotný AI výskum začal kedy dávno. A tie veci teraz sú len vylepšené vďaka tomu, že je nejaká výpočtová kapacita a škála, aj dostupnosť dát, že vôbec sa da ju použiť. A čo je sranda, tak ja som niekde minule čítal článok o tom, že elektrické koldobežky boli už niekedy, ja neviem, dávno, dávno, dávno a len potom proste tá elektromobilita bola zabitá z nejakých rôznych dôvodov. Takže veľa veci, ktoré my tu máme teraz už boli vymyslené a je otestované a treba sa veľa učiť, no, praxi ideálne. Igor, tvoj názor na toto? Asi tak, jak ste povedali, že veľa konceptov, ktoré sa dnes používajú, nie sú nutne nové, ale sú umožnené tým, že tá technológia niekam pokročila. Hej, vajčku, jak si povedal, že došlo na vypočtovú kapacitu, že zrazu je k dispozícii a máme silné procesory a v tej škále sa ukázalo, že to má zaujímavé výsledky. O elektromobilite sa priznám, že nie je to úplne moje forte.

[1:11:05] Netuším, či tu bola v minulosti nejako viacej a či ju potom nahradili vlastne spalovacie motory, ale, ja som skôr zvedavý, že kam to pojede ešte týmto smerom, lebo, viem o tom relatívne málo, ale mám pocit, že to celé tkvie vlastne v hustote batérií, respektíve v tom akú energiu vieme dať do tých batérií a v tom, ako dlho sa to nabíja, čiže to je asi, to kľúčové, že či sa toto pohne ešte lepším smerom. Je taká populárna téma v posledné roky, asi hlavne keď bola korona remote, je taká kultúra vo IT firmách. Kultúra vo firmách. A špeciálne, aby som sa chcel spýtať na tú IT, keď si uvedomím, že 70 ľudí, čo väčšina je asi ITčkárom, tak ako sa udržia v tomto období kultúra v týchto časoch? Máte nejaké špeciálne prístupy na to, alebo je to jednoducho, proste fungujete, máte svojich projektových manažerov, dané bolky alebo nejakú štruktúru, máte nejakého riadenia aj tých týmov alebo jednoducho, keď máte riadceho projektov, každý projekt má iba jedného projekt manažera a tak ďalej?

[1:12:16] Celkovo sa snažíme, aby štruktúra práve nebola moc vysoká, aby to nebol nejaký vysoký strom. Do dnešného dňa, keď mi proste niekto napíše na Slacku, používame Slack ako hlavne komunikátor, keď mi niekto napíše na Slacku, že potrebuje s niečím pomôcť, poradiť, porešiť nejaký problém alebo čokoľvek, tak to proste riešim a pokiaľ s tým viem pomôcť. Na druhej strane nedalo by sa úplne rástať bez toho, aby tam nejaká štruktúra bola, lebo samozrejme by sa ľudia si zbláznili, že nedá sa deliť časť človeka na niekodečno malých dielikov.

[1:12:51] Náša štruktúra vyzerá asi tak, že zistili sme, že po kultúrnej, organizačnej aj nejakej delivery stránke nám najviac funguje nejaký stav firmy, ktorý bol, keď nás bolo 30, 40, 40, 50 povedzme. A potom sme rozmýšľali, že ako toto zreplikovať, keď nás je teda viac. A vyústilo to vlastne v tom, že my v podstate máme také Panaxeo v panaxeu. Voláme to portfólia, ale v podstate je to ako keby taká menšia časť firmy, ale so všetkým, čo k tomu patrí. To znamená, máme projekty, to je nejaký tím ľudí, ktorý pracuje na konkrétnom projekte alebo pre nejaká zákazníka. Projekty sú v portfóliu, čiže to je druhá úroveň a nad portfóliami vlastne už sme len majiteľi a respektíve cečkové role, ktoré sa snažia, aby toto fungovalo. No a to škálovanie tým pádom je, že máme viac a viac portfólií, keď by trebalo a zatiaľ tam netrebať nejakú ďalšiu štruktúru. No a portfólio je vlastne zodpovedné za celý svoj ekosystém, čiže koľko ľudí potrebuje.

[1:14:04] Či je profitabilné riešiť spoluprácu s tými zákazníkmi a vieme, že jeho maximálna veľkosť je tak do 45 ľudí. Sme si povedali, lebo tak sme si to odpozorovali sami na sebe. Áno, má vlastného rediteľa, vlastného CTO-a. Dá sa to tak, voláme to portfólio manažera, ale v podstate sú to dvaja ľudia. Jeden je technickejší, jeden je manažerskejší a vychádza to z takej nátury, že tak sme rozdelení ja s Adamom ako majiteľi a že my sme v podstate do veľkej miery zameniteľní a do veľkej miery vieme súplovať jeden druhého a to nám veľmi pomohlo vlastne fungovať vo firme a občas mať kľud a občas zase zamakať. A ja som, viac možno cez tie technológie a Adam zase riešil viacej operatívu no a tento štýl sa nám páčil v tom zmysle, že aj je tam zastupiteľnosť, aj sa vieme poradiť, aj o dôležitých veciach nerozhoduje jedna osoba, ale je to proste vždy nejaký konsenzus no a tak sme to zreplikovali vlastne na úroveň toho portfólia, že tiež je tam vlastne jeden a pôl človeka, ale fyzicky akože dve hlavy a proste musia sa poradiť musia sa dohodnúť a vedú si to portfólio za seba.

[1:15:15] Evidentne teda radši táš knihy a plus si hovoril, že máš nejaké tie filmy, ktoré si už videl veľakrát a stačí ti ich počúvať ako zúb pristavenie lega. Vedel by si odporučiť našim čítecovom nejakú nejakú knihu, ktorá im môže pomôcť byť lepším.

[1:15:35] Vývojárom alebo človekom v technickom svete a možno, že tvoj úlovený film, taký ktorý...

[1:15:44] Tak tože, čo sa týka byť lepším vývojarom, podľa mňa, či jedna kniha tomu nepomôže, takže dúfam, že ma za to nikto nezužerie za tento názor. Najlepší vývojári, ktorých poznám, sú najlepší preto, lebo majú extrémne vysokú prírodzenú zvedavosť a nikdy sa neuspokojili s tým, že niečo funguje, ale vždy chceli vedieť, že prečo. A to prečo ich donutilo sa vŕtať v tom systéme až do vtedy, kým ho nerozumeli, až do takej úrovne, že to možno ani netrebalo. Čiže za mňa je oveľa cenejšia, a to isté fungovalo vždy mne, že byť zvedavý a ak to funguje, tak prečo, a ak to nefunguje, tak prečo.

[1:16:29] Všetky informácie na to, aby človek bol dobrým programátorom sú na internete, všetky skripta z najlepších univerzít sú proste voľne dostupné na internete, milión konkurzov, milión tutoriálov, proste Stack Overflow už, produkuje AIčky, ktoré proste vedia písať kód, hej, čiže akože myslím tým, že boli použité, Stack Overflow bol použitý asi ako zdroj dát proste pre nejakú AIčku, alebo chcem tým povedať, že tie Informácie tam proste sú. Je to skôr o tom, aby človek mal nejakú motiváciu si sadnúť za komp a reálne sa do toho vŕtal proste dovtedy, kým tomu nerozumie. A ono to proste bolí zo začiatku celkom dosť a potom to začne dávať v myseľ. Čiže to je môj názor, akože na to, ja neviem, že na to nie sú dobré knihy, sú tam vynikajúce knihy, ale aj Klinkov som čítal proste veľmi dávno. A je to užitočné, ale nemyslím si, že to je to kľúčové. Zvedavosť a chcieť sa furt učiť. Chcieť sa furt učiť. Nové veci.

[1:17:33] Jedna z dobrých knih, čo som nedávno čítal, je práve, že skôr čisto pragmatická, teraz sa aj my pozerám, a je to stávanie šejdrov pre Unity. To je niečo, čo mňa veľmi bavilo a čo som si celkom užil. Je to hruba bichla, ale ak niekoho zaujíma, ako sa píšu šejdre a čo sa s nimi dá robiť, tak to bola super vec. Ale to je zase opäť konkrétna vec na konkrétny cieľ. A nejaké netechnické? Čítaš aj knihy netechnického charakteru? Posledné, čo som čítal, boli skôr o histórii a situácii medzi Ruskom a Ukrajinou za posledných 500 rokov a niečo na tento spôsob, skôr preto, aby som nejak navnímal situáciu. Čiže netechnické sa snažím skôr čítať také naozaj, že mimo biznisu a mimo tohto. Dobre, a čo tam? Stokrát počúvame. Stokrát počúvame rozhodne Star Wars, ktoré som videl veľmi veľakrát. Čokoľvek od Christophera Nolana. A tam by som to nechal. Všetky LEGO movie. Videl som niektoré. Nevidel som všetky. Tak Igor, ďakujeme ti za čas dnes, dobrú diskusiu. a niekedy inokedy sa znova počujeme a vidíme. Ďakujem pekne za pozvanie. Ďakujeme, ahoj. Ahojte. Čaute, pekný deň.