středa 23. prosince 2015

Mýtus Vývojář brouk pod kamenem

Často kolem sebe slyším, jak je to v pytli, že se nedaří nikoho najmout. Prý jsme my, čeští vývojáři, brouci pod kamenem. Dobří, ale nikdo o nich neví. Nepíšou, neprogramují veřejně - rozuměj mají alespoň jednou týdně jednu kontribuci na GitHubu. Na univerzitách to prý stojí za starou bačkoru, protože studentů je málo, poptávka je obrovská a platy královské. K tomu všemu nemusí ani moc hrábnout, protože se jim to servíruje na stříbrném podnose. Výsledek? Najít kvalitní lidi je problém. Jenom dodávám problém to byl i před patnácti lety. No možná i před dvaceti, padesáti… Problém to byl vždy. To co se změnilo je způsob jeho řešení a ten evidentně selhává.

Žijeme v době kdy kvalitu vývojáře posuzujeme na základě referencí na síti, kde je nebo byl každý kolegou/známým každého nebo to minimálně alespoň předstíráme (LinkedIn). Případně na základě dojmu z kontribuce na GitHubu s lehkým přihlédnutím k faktu, jestli vyprodukovaný kus kódu patří do shell skriptu o deseti řádcích nebo do projektu, který nikdo nikdy nepotřeboval. U přijímacího pohovoru považujeme za vrchol erudovanosti schopnost vyřešit problém, jehož řešení by trvalo na internetu najít a pochopit pět minut. Výsledek je, že buďto nikoho nenajdeme, najdeme a vyhodíme, najdeme a asimilujeme, najdeme a tiše skřípeme zuby. Používáme špatný způsob špatně a potom si na to ještě stěžujeme.

Kvalitu vývojáře nepoznáte ani podle statistiky z GitHubu ani podle profilu na LinkedIn. Programování je normální řemeslo, které se učíte celý život. V podstatě potřebujete jenom dva předpoklady ochotu učit se a pracovat na sobě. Hlavně ovšem záleží do jaké firemní kultury zapadnete. Špatná kultura z vás může udělat špatného vývojáře a naopak. Hledejte lidi, kteří vám zapadnou do firemní kultury a dělejte takovou firemní kulturu, podle toho jaké lidi chcete mít kolem sebe. Pak nemusíte řešit ani LinkedIn ani GitHub a možná ani to jestli je ten člověk víc juniorní nebo seniorní nebo jaký programovací jazyk nebo technologie zrovna umí.

Malá vsuvka pro dobré lidi. Pozor, firemní kultura není definována tím co si pověsíte na zeď nebo napíšete do firemního bulletinu. Je to něco co definuje chování skupiny - esprit de corps - a vzniká mimoděk tím jak se chováte a co děláte. Podobně jako inovace nevzniká tak, že řeknete vaším kolegům inovujte, ani kultura nevzniká tím, že jí nařídíte. To nejde, je to nesmysl.

pátek 18. prosince 2015

CZ Podcast 134 - Future of work

Ve vánočním speciálu jsme chtěli zrekapitolovat rok 2015, zazpívat koledy a využít neuvěřitelné pohostinnosti firmy Avast. Nakonec se z toho stalo natáčení před živým publikem a kromě okrajové rekapitulace jsme zavedli řeč na téma future of work. Doufáme, že se vám tento trochu delší díl bude líbit a v čase vánočním vám poskytne novou pastvu pro vaše uši a mysl.

úterý 1. prosince 2015

CZ Podcast 132 - Co se peče v SocialBakers

Při natáčení 132. dílu jsme se vypravili do úžasných prostor firmy SocialBakers a natočili jsme pro vás neméně úžasný díl o tom co se u nich kutí, teda vlastně peče. Tuze zajímavé a hutné povídání s Eduardem Kuncem a Josefem Šlerkou. Probrali jsme nejenom jejich produkt, ale zrabrousili jsme do technologií a hlavně jsme poměrně hutně rozčísli téma spolupráce s univerzitami a peciválství nebo bojácnosti českých vývojářů chcete-li.

pátek 27. listopadu 2015

Happiness at work konference nebyl jenom výlet mezi sluníčkové lidi


Šrakyi, kterého možná znáte z našeho podcastu (Internet věcí a překvapivě Štěstí v práci), spolupořádal konferenci Happiness at work, na kterou mě a Filemona pozval. Filemon tam tedy mluvil v lightning talku s kadencí rotačního kulometu Gatling a posléze nadhazoval vlastní aplikaci pro analýzu opravdových vztahů ve firmách. Na mě zůstalo zapisování poznámek a pocitů. Ač se to zdá na první pohled jako sluníčkové téma a výlet mezi etérické bytosti, opak byl pravdou. Štěstí v práci je vlastně něco mnohem jednoduššího a lépe uchopitelného než si myslíme. Snad se na mě Šrakyi nenazlobí, kvůli tomu, že nenapíšu plnohodnotnou reportáž, ale aspoň takhle bych se chtěl podělit o to co mě nejvíce zaujalo a poděkovat mu touhle cestou.


