Zabijáci motivace

Dneska tu budu trochu řešit motivaci. Je to téma, které mě dlouhodobě provází a včera mi došlo, že bych si o tom zase chtěl něco napsat. Takže se nedivte, že tu píšu to samé co se dočtete v chytrých knížkách, píšu si, protože se mi chce.

Já mám totiž takový problém. Veliký problém. Peníze mě vůbec nemotivují. Jasně, rád si nechám za práci dobře zaplatit. Na můj pracovní výkon to ale nemá žádný vliv.

Takže musím hledat motivaci jinde. Abych byl přesný, ani ne tak jinde, jako spíše uvnitř. Programováním se živím, protože mě to jednoduše baví. Kromě toho, že můžu sedět v teple a nemusím zvedat nic těžkého, tak mě baví řešit zapeklité problémy, bavíme mě vymýšlet jak to dělat co nejlépe. Mám rád pocit, že jsem něco dokázal, něco vytvořil, někomu pomohl. To tvoření je pro mě hrozně důležité. To je důvod, proč se pořád držím kódování. Člověk může přetvářet myšlenky v něco, co se hýbe, občas i funguje a je to k něčemu dobré. Dobrá, nedá se na to sáhnout, ale tím lépe. O to je člověk svobodnější. Nemusí se babrat s ničím fyzickým, může přímo přetvářet myšlenky.

A myslím, že v tom nejsem sám. Spousta známých i kolegů dobrovolně pracuje o víkendech a dovolených protože je to prostě baví. To se ale máme, v práci děláme to co nás baví. Hurá. Hmm.

Jak to, že tedy nejsem šťastný a spokojený hypervýkonný pracant? Proč v práci věčně držkuju, šéfovi odmlouvám a jinak podvracím morálku? Protože mě neuvěřitelně ničí zabijáci motivace. Seznamte se tedy prosím s novodobými jezdci apokalypsy

Schůze a papírování

Pokud je kódování supersíla, pak jsou schůze kryptonit.

Všichni milujeme schůze, proto si na ně nosíme laptopy, abychom si potěšení ještě znásobili nějakým tím kódováním. O tom snad ani není potřeba mluvit, proto se přesunu k dalším položce v této kategorii, k papírování.

Teď, ve století ovocného netopýra už nepapírujeme papírově, ale elektronicky. O to hůř, papírování je mnohem snazší, takže toho člověk zvládne mnohem víc. Tady musím uznat, že k něčemu papírování může být dobré. Ale přimlouvám se za nějakou rozumnou míru. Zamysleme se občas, kolik nás to všelijaké vykazování, odškrtávání, předávání a čertví co ještě stojí a kolik nám to přináší.

Zmar

To mě přivádí k další kategorii a tou je zmar. Už je to pár let, co jsem dělal u jednoho nejmenovaného růžového telefonního operátora. Na produkci jsem dostal své první čtyři řádky kódu po šesti měsících! Moji radost z tohoto kolosálního úspěchu kalil fakt, že se tam to mé veledílo dostalo omylem. Od té doby už jsem se s takovým pocitem zmaru nesetkal. Ale je to klasický a oblíbený zabiják motivace.

Zkuste sami zavzpomínat, stalo se vám někdy toto? Na něčem makáte. Je to hrozně důležité. Zachrání to planetu od hladomoru. Vyhraje vám to důležitou zakázku. Vydělá balíky peněz. Je to fakt něco. Už je to hotové. Super, můžeme to nasadit. Cože marketing si to rozmyslel? Už to nepotřebujeme? Poprvé se s tím člověk smíří. Podruhé to taky nějak skousne, ale potřetí už vás to fakt srazí do kolen.

Vyrušení a multitasking

Dělám na něčem co mě fakt baví. Už to mám skoro vyřešené. Najednou na mě začne mávat kačer. To mi Adium signalizuje, že se mnou chce někdo četovat. To bude další obdivovatel, kterého můžu ohromit svoji genialitou a bezmeznými znalostmi. Bravurně mu odpovím. Ale i tak mi to pár minut zabere. Cože jsem to předtím dělal? Nevím. Nevadí, využiji vyrušení a kouknu do mailu. Cože, někdo na mě hodil bug? Critical. Hmm, vždyť je to v jiné komponentě. Něco jsem řešil. Co to vlastně bylo? Nemá cenu se k tomu vracet, za pět minut mám schůze a po ní oběd. Odpoledne to samé. Cože jsem to vlastně za dnešek udělal? Nevím.

Dneska jsem si schválně zapisoval co všechno jsem dělal, u dvacátého řádku, někdy ve dvě odpoledne mě to přestalo bavit. Co s tím? Někde mají vyhrazených deset minut v každé hodině na vzájemnou komunikaci. Kolega má v kalendáři vyznačené dopoledne, že nechce být vyrušován. Moc mu to nefunguje. Já vážně přemýšlím, že si to vyhlásím soukromě. Něco v tom smyslu, že pokud minuta nezačíná na 5 nebo hodina není větší než 13 tak nechci být rušen. Alespoň to posílí moji pověst excentrika. Nebo si pořídím klobouk neviditelnosti. Když ho budu mít na hlavě, tak budu předstírat, že tam nejsem. Hmm, abych to s tou svojí pověstí nepřehnal.

Povyšování

Každý je povyšován na úroveň své nekompetence.

Ano, pro mě je povýšení demotivující faktor. Jsem fakt divnej. Ale má to logiku, každá vyšší funkce sebou přináší více schůzí, papírování a vyrušení. Hloupě jsem se nechal jmenovat architektem a teď za to pykám. Zatracená ješitnost.

