Skip to main content

Musí vás to bavit!

K tomuhle blogpostu mě motivovala přednáška a následná diskuze o deseti vychytávkách na plzeňském barcampu. Pár věcí jak to dělám já nikdo nezmínil, tak je zkusím probrat tady.

Celkem úsměvný moment jsem zažil hned první týden po barcampu, kdy jsem si uvědomil, že každému funguje něco jiného. Pár pracovních dní jsem zkoušet toggl.

Během nich mi ale došlo, že od roku 1984 už něco málo uběhlo a nebudu sám sebe sledovat, ať si to dělá ČSU, NSA, ETC, teda etc. :-) Ještě bych něco zjistil. Teď vážně: pro mě to nedává smysl, otravuje mě to a zapomínám na to. Jelikož se k tomu nevracím, nevidím v tom hodnotu. Uninstall. Takhle skončila moje bitva s toolou, která byla široce zmiňovaná.

Co mi tedy v diskuzi o efektivitě chybělo? No prostě ...

Musí vás to bavit!

Tohle si ne každý uvědomuje. Spoustu lidí honí efektivitu Evernotem, kalendářem, togglem, kanban toolou, blockem stránek v pomodoru nebo trello. Jenže nejvíc do toho dá člověk, kterého ten úkol baví.

Ale jak udělat, aby Vás všechno bavilo? Všechno? To nejde, ale jde tomu pomoct.
Kdysi jsem chodil k Lukáši Konečnému na box. Byla to makačka! Jednou jsme jeli kruháč a najednou slyším jak řvě na kluka vedle mě: "ty debile! Jak to děláš? Vždyť to děláš pro sebe ty vole!". Tahle věta mi utkvěla v hlavě. Kluk byl výrazně lepší než já, ale flákal to.
Na box jsme chodili rádi a dobrovolně, a jen na nás bylo, jestli jsme si něco odnesli nebo ne. Nemuseli jsme, stačilo to odchodit, což by asi stálo Lukáše hlasivky, ale nic víc. S prací je to stejné, zaleží na každém, co si z toho dne odnese.

Co z toho plyne? Jak moc zajímavou si práci uděláte, tak vás bude bavit.

Tak třeba: kdysi jsme měli generální problém s testy. Dlouhá exekuce, kvůli natažení celé infrastruktury pro jednoduché testy, spousta abstraktních předků, spousta nepěkně vonícího kódu. Po malé změně aplikačníhé kódu se musela měnit podstatná část testů. prostě manintance vázla. Testování není moc populární část developerské práce a tak to vyžadovalo přemoct svého slona. Jak to dopadlo? Kopli jsme do toho, přečetl jsem si dvě knížky, trošku jsme mákli, opravili jsme to a teď mám i po dlouhé době v hlavě vrytou velkou znalost a zkušenost testování. A ten pocit vítězství taky k nezaplacení :-)

Při vývoji jakékoliv komponenty tuhle zkušenost opráším, nikdy už neopakuju tu původní chybu. Proč? Sice to nebyla práce po které by Vás šéf poplácal uznale po zádech a objevili jste se na předních stránkách dzone. Ale stačilo to pojmout tak, že se naučíme testování a později to mnohokrát reusneme, prostě během té práce uděláme něco pro sebe.
V rámci každého úkolu můžete udělat něco pro sebe, naučit se něco nového, co se vám hodí, co potom použijete i jinde. Stačí dobře volit.
Američané stále cosi povídají o tom, že všechno je výzva. Ráno se sprchovat studenou vodou, učit se francouzsky nebo do práce rovnou běhat desítku crossem přes park. Výrazně víc mě baví práce, kde si najdu něco zajímavého, co mě někam posune. Tohle mi funguje jako největší hybná síla, jak se posunout dál.

Poslední věc která se k tomu váže. V každé firmě něco nefunguje, ideální firma je mýtus. Jen to někde jde líp a někde hůř. Jeden kolega kdysi vyřkl pěknou myšlenku: "dobrým se nestanete, tím, že se přidáte k dobré firmě. Dobrým se stanete, když něco dobrého uděláte". Někdy je nejlepším krokem pokořit věci, které nás nejvíc rozčilují, ikdyž to není vaše zodpovědnost nebo starost. Tím se naučíte úplně nejvíc.

Koukám, že se původní myšlenka rozlezla na celý článek, takže až příště něco o tom, proč dělám věci ráno a jak používám těch pět minut v pomodoru.

Comments

Popular posts from this blog

Performance Battle of NoSQL blob storages #1: Cassandra

Preface We spend last five years on HP Service Virtualization using MsSQL database . Non-clustered server. Our app utilizes this system for all kinds of persistence. No polyglot so far. As we tuned the performance of the response time - we started at 700ms/call and we achieved couple milliseconds per call at the end when DB involved - we had to learn a lot of stuff. Transactions, lock escalation , isolation levels , clustered and non clustered indexes, buffered reading, index structure and it's persistence, GUID ids in clustered indexes , bulk importing , omit slow joins, sparse indexes, and so on. We also rewrite part of NHibernate to support multiple tables for one entity type which allows use scaling up without lock escalation. It was good time. The end also showed us that famous Oracle has half of our favorite features once we decided to support this database. Well, as I'm thinking about all issues which we encountered during the development, unpredictive behavio

ETCD: POST vs. PUT understanding

ETCD is distributed key value store used as a core component in CoreOS . I've already send a post earlier this week. Here is a page describing how to use ETCD basic commands = ETCD API. Code snippets placed in a page mostly use put , but ETCD allows to use post as well.  Most of us understand differences between those two commands in a notion of a REST(ful) service, but how does it work in key value store? POST Example over many words. curl -v http://127.0.0.1:2379/v2/keys/test -XPOST -D value="some value" curl -v http://127.0.0.1:2379/v2/keys/test -XPOST -D value="some value" Two same command result into following content: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 { "action" : "get" , "node" : { "key" : "/test" , "dir" : true , "nodes" : [ { "key" : "/test/194" , "value" : &