Keynote
  • Alexander Kjerulf
  • Happiness at work is not job satisfaction. It’s not what we think, but how we feel. It's about emotions
  • Vytvořte prostředí, kde mají lidé mnohem více pozitivních emocí
    • 1 negativní emoce bývá vyvážena 3 pozitivními emocemi
  • Každý může být v práci šťastný
    • příklad babky co uklízela WC na letišti, Aerolinie Southwest
  • Proč je důležité štěstí v práci
    • velký/obrovský vliv na produktivitu a výkon lidí
  • V práci se často mluví o problémech a skoro nikdy o tom, co nás v práci udělalo štastnějšímu

Hlavní faktory ovlivňující náš dobrý pocit z práce
    • Jsem potřebný
    • Mohu něčeho dosáhnout
    • Dělám smysluplné věci
    • Dělám něco, co někomu pomůže bude užitečné
Dávejte lidem feedback
  • Chvalte, například každá porada se může začít tím co se povedlo
  • Muži mají často pocit, že když nic neříkají, vlastně chválí. Bohužel ne všichni to takhle vnímají.
  • Tip: Začněte ráno tím, že se s kolegy laskavě pozdravíte
Vztahy na pracovišti přispívají zásadním  způsobem k pocitu štěstí
  • Vztahy se spolupracovníky
    • potřebujeme mít pocit, že jsme součástí skupiny/kolektivu, že někam patříme
  • Nejdůležitější je vztah s bossem
    • Oceňuje mojí práci
    • Ví o mě
    • Zná moje schopnosti
    • Podporuje mě
Peníze nejsou hlavním motivačním faktorem, funguje jenom omezeně
  • Dělají zlou krev
    • máme geneticky zakódováno, že je s námi nakládáno fér. Pokud máme pocit, že není, často to vede k pocitu křivdy.
  • Větší plat vás neudělá šťastného
  • Šťastnější pracoviště vydělává více peněz
  • Tipy
    • Potřebujete leadry
    • Vyhodit špatné (bad) managery, kniha The no asshole rule
    • Najímejte šťastné lidi
    • Vytvářejte smysl a účel
    • Oslavujte vítězství, i ta malá
Etnetera
  • všechno začíná a končí s důvěrou
  • omezení nejsou potřeba, většinou omezují 97% přitom byla určena pro 3% (ty už možná odešli)
  • nebojte se dělat chyby
  • dali jsme do toho při restrukturalizaci firmy všechno (all-in), lidi uvěřili, že to myslíme vážně
    • těm co se to nelíbilo, s těmi jsme se rozloučili
  • potřebujete lidi, kteří to budou zkoušet
  • mimochodem měli jsme je v podcastu 111 
  • namísto procesů používáme pravidlo pravé ruky/selský rozum. Umožňuje nám to držet počet procesů na minimu.
  • Co nefungovalo
    • Flat struktura, složitá synchronizace meeting s 20 lidma
    • Zapojení obchodníků do týmu
    • Vzít lidem stravenky
  • Cíl byl mít nezávislé týmy a výbornou kulturu

CZ Podcast 131 - Textová analytika s Geneea

Do 131. dílu dorazil Jiří Hana a Petr Hamerník z firmy Geneea, která pracuje na textové analytice. Analýza sentimentu během hokejového Mistrovství světa v Praze nebo dobrého vojáka Švejka a jeho cesty do Haliče. To všechno jsou příklady, na kterých nám Jirka s Petrem ilustrovali možnosti jejich enginu. Vizuální představu můžete získat z této prezentace.

čtvrtek 5. listopadu 2015

CZ Podcast 128 - Borek Bernard a VersionPress

Do 128. dílu jsme pozvali Borka Bernarda a tématem byl jeho projekt VersionPress. Kromě technické stránky jsme se zajímali o to, jak se mu povedlo získat investici pro tento projekt. Mimochodem v tomto díle jsme rovněž osvětlili stock options a odpověděli na dotazy z minulého dílu. Za všechny ohlasy samozřejmě děkujeme.


středa 21. října 2015

CZ Podcast 126 - Zonky.cz děláme banku v pěti lidech

V tomto díle jsme se podívali na startup Zonky zaměřený na mikropůjčky, u kterého nás zaujal nejenom produkt, ale i to, že postavili bankovní aplikaci v pěti lidech. Naším otázkám trpělivě čelili Lucie Tvarůžková a Petr Vlček.

pátek 16. října 2015

Proč je technologie nedůležitá aneb zkreslení technické duše

My inženýři a vůbec technicky potentní jedinci máme utkvělou představu, že nejdůležitější částí každého produktu je technologie a technické provedení. Ani omylem a opak je pravdou. Technologie je ta méně důležitá esence každého produktu. Já jsem se o tom přesvědčil na vlastní kůži s HotCar.io. S drobnou pýchou v hlase dodáván, že jako inženýra mě těší, že náš engine dokáže vyhledávat rychlostí kulového desku, nabízet ty nejvýhodnější a nebo filtrovat podvodné nabídky, ale ve vytvoření úspěšného produktu nám to nepomohlo. Úspěšný produkt je takový produkt, pro který existuje trh, poptávka a hlavně uživatelé ochotní za něj platit. Technologie je prostředek a nikoliv cíl a tenhle post je o jedné z lekcí, které jsem dostal.