No, ještě jsem měl pár témat, která jsem tu chtěl rozebrat. Třeba trestání za dobré skutky, řízení metrikami a podobně. Padla z toho na mě ale nějaká chmura. Takže nechám doplnění seznamu na každém z vás.

Abych si spravil náladu, tak se zamyslím nad tím co dělat, když se v takové situaci ocitnete. Nejdůležitější je pokusit se to změnit. Štve vás něco? Tak to změňte. Že jste na to příliš malý pán? Ale jděte. Taky jsem si to myslíval, ale není to tak. Před pár lety jsem tu citoval pana DeMarca.

Osoba, která si nejvíce přeje přehodit tuto zodpovědnost někam výše je přesně tou osobou která ví, že by mohla tuto změnu uskutečnit, ale že to nebude jednoduché.

Zkuste to změnit ze své pozice. Když nevíte jak, tak se seberte, dejte si sraz se šéfem a proberte to s ním. Pak to s ním proberte ještě jednou. Pak znova. Pak pár týdnu počkejte. Pak ještě jednou. No a pak se to třeba pomalu změní.

Místo můžete změnit vždycky, ale věřte zkušenému fluktulantovi. Jinde to o moc lepší nebude. Bude to jiné, ze začátku to bude mnohem lepší, ale pokud jste šikovní, tak vás životní cyklus programátora stejně nemine.

Tomcat throughput (a stupid test)

This week, a colleague of mine had asked me what is the maximal throughput in Tomcat. That he just needs to accept an HTTP request and log the request body. That’s all. How many requests will be handled by Tomcat?

Now stop for a minute and make your guess. Is it
a) 1
b) 10
c) 100
d) 1,000
e) 10,000
f) 100,000

Well, the right answer is that it depends. It depends on your CPU, hard drive, network connection, request size, number of concurrent connections, day of the week and other important factors.

Ok, so I will tell you that I am testing it on an old Lenovo laptop with Intel® Core™2 Duo Processor T8100, 4gigs of RAM and 7200rpm disc, running Linux Mint 11 64bit, Java 6 and Tomcat 7. No performance tuning whatsoever.

I am generating the load from the same machine using JMeter with 50 threads that send requests one after another without any sleep. Each thread sends 20,000 messages containg string “Test ${counter}” where counter goes from 1 to 500,000. Yes, I know that doing tests like this is stupid. Having the test client on the same machine is just wrong. To make it even more stupid, I am writing this article while running the test. On the same old machine, of course.

The data are read from the request reader, stored in a String and sent to Logback to be logged in a file. Nothing fancy. Yes, and I restart the JVM before each test. Another stupid thing. Now you have all the information you need. Make your guess, please.

It turns out that at the and Tomcat is processing ~5,000 request/second. JIT needs some time before it optimizes the code. If I re-execute the test without JVM restart, it gets to ~5,200 requests per second and it does not climb any further. Nice performance. 5,000 request per second.

In my configuration the bottleneck is clearly the CPU. Well, it’s not surprising, JMeter eats half of it. I have also tried to run the test on a MacBook Pro with 8 cores and SSD drive. The throughput is around 22,000 requests per second. Yes, more the 20k requests even in such silly test. On the Mac, JMeter consumes more CPU than Tomcat.

As I have already admitted, my test setup is just wrong. If you want, you may make it better. The source code and the JMeter test are here. It’s just one servlet and few implementation classes, each for different logging strategy (direct, null and using a queue). Feel free to take, change, deploy and test it as you wish. I will be glad to see your results.

JsonUnit

Let me introduce you another of my pet projects. It’s called JsonUnit and it’s something like XmlUnit only for JSON (well it’s much, much more simple). Basically it’s able to compare two JSON documents and if they do not match, it prints out the differences. For example the following test

import static net.javacrumbs.jsonunit.JsonAssert.assertJsonEquals;

...

assertJsonEquals("{\n" + 
			"   \"test\":[\n" + 
			"      1,\n" + 
			"      2,\n" + 
			"      {\n" + 
			"         \"child\":{\n" + 
			"            \"value1\":1,\n" + 
			"            \"value2\":true,\n" + 
			"            \"value3\":\"test\",\n" + 
			"            \"value4\":{\n" + 
			"               \"leaf\":5\n" + 
			"            }\n" + 
			"         }\n" + 
			"      }\n" + 
			"   ],\n" + 
			"   \"root2\":false,\n" + 
			"   \"root3\":1\n" + 
			"}", 
			"{\n" + 
			"   \"test\":[\n" + 
			"      5,\n" + 
			"      false,\n" + 
			"      {\n" + 
			"         \"child\":{\n" + 
			"            \"value1\":5,\n" + 
			"            \"value2\":\"true\",\n" + 
			"            \"value3\":\"test\",\n" + 
			"            \"value4\":{\n" + 
			"               \"leaf2\":5\n" + 
			"            }\n" + 
			"         },\n" + 
			"         \"child2\":{\n" + 
			"\n" + 
			"         }\n" + 
			"      }\n" + 
			"   ],\n" + 
			"   \"root4\":\"bar\"\n" + 
			"}");

will result in

java.lang.AssertionError: JSON documents are different:
Different keys found in node "". Expected [root2, root3, test], got [root4, test].
Different value found in node "test[0]". Expected 1, got 5.
Different types found in node "test[1]". Expected NUMBER, got BOOLEAN.
Different keys found in node "test[2]". Expected [child], got [child, child2].
Different value found in node "test[2].child.value1". Expected 1, got 5.
Different types found in node "test[2].child.value2". Expected BOOLEAN, got STRING.
Different keys found in node "test[2].child.value4". Expected [leaf], got [leaf2].

Neat, isn’t it?