Byl to skvělý nápad a ta cesta vypadala dost přímočaře. Máme hromadu dat o ojetých autech a na světě je spousta uživatelů, kteří nám kvůli tomu utrhají ruce, aby si mohli nějaké auto výhodně koupit. Potřebujeme jenom drobnost, zasadit ta data do kontextu a to nejlépe analytického. Všechny zajímá, jestli v sousedním Bavorsku není to auto levnější a nebo jaká bude cena mnou koupeného ojetého vozu za rok. No a potom máme taky uživatele, které to vůbec nezajímá, protože jejich analytické schopnosti končí otevřením Excelu. Jste matka se dvěma dětmi a chcete si pořídit nové auto? To bude potřeba větší kufr, něco bezpečného, levný provoz a servis. Fajn, přijdete k nám na stránky, kde vám nabídneme nejlepší inzeráty, které vyhovují vaším preferencím.

Věděli jste, že je běžnou disciplínou inzerovat neexistující vozidla, aby prodejce přilákal vaší pozornost a pak vám při nejbližší příležitosti prodal nějaký křáp? O přetočených kilometrech ani nemluvě. Pokud o tomhle všem řeknete svým kamarádům, řeknou vám něco ve smyslu, že tohle by byla určitě super služba, kterou by používali.

Vsuvka - nikdy opakuji nikdy za žádných okolností, když vám kamarád řekne, že vaše nápad na startup je super, tomu nepodlehněte. Jednak kamarádi většinou neprovedou naprosto upřímnou sborku rozborku se zdrcující kritikou a jednak po pátém pivu je i blbý nápad dobrý nápad. Vždy validovat s někým komu jste u zadku. Pokud ho zaujmete a bude vám za to ochoten zaplatit, pak je jistá šance, že by to mohlo fungovat a vy na tom nepropálíte zbytečně čas a peníze.

My jsme takové štěstí na kritiku, která by nám otevřela oči, neměli. Začnete tedy implementovat, protože to děláte po večerech a ve volném čase, zabere vám to půl roku práce. Pečlivě vybrušujete každý technický detail. Po půl roce máte v potu tváře něco, co by se dalo nazvat osekaná beta. Pak přijde ten okamžik, kdy to poprvé někomu ukážete, a z hrůzou zjistíte, že možná skupina koncových uživatelů, pro kterou jste to celé šili na míru, vůbec neexistuje. Máte sice skvělý engine, ale nemáte v ruce žádný produkt, za který by byl ochoten někdo platit. Máte v ruce jenom šidítko pro vaší technickou duši, skvělá zábava, ale za tu se nenajíte a složenky nepoplatíte.

Lekce číslo jedna: nejdůležitější jsou uživatelé a jejich ochota za něco platit. To definuje produkt, nikoliv technologie, která vám to umožní realizovat. Bude těch uživatelů dost, jakým způsobem je oslovíme, škáluje náš model? My místo toho řešíme, jestli bude mít aplikace takové nebo makové API, jestli to napíšeme v Reactu a nebo Emberu, jestli použijeme dokumentovou nebo relační databázi, tj. detaily důležité nikoliv nezbytné.

Až za mnou příště přijde někdo s geniální myšlenkou, kterou mi nad třetím pivem odkývá každý kamarád, pustím se nejdříve do definice produktu, který budu levnou cestou validovat. Teprve potom, co budu mít určitou míru jistoty, že existuje cílová skupina ochotná platit, budu si lámat hlavu s tím, v jaké technologii to nakonec napíšu.

K tématu doporučuji výborný článek Seven lessons I learned from the failure of my first startup, Dinnr, knihu Running Lean a podcast s Hubertem Palanem o product managementu a trnité cestě, kterou musí každá myšlenka urazit než se z ní stane plnohodnotný produkt.

CZ Podcast 125 - Hubert Palan a Productboard

Do tohoto dílu jsme pozvali Huberta Palana ze startupu Productboard a povídali jsme si o trnité cestě, kterou musí každá myšlenka urazit než se z ní stane plnohodnotný produkt.

úterý 13. října 2015

Falešná podpora podnikání aneb eurotunel za 50 milionů euro

Včera vyšla zpráva Státní fond pro startupy dostal zelenou, rozdělí 50 milionů eur z EU, která by mě - člověku se startupovými zkušenostmi - měla udělat radost, ale mám z toho přesně opačné pocity. Pominu fakt, že jí ohlásil pan ministr Mládek, který všechny soukromníky označil za parazity sociálního systému . Mnohem více mi vadí princip, kterým chce naše vláda z našich daní podporovat startupy. Nevím přesně v jaké geniální hlavě na ministerstvu Průmyslu a Rozvoje se ten plán urodil, ale tipoval bych to na následující průběh.

Hele X, máme tady nevyčerpaných peněz z EU fondu Y. Uděláme si analýzu. Hmm čoveče tady ty startupy, to je bída, máme jich málo. Podívej se do Berlína, Londýna nebo Stockholmu, jak se jim tam daří.Hele máme tady minimálně 40 milionů euro, na které dosáhneme v programu podpory rozvoje začínajících fírem. Dobře přidáme naše peníze, vymyslíme způsob, jak to úředně zprocesit, aby bylo EU učiněno za dost, a spustíme to. To musí fungovat, no na tuty a ještě si kolem toho uděláme pořádné PR. Majstr kasa štyk to ti povídám.

Ten plán vypadá na první pohled dobře, ale znáte to, cesta do pekel je dlážděná dobrými úmysly. Předně už teď je jasné, že celý ten ouřednický aparát bude mít svojí režii. Nechme teď stranou fakt, že k tomu, abyste na nějakou podporu vůbec získali, budete muset najít způsob, jak proniknout přes byrokratické nástrahy čerpání z takového fondu. Plnění všech compliance povinnosti, kdy glejt s logem EU vypálený do zadnice vaší a vašich společníku, bude tou nejmenší překážkou. Rovnou bych očekával, že na čerpání peněz z toho fondu bude navázané použití technologií nebo know how z jiných podobných EU projektů. Nepřekvapilo by mě proto, kdybych musel použít obskurnosti typu rovnák na vohejbák, protože pochází z přidruženého EU fondu, který musí obhájit svojí smysluplnost.

Rovněž ponechme stranou, že je absolutně mimo schopnosti jakéhokoliv úředníka, bez ohledu na to jestli sedí v Praze nebo Bruselu, posoudit jestli má daný startup cenu oné investice. Kdyby to totiž mimo jeho schopnosti nebylo, už dávno by se živil jako Venture capitalist (rizikové investice).

Hlavní a zásadní problém je v tom, že od investování do začínajících technologických firem jsou soukromé osoby nebo soukromé fondy. Stát by měl stimulovat podnikání bez přívlastku (rozuměj bez ohledu na to jestli je to malé/velké nebo nové/staré) vytvářením prostředí (daně, míra byrokracie, zákony) nikoliv pobídkami pro konkrétní odvětví.

Seriozní debata, kterou já jsem nikde nezaznamenal, by se měla probíhat v intencích - jak složité a drahé je založit firmu a vyhovět všem podnikatelským povinnostem, jak nákladné je mít zaměstnance, jak je ekonomicky výhodné investovat tady nebo jinde. Obáván se, že výsledek tohoto státního pokusu o financování této oblasti musí skončit fiaskem, kdy peníze nás všech propálí banda úředníků a na ně navěšených pijavic - firmy zprostředkovávající dotace plus jedinci veksláckého typu, kteří koukají na jaký státní cecík se přisát. Ano možná tam bude jeden, dva, pět nebo třeba deset startupu, kterým to pomůže, ale ty by se prosadily i bez téhle státní subvence.

Osobně mi nedává smysl zapojit se s HotCar.io do tohoto programu. Já totiž očekávám od investora nejenom peníze, ale hlavně zkušenosti a kontakty. Nic takového mi nemůže jakýkoliv státní fond nabídnout.

pátek 18. září 2015

CZ Podcast 124 - ajťákem v Malajsii

Do 124. dílu jsme pozvali Jana Šnajdra a tématem byla všehochuť od informační bezpečnosti až po to, jaké bylo býti ajťákem v Malajsii.

pátek 4. září 2015

CZ Podcast 123 - hardwarové hračky

Do dalšího podcastu jsme pozvali Martina Malého a Boba Koutského a povídali jsme si o hardwarových hračkách na Arduinu a dalších kitech. Tuze zajímavé povídání o domácím bastlení a světě tranzistorů, ledek a vůně tištěných spojů a pájení.


úterý 18. srpna 2015

A case against polyglot programming

We have been doing polyglot programming at GoodData even before Micro services get traction and honestly it was probably one of the biggest mistake we ever did. At the beginning (2008) our platform was simple LAMP stack with REST interface and bunch of JavaScript. We have been adding more and more languages as we followed a golden rule use right tool for right job. We add Erlang because what language to use for a distributed system. We add C++ because what language to use for fine tuned computations. Since 2008 our stack was getting bigger and bigger - Perl, Java, JavaScript, Erlang, C++, Python, Ruby. In such heterogenous environment was critical to encapsulate every service/component with an API in order to keep interoperability. All our services expose a REST API so programming language is an implementation detail of them. Someone could appreciate such diversity, but from my 5 year experience it’s a nightmare.

First of all, once you start developing features spanning more than one service you need a team with experts in more than one or two languages. It’s absolutely ok to use one language for backend (pick your favorite) and one for fronted (JavaScript rule them all), but setup a team with Java, Perl, Erlang, JavaScript developers is complicated. You need more than one developer for every language because of redundancy. Those developers are mostly experts in one language meaning you can train them for other languages, but it takes a lot of time and money. Developers have to see the given language and not only language but also the whole ecosystem as a career opportunity. You not need a newbie who learn HelloWorld, but someone who is able produce production ready code. You can hire them if they are available and you have enough time goes through gazillion of CVs, interviews and not counting their boot time to domain problems your company tries to solve. It’s not a technical choice, but more a people/culture choice.

Second, what polyglot programming really offers? It’s worth to see 50 lines of Java code can be reduced 10 lines of Clojure code but for what. At least at the backend most of the code do nothing more than run few or more SQL queries, transform result to XML or JSON. Do we really need different programming languages for that? I doubt and you should too. Most of the programming tasks can be accomplished in single language without loosing any comfort and productivity because of existing frameworks, tools or libraries. I don’t think we should use one language for everything, but using different languages even sexy languages for very similar use cases is waste of time and resource.

pátek 14. srpna 2015

CZ Podcast 121 - Czechitas holčičí emancipace v IT

Do dalšího dílu jsme nepozvali jednoho hosta, ale hosty rovnou dva, Zuzanu Dostálovou a Ditu Přikrylovou z projektu Czechitas, který se velmi úspěšně snaží o ženskou emancipaci v IT. Povídání to bylo jako vždy zajímavé a plné energie a nám nezbývá než smeknout klobouk před tím co holky dělají a jak se jim daří. Sympaticky to působí i ve světle toho, že na to není potřeba evropských dotací z rozvojových fondů pro genderovou vyváženost a podobných nesmyslů.

úterý 11. srpna 2015

Proč je důležité dělat nedůležité

Hrajete počítačové hry? Všiml jsem si, že plno složitějších problémů nebo úkolů řeším, jako kdybych hrál počítačovou hru. Velmi mi to připomíná hraní her na hrdiny (RPG). Teď nemám na mysli to, že bych byl hrdina. Ostatně můžete kolikrát hrát za stranu padouchů a svůj herní charakter rozvinout jak kladně, tak i záporně. Při hraní RPG her, máte obvykle jeden hlavní úkol, ke kterému celé vaše snažení směřuje. Hru můžete odehrát tím způsobem, že plníte nejnutnější minimum, které je potřeba k splnění tohoto úkolu. Druhým způsobem, jak tyhle hry hrát, je prozkoumávání celého herního světa s tím, že plníte podružné úkoly nebo se jenom tak flákáte kolem a zkoumáte.

Já mám ten druhý způsob hraní hrozně rád. Nikdy nevíte, koho ve hře potkáte, co uděláte a kam vás to posune. Můžete narazit na lepší vybavení, vyrubat nějaké nepřátele a tím získat zkušenosti nebo rozplete kus příběhu, který vám pomůže lépe se zorientovat. Zkušenosti vaší postavy jsou důležité, protože díky nim můžete rozvíjet jednotlivé atributy herního charakteru (odolnost, zdraví, sílu, obratnost atd.)

Práce na nějakém složitějším problému je pro mě jako nová hra. Přirovnal bych to k průchodu nějakého dungeonu. Vidím vstup, vím kam se potřebuji dostat a jenom nevím přesně kudy a co tam na mě číhá. V tom dungeonu rád prozkoumávám jeho zákoutí, protože nevím, kde se dá co objevit a co mě posune dál. Mohl bych jít rovnou za nosem, ale nebyla by to taková zábava a dovedl by mě k cíli? Žádná cesta totiž není slepá dokud jí neprojdete. I v tom dungeonu děláte nebo lépe řečeno můžete dělat věci a plnit úkoly, které jsou nedůležité. Získáte tím zkušenosti, které se vám hodí při plnění hlavního úkolu.

Pokud zrovna programuji nebo navrhuji, nikdy nesleduji jenom hlavní úkol. Často dělám refaktoring, a snažím se kód dost zobecňovat, připravovat si různé nástroje a mikro frameworky, protože mám pocit, že se mi to bude v budoucnu hodit. Někdy se to skutečně hodí, ale dost často to prostě k ničemu není a já musím ten kód, nápad, návrh vyhodit nebo upravit, protože budoucnost je jiná než jsem si jí projektoval v hlavě. Je to způsob, kterým si ověřuji vlastní hypotézy a získávám další zkušenosti a lepší porozumění danému problému. Podobně jako bych v dungeonu vylepšoval sečné zbraně mojí postavy, abych posléze zjistil, že na nový typ nadpřirozených nepřátel jsou k ničemu.

Lidé jsou často svázaní představou, že by měli dělat jenom to důležité, co je dovede k řešení daného úkolu. Jenomže co je důležité? Dokážeme rozeznat důležité od nedůležitého? Retrospektivně viděno to dokážeme posoudit. Všechno co nás neposunulo ani o píď blíže k cíli bylo v uvozovkách zbytečné. Měli bychom si uvědomit, že podobně jako při hraní her je důležité dělat nedůležité a to přesně kvůli těm samým důvodům - jsou to zkušenosti, je to zábava a nikdy nevíte, jestli je cesta slepá dokud jí neprošlápnete. Vzpomeňte si na to, až si budete trápit mysl tím, že zrovna děláte něco nedůležitého.


úterý 4. srpna 2015

Neučme se z úspěchu

Deset rad, jak se z vás stane lepší programátor. Deset rad, jak vést firmu jako Steve Jobs. Deset rad, pomocí kterých zaručeně sbalíte holku. Deset rad, jak uspět s vaším startupem. Všechno s razítkem zaručené a nejlépe podpořené nějakou ikonickou značkou. Určitě jste narazili na přehršel podobných článků, které se vám snaží v kostce představit tu méně tu více osvědčené rady. Úspěšné příklady táhnou. Ve většině případů mají ovšem tyto rady malou cenu a já osobně takové články nečtu.

Nejde o to, že by se člověk neměl inspirovat úspěchem někoho jiného, ale bohužel to co vedlo k úspěchu jednomu, nebude s velkou pravděpodobností fungovat někomu jinému. Každý úspěch, respektive cesta k němu je unikátní, a pokud budete dělat totéž, nemáte rozhodně zaručeno, že dosáhnete stejného výsledku.

Problém rad postavených vydistilovaných z úspěšných příběhů spočívá v tom, že jsou vytržené z kontextu. Nebo lépe řečeno kontextově specifické. Když teď půjdete a založíte si internetový obchod se vším, těžko se z vás stane nový Amazon. A můžete si přečíst tisíc a jeden článek o tom, co děla Steve Bazos. Každý úspěšný příběh je zasazený do reálií, které bývají jedinečné. Možná se vám to nebude líbit, ale musím vás upozornit na to, že budete potřebovat i štěstí. Ať už si pod štěstím představíte cokoliv. Počínaje načasováním, kolegy, příznivou situací na burze atd. Štěstí hraje možná větší roli, než by se vám mohlo líbit.

Myslím, že jsem to poprvé četl v knize Why we fail, je důležité studovat úspěch, ale mnohem důležitější je studovat neúspěch, protože ten bývá méně kontextově závislý. Chyby jsou universálně přenosné a ve všech těch selháních a neúspěších člověk dokáže identifikovat společné vzory. Bohužel nebo bohudík jsme tak geneticky naprogramování, že se snažíme hledat vzory v tom co fungovalo. Úspěch táhne a motivuje, z neúspěchu se člověk učí.

čtvrtek 23. července 2015

CZ Podcast 120 - Youradio

Do dalšího dílu jsme pozvali Lubora Zoufala a tématem bylo personalizované internetové rádio Youradio a dalších zajímavých projektech mediální skupiny Lagardere. Pokud odebíráte naše podcasty z RSS zdroje Java.cz, upravte si prosím adresu na agregovaný feed.

úterý 14. července 2015

CZ Podcast 119 - Roboauto

Hostem 119. podcastu byl tým Roboauto ve složení Jan Najvárek, Tomáš Ondráček, Vojtěch Smejkal a Pavel Černocký. Témátem byl vývoja robotického auta, na kterém pracují, a dozvíte se technické detaily ze zákulisí včetně vlastní architektury.

pátek 29. května 2015

CZ Podcast 118 - Hackathony

Do dalšího podcastu jsme si pozvali Jan "Novoje" Novotného a Vojtěcha Jasného, kteří nás provedli tématem firemních Hackathonů - proč, co, jak, výhody, nevýhody a hlavně zkušenosti.

čtvrtek 21. května 2015

CZ Podcast 117 - Technologické inovace s Romanem Staňkem

Do dalšího dílu jsme pozvali Roman Staňka (NetBeans, Systinet, GoodData), jednoho z nejúspěšnějších technologický podnikatelů a vizionářů, se kterým jsme si povídali o technologických inovacích, řízení firmy a vůbec životě CEO.

čtvrtek 26. března 2015

čtvrtek 19. března 2015

CZ Podcast 113 - Geewa a multiplayer hry

Hostem 113. dílu byl Miloš Enderle ze společnosti Geewa a tématem byl vývoj multiplayer her. Probraných oblastí bylo tuze moc, od toho jak firma rostla, přes monetizační modely, konkurenci, integraci s Facebookem, architekturou, DDOS útoky zneuctěných hráčů a konče testováním na uživatelích. Tuze zajímavý podcast, kdy je člověku líto, když to musí po té hodině utnout.

čtvrtek 5. března 2015

úterý 24. února 2015

CZ Podcast 111 - Svobodná firma

Tuze zajímavé povídání jsme natočili se Zbyňkem Hraše. Tématem je koncept Svobodné firmy, zmrdfree kultura, samoorganizující týmy a vůbec transformace firmy Etnetera.

pondělí 23. února 2015

Jak jsem zkoušel býti digitálním nomádem

Často mi někdo říká: ty se máš, zabalíš si počítač a můžeš pracovat odkudkoliv na světě, případně pojedeme někam na trip, ty si vezmeš počítač a bude pracovat. Dlouho jsem tomu konceptu prostě nevěřil, obzvláště pokud je vaše práce týmová, respektive někdo závisí na vaší dostupnosti, což se stává z mnoho důvodů - rozjíždíte nový projekt, máte někoho méně zkušeného, případně potřebujete předat know how. Letos se mi naskytla příležitost strávit 14 dni na Kapverdských ostrovech, kam jsme vyrazili za kiteboardnigem. Dalo by se říci ideální sport, pro skloubení s prací. Jezdíte tři, čtyři hodiny denně - pokud vám přeje počasí, tedy především silnější vítr, bez kterého se ten sport nedá provozovat - a zbytek můžete strávit “s notebookem na pláži” nebo prostě proležet. Zároveň jsem měl dost práce na jednom soukromém projektu. Dobrá příležitost spojit příjemné s užitečným a vyzkoušet si digitální nomádství. Kromě toho jsem potřeboval trochu potrénovat na maratón a vzal jsem si běžecké boty, aby těch aktivit nebylo málo.

Střet s realitou

Člověk míní a život mění. Měl jsem v plánu dát si brzo ráno budíček, dojít se na hodinu proběhnout, trochu si zacvičit. Snídaně, dvě tři hodiny programovat, výjezd na pláž tři čtyři hodiny jezdit. Vrátit se zpátky na apartmán, udělat si večeři a potom ještě dvě hodiny programovat. Jak říkají kapverďané hlavně no stress. Samozřejmě, že si člověk plánuje vyplnit čas programováním i v hluchých místech: na letišti, v letadle atp.

Na letišti jsem samozřejmě nic neudělal, protože veškerou invenci jsem musel věnovat důmyslnému přebalení našich zavazadel, aby splňovala váhový limit 32kg. Cestu v letadle (sedm hodin) jsme z velké části strávili, sledováním filmů, povídáním a plánováním, jaké nové triky se hodláme naučit.

Během prvního dne, kdy jsme přiletěli a otestovali místní spot, jsem se cítil dost unavený. Nevadí, zítra bude taky den.

Druhý den ráno budíček, běh, nákup, návštěva banky, zjištění možností připojení k internetu, pojezd u moře a večer totální vytuhnutí již v devět večer. Dobře, to je aklimatizace, zítra bude lépe. Asi třetí den se mi podařilo začít programovat po snídaní, kdy zbytek party vyrážel do města. Večer to bylo víceméně marné díky únavě. Asi po čtyřech dnech přestalo foukat. Což byla totální pohroma pro zbytek party, ale mě to umožnilo ponořit se do práce. Zatímco zbytek skupiny vyrážel na pláž k moři, já zůstával na pokoji a programoval jsem s přestávkou na jídlo.

Bylo zajímavé, jak se vyvíjela nálada ve skupině. Všichni okolo mě byli totálně otrávení z bezvětří a vůbec špatného počasí - déšť, většinu času zataženo - díky kterému to nebylo ani na válení na pláži. Ostrov Sal, kde jsme pobývali, nenabízí moc příležitostí k zábavě. Já jsem byl spokojený, protože jsem měl klid a čas na práci. Sranda se mnou tedy moc nebyla, a zpětně viděno jsem je možná i trochu štval, protože jsem neustále seděl u počítače a večerní život se redukoval na konzumaci jedné plechovky místního ležáku, který mě spolehlivě uspával.

Přístup k internetu byl žalostný, což se nakonec ukázalo jako jedna z největších výhod. Na internet se chodilo na kafíčko do kavárny u hotelu. Díky horší dostupnosti internetu jsem se mohl plně soustředit na práci, od které mě nic nevyrušovalo. Jestliže si někdo myslí, že lze programovat pod slunečníkem někde na pláži nebo nedej bože u bazénu, pak já to tedy nejsem. Kromě toho, že tam je vedro a v našem případě fouká, atmosféra vás prostě nepřinutí pracovat. Mimochodem podobné to mám doma, mozek se přepne do režimu relax. Pokud tedy za práci nepovažujete brouzdání po internetu. 

Ve výsledku jsem toho za těch 14 dní stihl naprogramovat dost. Nesplnil jsem všechno co jsem si předsevzal a to z několika důvodů.

  • Docela mi trvalo, než jsem si našel denní rytmus, který mi umožňoval skloubit všechny činnosti se zbytkem skupiny (odjezd na spot, příprava jídla, úklid a podobně), vlastní programování a odpočinek. Jsem ranní ptáče a proto nějaká aktivita po večerech pro mě byla utopie a ta hlavní pracovní náplň se musela odehrát dopoledne.
  • Chyběl mi kontakt s někým, kdo by mi třeba na denní bázi dával zpětnou vazbu. Znáte to určitě z vlastní zkušenosti, že se do něčeho příliš ponoříte a přitom je to zbytečný detail, na kterém jenom pálíte čas, když těžiště práce je někde jinde.
  • Ergonomie pracovního prostředí. Seděl jsem u jídelního stolu jenom s laptopem. Příjemnější pracovní prostředí by mi třeba pomohlo ještě k větší aktivitě.

Shodou náhod se mnou trávil čas jeden kamarád programátor, se kterým jsem občas konzultoval některé problémy. Pikantní bylo, že na konci už se tak nudil, že pro mě naprogramoval pár drobností. Pokud by měl sebou počítač, a nemuseli bychom se dělit o ten můj, mohl mi pomoci mnohem více. Myšlenka, že tým někam vyrazí a pracuje společně, by v tomhle případě mohla fungovat a dává mi smysl. Navíc tým funguje jako motivační faktor a korekční faktor. Člověk by se cítil ve společnosti geeku přirozeně, když většinu času trávíte u počítače.

Moudro na závěr

Digitální nomádství není pro každého. Pokud si někdo představuje, že s brďolou v ruce na lehátku pod slunečníkem vydělá svůj první milion, pak je ve velkém omylu. Ve výsledku nezáleží na tom, jestli jste tady nebo v Africe, ale kolik času a energie tomu obětujete. Nomádství má dvě strany mince.  Můžete vypadnout z denního stereotypu. Nikdo vás neruší a vy se můžete na plno ponořit do programování, psaní, prostě čehokoliv, na co potřebujete čas a klid. Druhou stranou té mince je, že vám z toho stereotypu možná bude něco chybět například kamarádi, rodina a nebo pracovní prostředí, které vám dopřává jistý komfort. Pokud hodláte spojit příjemné s užitečným, v mém případě sport/zábavu, chce to jistou míru sebekázně. Jinak nic neuděláte, protože mozek bude v režimu prázdnin. Jde o to nastavit si model pracovního dne, kdy to příjemné (zábava) je odměna za to užitečné (práce), kdy bohužel té práce bude trochu více. Na druhou stranu máte tu skvělou svobodu regulovat si ten poměr podle vlastních pocitů.

Kdybych teď znova vyrazil na oněch 14 dní, šlo by mi to určitě lépe, protože jsem si našel režim, který mi to umožňuje skloubit. Jestli bych to doporučil? Nevím, opravdu to není pro každého. Obzvláště pokud nemáte dostatek sebekázně. Jinak to dopadne tak, že zábavu si neužijete a práci neodvedete. Mimochodem doporučuji přečíst článek Dana Tržila Odvrácena strana digitálního nomádství.

 

 

čtvrtek 22. ledna 2015

CZ Podcast 110 - Zátěžové testy

Do dalšího dílu jsme si pozvali Pavla Lukeše a povídali jsme si o zátěžových testech a nástroji Smart Meter, který Pavel vyvíjí ve společnosti Etnetera.

úterý 20. ledna 2015

Mýtus nekódujícího architekta

V poslední době mi trochu chybí kódování a přemýšlím, jestli platí, že nekódující architekt je horší než žádný architekt. Největší nebezpečí nekódujícího architekta vidím ve ztrátě citu pro jemné detaily. Architekt musí mít hlavně kontext, ale udržet si kontext nějakého většího systému znamená, že si holt musí od problému trochu poodstoupit. Jsou to dvě protichůdné síly, které na sebe působí. Poodstoupit si od problému je většinou snazší než si držet cit pro jemné detaily, protože ten nejlépe získáte pokud přímo programujete.

Malá vsuvka, občas mi vstávaly vlasy hrůzou, když během pohovoru kdejaký kandidát na architekta prohlašoval, že jeho představa programování spočívala v přípravě PoC nebo nedej bože zkoušení frameworků. To je dle mého skromného názoru nejlepší cesta k tomu, aby vás začaly vývojářské týmy nenávidět.

Když proto mluvím o programování, mám na mysli to, že si ušpiníte pořádně ruce - což je velký rozdíl oproti tomu rozjet někde HelloWorld a pak prohlásit, že to je ta pravá technologie. Bohužel, aby tohle bylo možné, potřebujete více času než pár hodin týdně. Myslím si, že varování o nekódujícím architektovi vzniklo tím, že práce architekta sklouzla v první řadě k výběru technologií a provádění HelloWorld pokusů.

V GoodData máme dvě role formálně pojmenované architekt. Ta jedna více odpovídá kódujícímu architektovi, protože ten člověk je mnohem blíže scrumovým týmům a jeho odpovědnost většinou nepřesahuje několik služeb. Ten si opravdu ušpiní ruce od kódu hodně často, a u něj by platilo, že nekódování by bylo fatální, protože je součástí dennodenních technických rozhodnutí v nejmenším detailu. Druhá role, které říkáme architekt, už předpokládá, že člověk má představu o fungování systému jako celku.

V mojí práci to třeba znamená, že když stavíme datové centrum v Evropě, mám přehled o tom, jaký to bude mít architektonický dopad, přes různé oblasti systému počínaje bezpečností dat a konče deploymentem. Pro tuhle roli je ten cit rovněž potřeba, protože rozhodnutí typu replikujte data mezi datovými centry, se lehce dělá od stolu s koblihou v ruce, ale má dalekosáhlé dopady na implementaci. Zdá se mi ovšem, že získání toho citu je věcí zkušeností, nikoliv toho, že bych kvůli tomu musel kódovat několik hodin denně.

V téhle roli mi programování spíše chybí, protože to pro mě byla zábava, ale nemyslím si, že je nutností (zatím). Ve většině případů je totiž člověk spíše vyjednávačem, který se snaží, aby se vlk nažral a koza zůstala celá obrazně řečeno. Namísto toho, abyste řešili, jestli použít framework X nebo Y, jestli je lepší používat pro odsazení tabulátory nebo mezery, spíše řešíte návrh a rozšíření systému s ohledem na všechny zainteresované strany - vývojáře, zákazníky, produkt management, podporu, finanční oddělení atp. Doporučoval bych proto místo četby knih typu Sedm jazyků v sedmi týdnech navštívit kurz behaviorální psychologie, vyjednávání a kompromisů, protože o tom ta práce primárně je.