13. listopadu 2017

vimdiff, nástroj drsňáků


Musím se vám k něčemu přiznat... Už patnáct let je Vim můj nejoblíbenější textový editor. A občas, čas od času, i hlavní nástroj na programování.

Umím si poeditovat vimrc, který po léta udržuju a vylepšuju. Dokonce jsem se i naučil trochu Vim script/VimL a napsal dva zanedbatelné a nedotažené pluginy (pro Gradle a WSDL).

Ale vždycky jsem se jako čert kříži vyhýbal jedné věci - používání vimdiff. Nicméně na každého jednou dojde. Z určitých (pro článek nepodstatných) důvodů jsem si nemohl pro nové vývojové prostředí nastavit P4Merge a tak jsem vstoupil do zapovězené komnaty.

Disclaimer: Tenhle článek píšu jako shrnutí toho, jak jsem práci s vimdiff pochopil. Pokud máte víc zkušeností, budu rád, když se podělíte v komentářích.

2-way merge

Nejjednodušší způsob, jak používat vimdiff - pokud pomineme, že umí dělat i "plain old" diff - je 2-way merge: máme vedle sebe dvě okna se zvýrazněnými rozdíly a chceme mezi nimi tyto změny propagovat.

vimdiff, 2-way merge

Stav na předešlém obrázku, který je výchozí pro merge, se dá dosáhnout několika způsoby:
  • Příkazem: vimdiff myFile.txt theirFile.txt
  • Příkazem: vim -d myFile.txt theirFile.txt
  • Kombinací příkazů:
    • vim myFile.txt
    • :diffsplit theirFile.txt
  • Kombinací příkazů
    • vim -O myFile.txt theirFile.txt (vsplit obou souborů)
    • :diffthis (zapne diff na aktuálním bufferu)
    • Ctrl-W Ctrl-W (skok do druhého bufferu)
    • :diffthis(zapne diff v druhém bufferu)

Základní příkazy

Tak, diff máme zobrazený, co s ním? První věc - je potřeba se v diffu umět pohybovat. Kromě toho, že můžete použít jakýkoli skok, který znáte z běžného Vimu, jsou tu dva příkazy, které umožňují skákat po jednotlivých rozdílech:
  • ]c skočí na následující diff
  • [c skočí na předcházející diff

Za druhé - chceme propagovat změny z/do aktuálního bufferu: skočíme na diff, který chceme upravit a:
  • do, nebo :diffget natáhne změny z "druhého" bufferu do toho aktuálního.
  • dp, nebo :diffput propaguje změny z aktuálního bufferu do "toho druhého".

Za třetí - změny uložíme. Kromě příkazů na standardní ukládání (:w, ZZ atd.) se může hodit:
  • :only zavře všechny ostatní buffery kromě toho aktuálního
  • :qall zavře všechny otevřené buffery
  • :only | wq zavře ostatní buffery + uloží stávající + ukončí Vim. Cool!

Eventuálně začtvrté - pokud věci nejdou hladce, může se šiknout:
  • :diffupdate znovu proskenuje a překreslí rozdíly (u komplikovanějších mergů nemusí Vim správně pochopit danou změnu)
  • :set wrap nastavení zalamování řádků (hodí se při velmi dlouhých řádcích, typicky některá XML)
  • zo/zc otevře/zavře skryté (folded) řádky

3-way merge

Nemusím vám říkat, že 2-way merge je pro školáky - profíci makaj v Gitu, či v Mercurialu a tam je dvoucestný merge nedostačující. Ke slovu přichází 3-way merge. Co to je?

Schéma 3-way merge

3-way merge není nic složitého. V podstatě jde o to, že máme dvě verze, které mají společného předka. V mergovacím nástroji pak vidíme všechny tři verze vedle sebe a většinou máme k dispozici ještě čtvrté okno s aktuálním výsledkem merge.

3-way merge v aplikaci


Nastavení Gitu

Nastavení spolupráce Gitu a vimdiff je jednoduché - stačí spustit z příkazové řádky následující sadu příkazů:
$ git config --global merge.tool vimdiff
$ git config --global merge.conflictstyle diff3
$ git config --global mergetool.prompt false
$ git config --global mergetool.keepBackup false

Pokud se podíváte do ~/.gitconfig, měli byste tam vidět:


Nastavení Mercurialu

Nastavení Mercurialu je podobně jednoduché. Otevřeme soubor ~/.hgrc příkazem
$ hg config --edit
a vložíme následující řádky


Sekce [extensions] a [extdiff] nejsou pro merge nutné, ale hodí se, pokud chceme vimdiff používat jako dodatečný externí diff nástroj. Sekundární diff spustíme příkazem hg vimdiff.

Základní příkazy

Základní příkazy jsou stejné jako v sekci 2-way merge, s výjimkou příkazů dp/do (:diffput/:diffget) - pokud bychom je nyní použili, vimdiff nám zahlásí chybu:
More than two buffers in diff mode, don't know which one to use
To je v pořádku: u 3-way merge se ve vimdiff otevřou 4 buffery, všechny v diff módu. Takže do té doby, než se vimdiff naučí komunikovat telepaticky, je potřeba mu říct, ze kterého bufferu chceme danou změnu natáhnout.

vimdiff, 3-way merge v Gitu

Klasické merge flow vypadá následovně:
  1. Začínáme v dolním "výsledkovém" bufferu.
  2. ]c (skočit na následující diff, který chceme mergovat)
  3. :diffget <identifikace-bufferu> získáme změnu z daného bufferu (viz dále)
  4. Opakujeme 2-3.
  5. :only | wq uložíme merge.

Obecně, identifikátor bufferu získáme příkazem :ls. To je ale dost nepraktické a nepřehledné. Další možnost je identifikovat buffer částečným názvem souboru. Tady přichází na pomoc jak Git, tak Mercurial, který přidávají k názvům souborů příhodný suffix.

Merge v Gitu

Git přidává do názvů mergovaných souborů následující suffixy, v pořadí zleva doprava: LOCAL (vlevo), BASE (uprostřed), REMOTE (vpravo). Pro natažení změny z (levého) bufferu LOCAL můžeme použít příkaz :diffg LO.

Výpis bufferů pro Git:
:ls
  1 #a   "./myFile_LOCAL_7424.txt"      line 1
  2  a   "./myFile_BASE_7424.txt"       line 0
  3  a   "./myFile_REMOTE_7424.txt"     line 0
  4 %a   "myFile.txt"                   line 12

Merge v Mercurialu


vimdiff, 3-way merge v Mercurialu

Mercurial přidává do názvů mergovaných souborů následující suffixy, v pořadí zleva doprava: orig (vlevo), base (uprostřed), other (vpravo). Pro natažení změny z (levého) bufferu orig můžeme použít příkaz :diffg orig.

Výpis bufferů pro Mercurial:
:ls
  1 %a   "myFile.txt"                   line 2
  2  a-  "myFile.txt.orig"              line 0
  3  a-  "/tmp/myFile.txt~base.iZwwuA"  line 0
  4  a-  "/tmp/myFile.txt~other.km9Itr" line 0

Co mi (zatím) schází?

Musím říct, že potom, co jsem si vimdiff osahal, pochopil jeho logiku a naučil se jeho příkazy, jsem si ho docela oblíbil.

Jediná výtka zatím jde za jeho neschopností skákat přímo po konfliktech - Git i Mercurial dělají výborně automatické merge a ty jsou samozřejmě vidět ve vimdiffu taky, jako pouhá změna bez konfliktu. Mít nějaký příkaz, který rozlišuje pouhý diff a konflikt, by bylo fajn.

Související články


1. listopadu 2017

Trampoty s JUnit 5

Poslední dobou jsem nepsal moc unit testy... v Javě. Jednak jsem posledního půl roku hodně prototypoval - a tam moc testů nenapíšete - a když už jsem testy psal, tak to bylo převážně ve Scale, nebo v Clojure.

Teď ale naše firma projevila sklony k evoluci, se snahou trochu více zautomatizovat vytváření prostředí a zakládání projektů. Sice to jde mimo mě, ale když jsem byl požádán, ať napíšu testovací projekty v Javě pro Gradle a Maven, chopil jsem se příležitosti a ponořil se do (povrchního) studia JUnit 5.

Vyznání

Obecně musím říct, že pro JUnit mám slabost - začal jsem ho používat na začátku své Java kariéry ve verzi 4.2 (pro pamětníky únor 2007) a tak vlastně celý můj Java-produktivní věk jsem strávil se čtyřkovou verzí. Naučilo mě to hodně - za to, že jsem dnes takový skvělý programátor (ha, ha, ha) vděčím tomu, že mě unit testy naučily psát dobrý design.

Samozřejmě jsem si k tomu občas něco přibral. Už v roce 2008 jsem si mistrně osvojil (tehdy progresivní) jMock 2 a naplno se oddával neřesti BDD. Taktéž TestNG jsem si na pár projektech zkusil. Ale gravitační síla tradičního JUnit a TDD mě vždy přivedla zpátky.

A teď zažívám něco jako déjà vu. Je to podobný, jako když přišla Java 5 - skoro všechny nástroje s tím mají menší nebo větší problém. Java komunita to ještě moc neadaptovala. Když narazíte na problém, StackOverflow často nepomůže. Atd.


Pár aktuálních problémů JUnit 5 se mi podařilo vyřešit ke své spokojenosti. Tady je máte na stříbrném podnose.

Zadání

Zadání, které jsem dostal, bylo triviální - napsat miniaturní Java projekt, buildovatelný Gradlem a Mavenem, který bude mít unit testy. Projekt se bude buildovat na Jenkinsu, potřebuje změřit pokrytí testy pomocí JaCoCo a projít statickou analýzou kódu na SonarQube.

Jak říkám, bylo by to triviální, kdybych si pro testy nevybral JUnit 5.

Gradle

Odpírači pokroku a milovníci XML se mnou nebudou souhlasit, ale já považuju Gradle za základ moderní automatizace na JVM. Včetně (a primárně) buildů. Jak tedy zkrotit Gradle, aby se kamarádil s JUnit 5?

Zatím jsem se v tom nějak moc nevrtal, pač nemám ambice se stát JUnit 5 guru, jen potřebuju běžící testy. Ale je dobré vědět, že:
JUnit 5 = JUnit Platform + JUnit Jupiter + JUnit Vintage (JUnit 5 User Guide)
JUnit Vintage je pro JUnit 4, což nás dnes nezajímá. Zbývá tedy JUnit Platform pro spouštění unit testů a JUnit Jupiter pro samotné psaní testů.

Protože JUnit 5 změnilo pravidla hry, nestačí do Gradlu jenom přidat závislosti - současný Gradle novým unit testům nerozumí a zůstaly by nepovšimnuty. Naštěstí je k dispozici je nový plugin, který přidá do build life-cyclu nový task junitPlatformTest a který umí testy spustit.

Bohužel, plugin ještě pořád není dostupný na Gradle Plugins Portal, ale jen v Maven Central. Tím pádem se zatím nedá použít Plugins DSL :-(

V následujícím minimalistickém Gradle skriptu si povšimněte různých konfigurací pro jednotlivé závislosti:
  • testCompile pro api
  • testRuntime pro engine.


Závislost apigurdian-api je optional a je tam jenom proto, aby se ve výstupu nevypisovalo varování:
warning: unknown enum constant Status.STABLE
    reason: class file for org.apiguardian.api.API$Status not found

Task juPlTe je "zahákovaný" na standardní test task, který se dá použít také.

Spuštění JUnit 5 testů Gradlem

Jedna z killer feature Gradlu je incremental build - pokud nešáhnete na produkční kód, nebo na testy, Gradle testy nespouští. Je prostě chytrej ;-)

Gradle incremental build přeskočí testy, pokukd se kód nezměnil


Maven

Tradicionalisti milují Maven a protože jsem shovívavý lidumil, podělím se i o toto nastavení. Pro Maven platí totéž, co pro Gradle:
  • nový plugin (přesněji Surfire provider)
  • závislost na api a engine v různém scopu


Velký rozdíl mezi Mavenem a Gradlem je, že Maven incremental build (moc dobře) neumí - tupě spouští testy, kdykoliv mu řeknete.

Spuštění JUnit 5 testů Gradlem


JaCoCo pokrytí testy

Zbuildovat a spustit JUnit 5 testy byla ta jednodušší část. S čím jsem se trochu potrápil a chvilku jsem to ladil, bylo pokrytí testy. Vybral jsem JaCoCo, protože mi vždycky přišlo progresivnější, než Cobertura (jen takový pocit, či preference).

Dále budu uvádět jen nastavení pro Gradle, protože Maven je hrozně ukecaný. Pokud vás ale Maven (ještě pořád) zajímá, podívejte se do pom.xml v projektové repository.

Zkrácená JaCoCo konfigurace vypadá takto:


V předešlém výpisu jsou podstatné tři věci: (1) generování JaCoCo destination file je svázáno s taskem junitPlatformTest. (2) Definujeme název destination file. Název může být libovolný, ale aby fungovalo generování JaCoCo reportů, je potřeba, aby se soubor jmenoval test.exec. A za (3), pokud chceme některé soubory z reportu exkludovat, dá se to udělat trochu obskurně přes life-cycle metodu afterEvaluate. (Tohle by chtělo ještě doladit.)

JaCoCo pokrytí testy


SonarQube statická analýza

Sonar vlastně s JUnit nesouvisí. Pokrytí testy už máme přece vyřešeno. No, uvádím to proto, že opět je potřeba jít tomu štěstíčku trochu naproti.

Zkrácená verze Sonar konfigurace je následující (Maven opět hledejte v repo):


Tady jsou důležité dvě věci: (1) říct Sonaru, kde má hledat coverage report (klíč sonar.jacoco.reportPath) a za (2) naznačit, co má Sonar z coverage ignorovat (sonar.coverage.exclusions) - bohužel, JaCoCo exkluduje jenom z reportu, v destination file je všechno a tak to Sonaru musíte říct ještě jednou.

SonarQube statická analýza


Má smysl migrovat?

Jak je vidět, popsal jsem spoustu papíru, není to úplně easy peasy. A tak se nabízí hamletovská otázka: má smysl upgradovat z JUnit 4 na verzi 5?


Výše už jsem zmínil velmi přesnou analogii s Javou 5. Tehdy šlo hlavně o anotace a generické kolekce. Můj povrchní dojem je, že u JUnit 5 může být tahákem Java 8 (na nižších verzích Javy to neběží), takže primárně lambdy a streamy.

Pokud máte stávající code base slušně pokrytou pomocí JUnit 4, tak se migrace nevyplatí. Protože ale JUnit 5 umí (pomocí JUnitPlatform runneru) spouštět obě verze simultánně, je možné na verzi 5 přecházet inkremenálně.

Projekt repository

Na Bitbucket jsem nahrál repozitory jednoduchého projektu, kde si můžete v Gradlu a v Mavenu spustit JUnit 5 testy, vygenerovat JaCoCo report a publikovat výsledek do SonarQube.

16. října 2017

1:1, nejdůležitější nástroj team leadera

Říká se tomu one-on-one. V psané podobě můžete narazit na zápis OoO, O-o-O, 1on1 a různé další. Já používám 1:1, ale kreativitě se meze nekladou.

Za ta léta, co dělám team leadera, jsem se setkal s širokou paletou lidí a jejich zkušeností s 1:1. Jsou tací, kteří 1:1 nikdy neměli a někdy o něm dokonce ani neslyšeli. Jsou lidi, pro které je to jenom takový "manažment folklór". A pak je menšina těch, kteří 1:1 očekávají a vyžadují.

Jak už jsem psal v minulém článku (Technical Leader, mytické stvoření), potřebuju uzavřít určité období a shrnout, co jsem se naučil. Tady je moje moudro:
"Hlavním nástrojem vývojáře je IDE. Hlavním nástrojem Technical Leadera je Issue Tracking System. A hlavním nástrojem Team Leadera je 1:1." ~ SoftWare Samuraj

Můj příběh

Když jsem před nějakými osmi lety začal zvolna aspirovat na roli team leadera (ano, bylo to ještě předtím, než jsem začal psát tenhle blog), šel jsem na to svou obvyklou cestou, která se dá shrnout do tří slov: internet, knihy, praxe.

Hodně mi pomohl Michael Lopp, píšící blog Rands in Repose. Jeho nejlepší články tehdy vyšly v inspirativní knížce Managing Humans, na kterou mě upozornil na svém blogu Lukáš Křečan (jak to ten chlap dělá, že je vždycky o pár kroků přede mnou?).

Já sám jsem do té doby nikdy žádné pravidelné 1:1 neměl, jen takové to klasické performance review. Proto mě šokovalo, že bych měl organizovat 1:1 na týdenní bázi - neuměl jsem si to představit.

V té době jsem v někdejší firmě převzal/zdědil Java kompetenci. V reálu to znamenalo, že všichni seniornější Javisti už z firmy odešli. Nebylo od koho se učit, tak jsem si roli definoval sám. Naplánoval jsem si s klukama semestrální 1:1 a protože byli rozeseti na projektech po celé Praze, chodil jsem tam za nima.

Dalším milníkem bylo angažmá, kde došlo k nepřátelskému převzetí projektu (lehce jsem se tématu dotknul v článku (Ne)funkční tým). Pořád ještě jako juniorní team leader jsem bojoval, jak to šlo, podle svých tehdejších schopností. Jedna z věcí, které jsem zkusil a která byla dobrým krokem, bylo zavedení 1:1. Scházeli jsme se jednou za 1/4 roku.

A pak přišel další projekt - dostal jsem v kulminaci nálož 16 lidí (naštěstí to rostlo postupně). Opět jsem sáhl po knize (článek Management za zavřenými dveřmi) a opět jsem zredukoval periodu - scházeli jsme se na 1:1 jednou za měsíc.

   

Ano, už to přijde. Pointa. Ale tentokrát bez knihy. Když jsem nastupoval do nové práce, měl jsem neobvyklý luxus - mohl jsem si postavit svůj vlastní tým, úplně od začátku. S tímhle novým týmem jsem začal dělat to, co se všude radí bez výjimky - týdenní 1:1. Dělám to tak už téměř pět let a můžu jen konstatovat, že 1:1 je ten nejdůležitější nástroj, který team leader má.

Vize, benefit, smysl

1:1 je nástroj. Je to nástroj používaný mezi dvěma entitatmi - mezi team leaderem a členem týmu, ev. mezi manažerem a reportujícím. Aspektů, které tento nástroj může přinést je mnoho, ale já bych vypíchnul čtyři, které považuji za nejhodnotnější.
  • 1:1 je silný nástroj pro vytváření vztahu mezi team leaderem a členem týmu.
  • 1:1 kritický nástroj pro budování důvěry.
  • 1:1 je také nástroj na vytváření a ovlivňování týmové kultury.
  • A 1:1 je prostor a čas, který team leader dedikuje svým lidem.

Nejkritičtějším elementem je budování důvěry - pokud ve vztahu chybí důvěra, je těch benefitů jenom polovina (a míň).

Pravidla

Každý si umí představit analogii s autem, které potřebuje pravidelný servis, aby dobře fungovalo. Pokud ho zanedbáte (nebo už se to nevyplatí), tak se to nějak promítne, nastřádá. O 1:1 to platí také. A možná i víc, protože lidi nejsou stroje. Tady je pár pravidel, která vám můžou pomoct udržet 1:1 v dobrém stavu.

Pravidelnost

Běháte? Chcete uměhnout maraton (5k, 10k, 1/2 maraton)? Je potřeba, abyste pravidelně trénovali. Učíte se cizí jazyk? Je potřeba, abyste ho pravidelně procvičovali. Učíte se nový programovací jazyk/framework/technologii? Je potřeba je pravidelně používat. Jinak to nemá moc smysl a přínos je malý.

S 1:1 je to stejný. Jak říkal soudruh Lenin: pravidelnost, pravidelnost, pravidelnost. Rytmus je benefitem i podpůrnou konstrukcí.

Nezrušitelnost

Nikdy 1:1 nerušte. Nastavte si to jako železné pravidlo - jestli jste team leader, 1:1 je důležitejší než jakýkoli projekt. Projekt skončí, lidi vám zůstanou.

Když říkám nikdy, jsem si vědom absolutnosti toho slova. Já sám se snažím pít vodu, když kážu víno. Snažím se tomu ideálu aspoň přiblížit. Osobně to mám nastavené tak, že 1:1 ruším jenom když jsem (a) nemocný, (b) na dovolený, (c) na služební cestě. Pokud se něco kritického vyskytne v práci, snažím se 1:1 místo zrušení aspoň přeplánovat.

Rušení 1:1 má ještě jeden důležitý aspekt, ke kterému se vrátím v sekci Doporučení.

Respekt a vychování

Ono to přímo vyplývá ze zmíněného axiomu, že 1:1 je nástroj na vytváření vztahu - chovejte se ke členům svého týmu s respektem. Kromě běžné sociální slušnosti, bych vypíchnul reakci na vyrušení.

Na 1:1 neberte nikomu telefon. Nekontrolujte zprávy. Zdvořile odražte osobní vyrušení. Pokud vaše žena nejede do porodnice, tak vás nic neomlouvá, že se nevěnujete na 100 % člověku, kterého máte před sebou.

Mě když volá žena během 1:1 schůzky... típnu jí telefon. A zavolám potom. Když mi během 1:1 volá šéf, nezvednu mu to. Když šéf během schůzky vpadne do místnosti, řeknu že mám 1:1 a zastavím se potom. Za prvý jsem v právu a za druhý, je to slušnost.

Naslouchejte

Lidé ve vedoucích rolích mají často nepříjemný zlozvyk: moc mluví. I já - jako introvert - tím dost trpím a musím si to neustále (už po léta) připomínat. Někdy se mi to i daří. Naslouchejte. Poslouchejte, co vám kolegové chtějí říct. Když už máte jejich důvěru, tak ji nezahoďte.

Technology free

Předpokládám, že tohle hodně lidí šmahem odmítne, ale stejně to řeknu. Na 1:1 choďte bez technologií. Poznámky si pište na papír. Psát si během 1:1 na počítači - s libovonými bohulibými úmysly - je nevychované a neosobní. Pamatujete? Respekt a budování vztahu.

Pokud opravdu potřebujete mít vaše poznámky archivované na počítači, je to jenom vaše pohodlnost, co snižuje kvalitu komunikace.

Samozřejmě, pokud potřebujete svému kolegovi něco na počítači ukázat, je to v pořádku. Pokud ale před ním frontálně sedíte s počítačem před sebou, je to chucpe.

Obsah

Lidé, kteří se setkávají s 1:1 poprvé, můžou váhat, co je obsahem. Samozřejmě, je to primárně pracovní záležitost. Ale je v pořádku probírat i osobní a rodiné záležitosti. Jak tedy obsah 1:1 definovat?

Ještě než se přesunu k lehce konkrétním bodům, zmíním dva stěžejní principy:
  1. Nechte své kolegy spolu-vytvářet obsah 1:1. Ono i když se podíváte na ten zápis - 1:1 - mělo by to evokovat fifty-fifty, či win-win. Jsou věci, o kterých nemáte ani tušení, že by je vaši členové týmu chtěli řešit.
  2. Přizpůsobte 1:1 každemu člověku. Lidé jsou různí - mají různé povahy, senioritu, externí a životní zkušenosti, sociální a rodinný status. Můžou pocházet z jiných kultur a světadílů. Respektujte to a reflektujte to.

Pracovní témata

Pracovním tématem číslo jedna jsou problémy. Technologické problémy, projektové problémy, problémy ve vztazích v práci. To je to, co vaše lidi nejvíc trápí. Externí záležitosti vyřešit nemůžete, ale můžete aspoň svého kolegu vyslechnout a nabídnout empatii.

Interní problémy jsou dvojího druhu - ty, které daný člověk může vyřešit sám. Možná mu k tomu chybí odvaha, možná neví jak, možná jen potřebuje cítit vaši podporu. A pak interní problémy, které on vyřešit nemůže, ale můžete je vyřešit vy... protože jste (jeho) team leader. Tohle výživné téma by vydalo nejméně na článek - klíčové slovo: coaching.

Tématem číslo dva jsou úšpěchy. I drobné. Co se vašemu kolegovi povedlo? V čem se zlepšil? Co se naučil? Není u toho potřeba používat vyprázdněné superlativy, méně je více. Ale nemělo by to zapadnout.

Téma číslo tři: rozvoj. Co dělá váš kolega navíc, nad rámec "daily job"? Čte knihy? Zajímavý článek na internetu? Osobní projekt? Samozřejmě sem spadají i školení a podobné věci, i když ty se neplánují každý týden.

Téma číslo čtyři (záměrně není v TOP 3): něco jako "mikro-status". Záleží na kontextu. Pokud kolegu potkáváte na denním standupu, asi to nebude tak podstatný, možná i zbytečný. Pokud dělá na jiném projektu, hodí se vědět, jak vypadá aktuální projektový/technologický "snaphot". Bacha na micro-management!

Osobní témata

Asi je jasný, co se tím míní. Rozsah a hloubka se budou lišit od kvality vztrahu a míry důvěry. Já si běžně se členy týmu povídám o sportu, dovolený, rodině, koníčkách apod. Jde hlavně o to, co jste ochotni prozradit vy. (Jenom to nepřežeňte.)
"The most important action that a leader must take to encourage the building of trust on a team is to demonstrate vulnerability first." ~ Patrick Lencioni

Doporučení

Na závěr ještě pár doporučení, která rozvíjejí témata, která už zazněla.

Pokud vše dobře půjde, budete mít 1:1 s daným člověkem léta. Jak váš vzájemný vztah, tak vaše 1:1 by se mělo vyvíjet. Neupadněte do rutiny. Adaptujte (se). Změňte vaše individualizované 1:1 tak, aby to stále byl oboustranně prospěšný nástroj.

Jak už jsem naťuknul - neřešte problémy vašich lidí za každou cenu. Buďte umírnění a nechte je vyřešit maximum problémů, které zvládnou sami. Podpořte je, když selžou. Bez chyb není učení.

Vyhraďte si na 1:1 poznámky dedikovaný sešit. Budete mít historii na jednom místě.

A zlaté doporučení. Pokud vaši lidé odcházejí (z firmy) - stává se to - nerušte jim 1:1, ale pokračujte s nimi až do konce. Ukážete jim, že vám na nich i tak pořád záleží. V opačném případě budou mít pocit, že jste je hodili přes palubu.

Mind Map



Související články


3. října 2017

Technical Leader, mytické stvoření

tl;dr Pokud vás téma zajímá, ale nechce se vám číst dlouhý článek, skočte na sekci Model. Nic jiného číst nepotřebujete ;-)

Into the woods

Jak už jsem letos párkrát zmiňoval, procházím určitým přelomovým obdobím, jehož vedlejším, či hlavním(?) důsledkem je, že opouštím vyšlapané cesty. Prostě jsem si koupil bare-foot boty a sešel z dlážděných cest na trávu a lesní pěšiny.

Není to ale žádné pálení mostů. Jsem za tu cestu, kterou jsem urazil, vděčný a hodně jsem se na ní naučil. A abych mohl tenhle úsek putování uzavřít, rád bych se podělil ještě o několik témat, která do budoucna opouštím. Můj náhled, co to je technical leader, je jedním z nich.

Obiter dictum

Jako formální i neformální technical leader jsem pracoval řadu posledních let - v různém prostředí, pro různé zaměstnavatele, s různými týmy. Také jsem o této doméně hodně četl. Byla to role, která mne neskutečně bavila a ve které jsem se chtěl kontinuálně zlepšovat. Snad se mi to i dařilo.

Zároveň jsem viděl, jak lidé v mém blízkém a občas i (velmi) vzdáleném okolí tápou. Co by mělo být obsahem té role? Jak se mám naučit potřebné věci?

A občas jsem také viděl, jak měli lidé ambici stát se formálním technical leaderem, aniž by tušili co to obnáší a hrnuli se do toho s pouhými romantickými představami a vidinou nově deklarovaného statusu a finančních benefitů.

Kromě toho, že jsem sám v této roli pracoval, jsem i pár technical leaderů vychoval. No, vychoval - řekněme, že jsem jim nestál v cestě (ale to už je jiný příběh).

Takže i když vím, že "tam venku" existují lepší technical leadeři, než jsem já, cítím se trochu povolaný sdílet pár informací a osobních názorů. Už proto, že o tom nikdo moc nepíše. (A pár jednorožců už jsem viděl.)

Model

K roli technical leadera můžete mířit z jakékoli jiné technické role. Pro potřebu tohoto článku budeme vycházet z pozice vývojáře, ale můžete si za něj dosadit "obecného" (či specifického) SW Engineera.

Výchozím bodem by měl být vývojář, který je "rozumně" seniorní. Co znamená ono rozumně, nechám na vašem zdravém rozumnu ;-) Povýšení juniorního člověka na technical leadera nedává moc smysl.

K tomu, aby se člověk stal technical leaderem, musí mít, kromě svého ústředního skillu, ještě nějaký přesah. Co jsem za ty roky vypozoroval, je to většinou přesah do jedné ze tří oblastí: architektura, project management a team leading. A podobně jako u technical leadingu, mohou být tyto oblasti formální i neformální.


tl;dr Pokud jste rychločtenáři, můžete nyní přeskočit na sekci Gotický svorník (model re-visited). Pak už je to opravdu všechno :-P

Developer

Jedním z méně častých, i když také možných typů technical leadedra, je vývojář, který sice nemá přesah do výše naznačených oblastí, ale který má velmi hluboké znalosti své technické domény. Je to ten tzv. guru (trošku devalvované slovo, což?). Ale nejenom to - je také problem-solver a mentor. Umí vyřešit nejen své technické problémy, ale i svých kolegů a zároveň jim dát do "své" technologie potřebný vhled.

Uvádím tenhle typ jen pro úplnost. Většinou je zde někdy tenká, někdy hodně široká a rozmazaná hranice mezi velmi seniorním člověkem a "opravdovým" technical leaderem. Osobně jsem takových moc nepotkal. Ale je to validní cesta, pokud se necítíte povoláni k ostatním typům přesahů.

Architekt

Přesah do architektury je s přibývající senioritou běžný. Jako seniorní vývojář chcete vystrčit hlavu z písku své technické domény a podívat se, co se děje u souseda na dvoře. Časem si možná uvědomíte že mezi vaším (vývojářským) a sousedovým dvorem (architektura) není žádný plot. Jsou to dvě plochy téhož tělesa.

Jako technical leader s přesahem do architektury je vhodné umět navrhnout architekturu a zároveň ji zvládnout kompletně naimplementovat. Nikdy byste neměli z pusy vypustit ohavnou větičku, že něco je "implementační detail". To nechte ivory-tower architektům.

Je vhodné vidět daný software v celosti jeho life-cyclu. Nemít klapky na očích a nesoustředit se jen na aktuální (a nejzajímavější) vývojovou fázi. Jak například vypadají vaše logy? Budou sloužit jen pár měsíců vývojářům, nebo budou supportu/operations pomáhat roky na produkci?

Ovšem, není to jen o vás - je potřeba umět vysvětlit vaše návrhy svým méně seniorním kolegům a také jim pomoci s úseky, které jsou nad jejich síly (technicky, designově, myšlenkově).

Projekt Manager

Často se setkávám s tím, že vývojáři vlastně neví, za co je platí. Že dostávají peníze za to, že (efektivně) vyřeší nějaký business problém. To je věc, kterou si velmi dobře uvědomuje project manager - zná finanční rozměr projektu a měl by mít plán, jak to zvládnout.

Jako technical leader s přesahem do project managementu je vhodné umět sestavit implementační plán (v libovolné vyhovující formě). Naplánovat iteraci. Prioritizovat. Zvážit smysluplnost investovaného úsilí. Seřadit a spravovat časové slouslednosti - aby si vývojáři s tunelovým viděním nestěžovali, že je "něco" blokuje.

A také umět předvídat, odhalovat a mitigovat rizika. Umět řešit a případně eskalovat problémy: chybějící lidi, externí závislosti, nečekané události. Navrhnout a řídit vývojovou metodologii a umět ji podle kontextu modifikovat a přizpůsobit.

Team Leader

Team leader a technical leader jsou často překrývající se, nebo zaměňované pojmy. Temínem team leader zde myslím toho, kdo pracuje s lidmi, vede tým a má za něj zodpovědnost.

Jako technical leader s přesahem do team leadingu je vhodné... vést lidi. Komunikovat se svým týmem. Řešit jeho problémy a objevovat příležitosti. Mít individuální přístup k jeho členům - každý z nich je originál. Vystupovat jako facilitátor.

A nejpodstatnější věc - mít vizi a udržovat týmovou kulturu. Působit preventivně proti bad apples. Vytvořit dobře promazaný stroj, který vyhraje softwarové play-off.

Budu k vám upřímný. Tenhle přesah je ze všech nejtěžší a nejvíc adeptů na něm ztroskotá. Jde o to, se nepoložit a pokračovat. Zkusit to znova, až to půjde. Ono to půjde.

Gotický svorník (model re-visited)

V předšlých sekcích jsme naznačili možné přesahy, které může technical leader mít, kromě svého core-skillu. Někdy má přesah jen do jedné z těchto oblastí, někdy do dvou. Nejcennější ale je, pokud má přesah do všech tří domén a působí tak jako svorník klenby, která z těchto pilířů vyrůstá.


V reálním světě měnících se potřeb a požadavků, se ty přesahy budou organicky měnit a přelévat, někdy i během krátké doby (jednoho projektu). I když ale daný skill není zrovna potřeba, pořád obohacuje všechny zbývající aspekty.

Technical... Leader

Většina adeptů na technical leadera se soustředí na to první slovo v názvu role. Ale to druhé slovo - leader - tam není náhodně. Osobně bych řekl, že tenhle aspekt je v celkovém přínosu a smyslu ten důležitější. Protože technical leader, který není leader je jenom seniorní vývojář.

Důvod, proč je tato druhá složka opomíjená, je celkem prostý - techničtí lidé z ní mají obavy. Jak se stanu leaderem? Všichni uvidí, že to neumím! A tak se soustředí na to, co už dobře znají... technologie. Komfortní bublina. A možná tak trochu čekají, že ty věci kolem leadershipu, tak nějak přijdou samy. Snesou se z modrého nebe jako vavřínový věnec nesený holubicemi...

Ale něco vám řeknu: vy už jste se jako seniorn vývojáři narodili? Že ne? Že to trvalo léta praxe a učení se? Jasně, jasně. Prozradím vám tajemství: nic jako "natural born leader" neexistuje! Vede k němu úplně ta samá cesta, jakou jste už sami ušli. Zadejte si do Googlu heslo natural born leader a budete vědět, na čem ještě potřebujete pracovat. Většinou je to práce na celý život. Ale někdy se začít musí.

Jediná cesta?

Samozřejmě, že role technical leadera má mnoho podob. Kdybychom chtěli pokračovat v naznačeném modelu, mohli bychom přidat jako další oblast přesahu například business analýzu. Nebo QA. Nebo... Anebo modelovat/definovat tuhle měňavou roli úplně jinak.

Podstatné je dát vaší roli technical leadera to, co váš kontext potřebuje. Cesty páně jsou nevyzpytatelné a matka příroda je flexibilní a přizpůsobivá. Nechť vás síla na vaší cestě technical leadera provází.

Doporučená literatura

Pokud jste dočetli až sem, tak jste možná opravdoví čtenáři. A ti čtou opravdové knihy. O technical leadingu už pár titulů napsáno bylo. Jestli můžu doporučit jeden z nich, je to kniha Becoming a Technical Leader od Geralda Weinberga (@JerryWeinberg), která je jako truhlice narvaná drahokamy. Některé nedoceníte hned. Jak říká Jerry:
"Becoming a technical leader is not something that happens to you, but something that you do."

Související články


Související externí články



19. září 2017

Střípky z prototypování II: WebSockets

V úvodním díle jsme se dívali na jednoduchý prototyp - jak spojit dvě etablované webové technologie: Wicket a Spring. Bylo to takové zahřívací kolo, ještě o nic nešlo. Spíše o to, připravit si prototypovací platformu, než vyřešit zapeklitý technický problém.

V dnešním díle se podíváme na prototyp, jehož negativním výsledkem mohla být výměna GUI technologie, což by vedlo k refaktoringu cca 1/3 aplikace.

Kontext

πάντα χωρεῖ καὶ οὐδὲν μένει ~ Ἡράκλειτος
Jak říká Hérakleitos z Efesu: "všechno se mění a nic nezůstává stejné". To se tak stane, že zákazníkovi prodáte určité řešení. Všude - v odpovědi na RFQ, v kontraktu, na workshopech se zákazníkem - prezentujete, že GUI určité aplikace bude "wizard-like".

Vyberete technologie, nastřelíte aplikační prototyp a začnete vyvíjet business features. Vývojáři studují a postupně si osvojují nové technologie. Svět je krásný...

A pak přijde UX designer a hodí vám do toho vidle. Řekne, že uživatelé milují skrolování a cool, že jsou Single Page Aplications (SPA). A vy si uvědomíte, že GUI technologie, kterou jste zodpovědně vybrali (možná i nějaká bezesná noc tam byla), se se změnou paradigmatu není schopná vyrovnat.

Use Case

Cíl tohoto prototypu byl přímočarý: zpropagovat data, která přijdou na server z bezstavové RESTové služby do prohlížeče konkrétního uživatele a překreslit určitou část obrazovky, aby se tato data zobrazila. S nadsázkou jsem tomu říkal: přidat "reactive-like" chování.

Podmínkou samozřejmě bylo, aby zůstaly zachovány stávající technologie (tedy Spring a Wicket). Pro úplnost dodám, že Wicketovské komponenty jsou vždy stavové.


Implementace

Implementaci jde rozdělit do dvou kroků:
  1. Zpracování RESTového volání a propagaci dat do Wicket komponenty na serveru.
  2. Push dat ze serveru do konkrétního prohlížeče.

Observable Cache

První bod můžeme realizovat pomocí Observer patternu - do řešení přidáme další element, který zatím budeme nazývat observable cache (a více si o něm povíme v příštím díle). Observable cache nám bude fungovat jako synchronizační mechanizsmus:
  1. Wicket komponent se zarigistruje jako observer do observable cache.
  2. REST kontroler vloží data do observable cache.
  3. Observable cache notifikuje zaregistrované observery (wicket komponenty).


Jelikož observable cache je pro nás zatím abstraktní komponent, jehož technologie/implementace bude vybrána později (a navíc pro nás momentálně není podstatná), vytvoříme si ji pro začátek jako jednoduchou observable HashMapu. Pro začátek budeme chtít notifikace pro metody put a remove.


Následně zaregistrujeme Wicket komponentu (Panel) jako observera. Potřebná WebSocket logika půjde do metody update(). Prozatím ji necháme prázdnou, než probereme, jak se Wicket staví k WebSocketům.


Wicket a WebSockety

Je to taková matrjoška. Existuje WebSocket specifikace. Ta je implementována Java API for WebSocket (JSR 356). A Java API je pak obaleno Wicktovskou implementací/rozšířením. Wicketovská dokumentace je popsaná v referenční příručce v kapitole Native WebSockets. Některá témata zde chybí, ale je to dobrý začátek.

To, co Wicket k WebSocketům přidává a co také využijeme pro náš případ (a co také chybí v dokumentaci), je "broadcastování" WebSocket zpráv. V základě to umožňuje poslat WebSocket událost všem komponentům, které mají definované WebSocketBehavior. Komponent pak může přijatou událost dále filtrovat a rozhodnout se, jestli na ni reagovat.

To, že náše aplikace bude WebSocket-ready, nám zajistí náhrada klasického WicketFiltru za JavaxWebSocketFilter:


Tady trochu odbočím od WebSocketů k servletům. Aby WebSockety fungovaly, musí je podporovat servlet kontejner, ve kterém aplikace poběží (všechny moderní kontejnery by to měly umět).

V rámci popisovaných prototypů probíhá deployment jako součást buildu, do embedovaného servlet kontejneru, který nám poskytuje výborný Gradle plugin Gretty (k dispozici jsou Jetty a Tomcat). Bohužel, našel jsem tady pravděpodobně bug - WebSockety nefungují v embedovaném Jetty, takže je potřeba používat embedovaný Tomcat. (Ve standalone Jetty funguje všechno jak má, takže to bude problém Gretty.)

Zpátky k WebSocketům a Wicketu. Nyní, po notifikaci z observable cache, chceme z metody update broadcastovat WebSocketEvent a opět ji odchytit ve Wicket panelu, který budeme chtít překreslit. Data pro model komponentu si vytáhneme přímo z cache.


Pokud se podíváme na tento proces z hlediska kódu, potřebujeme ve Wicket komponentu aktualizovat pár věcí:
  1. V konstruktoru přidat na komponentu WebSocketBehavior.
  2. Z metody update broadcastovat IWebSocketPushMessage.
  3. V metodě onEvent zprávu přefiltrovat.
  4. Nechat komponent (nebo jeho část) překreslit.
  5. V rámci překreslení dojde ke znovu-načtení modelu.


Prototype repozitory

Pokud si budete chtít prototyp spustit a trochu si s ním pohrát, naklonujte si následující Bitbucket repository. Součástí prototypu je SoapUI projekt, s připraveným REST requestem, kterým si můžete poslat data do prohlížeče.

Klíčové třídy:

Poučení

Občas se ukáže, že řešení, které jsme odkládali jako nejzažší možné, je nakonec to správné. Nebo jediné funkční. Je potřeba zvážit potenciální důsledky - např. přepisování GUI vrstvy versus pozdější perfomance problémy (kolik WebSocket spojení bude v produkci otevřených? Jaký bude objem broadcastovaných zpráv? apod.)

Zvolili jsme na počátku dostatečně flexibilní technologii, aby uspokojila i nároky v úvodu zmiňovaného Hérakleita z Efesu? (Eh, chtěl jsem říci šíleného UX designera.) Malý, rychlý prototyp může dát na tyto otázky odpověď. Nebo aspoň vyznačit cestu, kudy ne.

Příště

V pokračování střípků se podíváme na to, čím nahradit observable cache. Můžete se těšit na sebevražedný deathmatch Neo4j vs. Infinispan.

Repository všech prototypů


Související články



16. září 2017

Smutná zpráva o stavu IT trhu

Aneb jak dělají technické pohovory jinde

Strávil jsem teď posledních pět měsíců hledáním nové práce. Nebylo to radostné období, bylo to tristní. Celkový dojem by se dal shrnout do jedné věty:

V oblasti IT jsme jen levná montovna aut.

Zaměstnavatelé (IT firmy) nehledají ani kreativní lidi, ani problem solvery, ani autonomní vývojáře. Nehledají lidi, kteří se konstantně učí a zlepšují. Ne. Místo toho hledají někoho, komu jeden bývalý kolega říkal láskyplně makáči. Občas jim někdo méně něžně říká lopaty. A já to řeknu natvrdo:

Většina firem u nás hledá programátory, které potřebují posadit rovnou k soustruhu, či k pásové výrobě.

A když to trochu víc zgeneralizuji, hledají lidi s fixním mindsetem. Zapomeňte na to, že byste se ještě někdy mohli něco naučit. Je potřeba, abyste sekali šroubky, jeden jako druhý. Jediným doporučením je, že jste navlas stejné šroubky dělali v minulosti (která skončila včera).

Silná slova, nebo jak to teda je?

Tak, bulvární úvod už máme za sebou, pojďme se na to podívat trochu objektivněji. V rámci možností. V tom, co jsem napsal v úvodu, se můžu těžce mýlit. Je to jenom odraz toho, jak interpretuji technická kola pohovorů, který jsem absolvoval. Hodně to reflektuje rozpor mezi tím, co firmy (a jejich techničtí lidé) říkají a jak reálně konají na pohovorech.

No a samozřejmě, ať to zazní hned na začátku - mám spoustu chyb a nejsem rytíř v blyštivé zbroji. Možná že celou situaci špatně čtu a prostě nedosahuji "standardních" nároků, které dnes IT trh vyžaduje. Možná mi jenom ujel vlak. Jako introvert, si to myslím polovinu času.

Moje reflexe je silně poznamenaná zpětnou vazbou, které se mi dostalo. Je po léta smutným faktem českého trhu, že v 80 % dostanete jako jediné vyjádření kultovní větu:
"Pro další jednání jsme upřednostnili uchazeče, kteří přesněji odpovídali aktuálním požadavkům pozice."
Nic proti rozhodnutí. Jen vám to tak nějak nepomůže, že jo? (A jsme zase u toho fixního mindsetu.)

Rozsah a forma

Dále neuvádím všechny pohovory, které jsem absolvoval, jen ty, kde proběhlo aspoň nějaké technické kolo (v libovolné formě). Uvádím vždy:
  • Anonymizovaný typ firmy a název pozice.
  • Krátký popis technického kola.
  • A pak asi to nejcenější - reflexi.
  • Formální, či neformální zpětná vazba od pohovorující strany.
  • Černobílé hodnocení mindsetu: fixed/growth.

Upozornění

Tento článek je převažně negativní. Proto bych zdůraznil, že je primárně o procesu, ne o lidech. Pokud se někde vyjadřuju rozporuplně o pohovorujících, jde o názorovou neshodu a nevypovídá to nic o jejich charakteru, nebo schopnostech.

Start-up inkubátor, System Engineer

Technický pohovor

Technický pohovor měl formu videocallu, cca 1-1,5 hodiny a povídali jsme si o tématech Computer Science, Software EngineeringDistributed Systems a Functional Programming. Ptali se mě mmj. na věci jako:

Potenciální další kolo bylo vědomostně ve stejném rozsahu, ale on-site, cca na 1/2 dne a "víc do hloubky".

Reflexe

Byl to můj první "start-up" pohovor v životě a tak mě dost zaskočilo tunelové vidění pohovorujících. Dvě třetiny otázek jsem nebyl schopný zodpovědět, protože:
  • jsem je v praxi nikdy nepotkal,
  • brali jsme je před 12 lety na škole a od té doby jsem je nikdy ani prakticky, ani teoreticky nepoužil,
  • nastudoval jsem si je před časem po večerech čistě z hobby-zájmu a nebyl je schopný z hlavy plynule přednést/vysvětlit (konkrétní příklad: před 5 lety jsem si nastudoval Hadoop, na blogu jsem se dostal jenom k zápisku o HDFS).

Z pohovoru i z následného (podmínečného) pozvání do dalšího kola jsem měl neodbytný dojem semestrální zkoušky - nastudovat, dostat zápočet, zapomenout. Když jsem se ptal, zda určité věci, na které se ptají, opravdu používají v praxi, otevřeně řekli, že ne, ale "tím si u pohovoru prošli všichni", tak by nebylo fér to v interview nemít i nadále.

Mým silným pocitem bylo, že si se mnou neví rady - jejich core business a technologie jsem neznal, zároveň "cítili", že "něco" vím (takže to nebylo na přímé zamítnutí), ale nevěděli, jak se k "tomu" dostat, jak se zaptat.

Přímým důsledkem tohoto pohovoru jsou dva články na blogu (CAP Theorem a Covariance & Contravariance) a téměř absolvovaný kurz Functional Programming Principles in Scala. Jaké bylo mé překvapení, když jsem zjistil že pohovorové otázky z funkcionálního programování kopírují témata z kurzu. Nic proti Martinu Oderskému - jeho kurz je výborný. Ale Scala je jen podmnožinou FP a některé věci nedávají v jiném jazyce smysl (třeba covariance/contravariance v Clojure).

Zpětná vazba

Musím ocenit následnou, celkem obšírnou zpětnou vazbu, kde byly v mailu rozebrány jednotlivé oblasti, s doporučením, na co bych se měl zaměřit, pokud bych chtěl pokračovat do dalšího kola.

Mindset

Fixed ⚔

Machine Learning start-up, Software Developer

Technický pohovor

Tady to nebyl úplně klasický přijímací proces - sešli jsme se opakovaně, na několik neformálních rozhovorů, kdy jsme se vzájemně přestavovali a poznávali. Nejvíce technické pak bylo řešení architektonicko-integračního zadání na white-board a firemní představení dvou projektů, hlavně z technického pohledu, kde jsem se mohl ptát spoustu technických otázek (předpokládám, že z toho se dá leccos poznat).

Reflexe

Velice příjemná forma pohovoru, postavená na vzájemném respektu (to není úplně samozřejmé). Musím ocenit přizpůsobení technické části mé aktuální roli a senioritě (celkem výjimečné).

Zpětná vazba

Vzhledem k neformálnosti a otevřené formě rozhovorů jsem měl pocit jakési "instantní" zpětné vazby.

Mindset

Growth ✔

Marketing eCommerce start-up, Functional Developer

Technický pohovor

Technický pohovor se skládal z rozhovoru o technických řešení z mé praxe a z implementace cons funkce... na papír.

Reflexe

Můj pohovorující byl evidentně velmi seniorní funkcionální programátor. Bohužel, jsme nenašli společnou platformu pro diskuzi o technických řešení. Pokud popisujete integraci přes RESTové služby na úrovni API a jste neustále přerušováni dotazy co přesně v ten moment chodí v hlavičkách na úrovni TCP protokolu a ani po 30 minutách se nedoberete bodu, kdy si sladíte terminologii; máte problém - pokud nejste schopni se domluvit na pohovoru, těžko to budete zvládat později v práci.

V programování na papír jsem extrémně slabý. Re-implementaci nízhoúrovňových funkcí považuji za ztrátu času (pokud zrovna na škole nestudujete předmět Algoritmy).

Zpětná vazba

Zpětná vazba byla, že pro core business firmy nejsem vhodný, ale "kdybych nebyl tak drahý", tak bych se mohl věnovat vedleší činnosti - přesýpání dat, klidně v Clojure, kde by to nebyl takový problém. Doufám, že se mi podařilo zachovat poker-face.

Mindset

Fixed ⚔

Český internetový hegemon, Developer of Advanced Systems

Technický pohovor

Prvně jsem online absolvoval Java test na Codility. Šlo o dvě úlohy, které bylo potřeba vyřešit a odevzdat během 90 minut. První úloha byla naimplementovat algoritmus na prokládání řetězců, něco jako: 12 + 98 = 1928. V druhé úloze jsem měl vymyslet(!) a naimplementovat algoritmus na počet kroků v geometrické spirále.

Pak jsem byl pozván on-site na pohovor s HR paní, v jehož závěru jsem psal na dedikovaném počítači kombinovaný Java-Python-C++ test, 75 otázek během 45 minut (nevím, jestli si správně pamatuji ten čas, každopádně to byla míň než minuta na otázku). Třetina otázek byla z Javy, třetina z Pythonu, třetina z C++.

Reflexe

Nemám slov. Tak špatně udělané technické kolo jsem během své kariéry ještě nezažil. Jsou to takové ty absurdity života, kdy přemýšlíte, jestli nejde o nějakou skrytou kameru. A když za váma zaklapnou dveře, máte potřebu se hystericky smát, abyste neztratili pojítko s vesmírem, který jste doposud obývali, než jste vsoupili do budovy.

Docela by mě zajímaly myšlenkové pochody člověka, který takovou frašku "designoval". Ještě bych tak akceptoval Codility jako jakýsi filtr pro ne-programátory. Byť vymýšlení algoritmu s tikajícíma hodinama v pozadí patří spíš do ranku "konkurz na McGyvera".

On-site test pak rezignuje na jakoukoliv konvenční racionalitu:
  • 2/3 testu nemají relaci jak ke kandidátově minulosti (v Pythonu jsem nikdy komerčně neprogramoval, v C++ ani jako hobby), tak potencionální budoucnosti (šlo o čistou Java pozici). Asi množstevní sleva, nebo snaha ušetřit.
  • Cca 40 sekund na otázku je asi z důvodů, aby kandidát nepřemýšlel, případně mechanicky tahal z trouby rozpečené polotovary.
  • Ad absurdum dotažené obskurnosti syntaxe daného jazyka ve stylu "kompilátor v hlavě intoxikované LSD".
  • Java array je "first class citizen", zapomeňte na cokoliv, co přišlo po Java 1.1. Třeba znalosti Javy 8 nejlíp otestujete tak, že se trváříte, že kolekce nikdy neexistovaly.

Zpětná vazba

Nesmím opomenout zdůraznit: nulová zpětná vazba:
"Pro další jednání jsme upřednostnili uchazeče, kteří přesněji odpovídali aktuálním požadavkům pozice."

Mindset

Extremely Fixed ⚔

Big Data start-up, Erlang Developer

Technický pohovor

Prvním krokem bylo programovací zadání, s deklarovanou náročností cca 1/2 dne, které mělo být odevzdáno do 24 hodin. Zadání bylo velmi vágní. K vypracovanému zadání přišly připomínky, které jsem měl zhruba do týdne doimplementovat a znovu odeslat. Odevzdání probíhalo mailem.

Následovalo on-site kolo, kdy jsem postupně mluvil s dvojicí sysadminů/operations, dvojicí architektů a dvojicí vývojářů (Java a Erlang).

Se sysadminy jsme si povídali hlavně o unixu a jak hledat problémy v produkčním prostředí. S architekty jsme si u white-boardu popovídali o jednom z mých projektů.

S Java vývojářem jsme si (tuším) povídali o vypracovaném zadání. Bohužel si víc nepamatuji, protože to všechno přebyl jeden detail (viz reflexe). S Erlang vývojářem to byla klasika - přinesl si papír a tužku. Už tušíte, že jo? Naimplementovali jsme si funkci na parsování regulárního výrazu.

Reflexe

Programovací zadání bylo celkem zajímavý - naimplementovat RESTovou službu s určitou business logikou. V čem jsme se podstatně rozcházeli, byla časová náročnost - z mého pochopení zadání by toto zvládnul naprogramovat za půl dne jenom superman. Já jsem na zadání, i s dopracováním, strávil 2 MD čistého času a i tak významně prioritizoval, co jen nastínit a co udělat v rozumné kvalitě.

Co mě dost otrávilo, bylo dopracování zadání - doimplementovat persistenci. Jakože cože?!? To je zadání pro studenty průmyslovky?!? Kdybych to měl řešit na pohovoru já, tak si o tom tváří v tvář popovídáme a za 5 minut se není o čem bavit. Aby to pro mne nebyla ztráta času, aspoň jsem si vyzkoušel verzování databáze přes Flyway (zůstalo nepovšimnuto).

Rozhovory se sysadminy a architekty byly celkem očekávatelné a nemám, co bych vytknul, či vyzvedl. S programátory to byla jiná. Začněme Javou. Napsal jsem v zadání kus takovýhleho kódu:


Když pominu design (brilantní kód zkrátka na první dobrou nepíšu), obsahuje tenhle kód jeden podstatný problém - iteruje se přes mapu, místo aby se k ní přistupovalo přes klíč. Pohovorující kolega mne na tento detail upozornil.
  • "Ano", říkám, "to je chyba".
  • "Byl jste ve stresu, když jste to psal?", ptá se.
  • "To bych ani neřekl, spíš jsem některým věcem dával nižší prioritu - postatný pro mne byl fungující, buildovatelný a spustitelný projekt.", vysvětluji.
  • "No dobře, ale z mapy se hodnoty vytahují přes klíče, to je přece základ.", vrací se k tématu.
  • "Ano", souhlasím, "byla to chyba."

Takhle to ještě chvilku pokračovalo, až se z toho stal nejsilnější pocit z interview - já jsem ten pro kterého je normální iterovat přes mapu, místo použití klíče. Je smutné, když se dva seniorní vývojáři baví o takové trivialitě tak dlouho a navíc spolu od počátku souhlasí. Ale možná, že mnou spáchaný hřích přehlušil veškerou další komunikaci.

No budiž, je to pohovor na Erlang programátora, nechme Javu odpočívat v pokoji. Takže: v praxi, stejně jako na pohovoru, je důležité:
  • Programovat na papír.
  • Re-implementovat esenciální core funkce jazyka (regex match)
  • Předpokládat, že funkcionální termíny jsou obecně platné, bez ohledu na kontext (přece když řeknu list, tak je jasné, že myslím spojitý seznam z cons buněk - žádné jiné typy seznamů přece neexistují).

Myslím, že o funkcionálních programátorech možná napíšu satirický článek.

Zpětná vazba

Hodně zklamaný jsem byl ze zpětné vazby - do pohovorů jsem investoval 2,5 MD čistého času (zadání + pohovory) a výsledkem byly dvě věty:
"Ačkoliv kolegové hodnotili setkání s Vámi jako zajímavé, bohužel do finálního kola budeme zvát jiného kandidáta. Dle kolegů se zcela nepotkávájí Vaše dosavadní znalosti s technickou profilací naší role a nebyli bychom schopni plně využít Vaše zkušenosti."
Vezměte si dení sazbu seniorního vývojáře za 2,5 MD a na druhou misku vah položte informaci, že jste "zajímavý". Neocenitelné, což?

Mindset

Fixed ⚔

Data Management produkt, Java Developer

Technický pohovor

Byl jsem požádán o zaslání odkazů na své public repository. Poslal jsem link na Bitbucket a GitHub a vypíchnul jsem dva hobby projekty (oba v Groovy).

Následovalo on-site technické kolo, kde dva seniorní vývojáři převáženě zodpovídali mé otázky o své práci. Překvapivě jsem se o jejich technickém řešení dozvěděl méně, než z předešlého rozhovoru s CTO, který mi nakreslil a vysvětlil blokové schéma. Vývojáři jen povídali a asi předpokládali, že už všechno vím.

Na prodiskutování mého kódu nezbyl čas, vybavuji si jen jednu povšechnou otázku na Groovy/Gradle. Na závěr byla půl hodina live-programování v Javě, implementace algoritmu procháze bludiště... v NetBeans IDE.

Reflexe

Že jsme neprobírali můj kód, považuji za chybu. Já chci před pohovorem kandidátův kód nejen vidět, ale hlavně ho s ním prodiskutovat. Jak říká Linus: "Talk is cheap. Show me your code." Ta diskuze je důležitá - pokud si z něčeho uděláte představu, aniž byste znali kontext, dojdete pravděpodobně k mylným závěrům.

Závěrečné live-programování považuji za druhou nejhorší zkušenost z popisovaných technických kol. Jako jediné pozitivní hodnotím, že jsem požadovaný algoritmus nemusel vymýšlet, ale byl mi vysvětlen.
  1. Programování probíhalo v NetBeans IDE, které nejen že nepoužívám já, ale ani nikdo v inkriminované společnosti! Na otázku: "Jak se v NetBeans dělá XYZ?", vám odpoví: "Nevím."
  2. Před-připravený "projekt" v IDE, byla jediná Java třída, zabírající vertikálně asi 5 obrazovek.
  3. Top třída obsahovala několik vnitřních tříd (i doménových). Trochu mi to připomnělo Javu před 10 a více lety, ještě než se rozmohly best-practices a Spring.
  4. Top třída vesele kombinovala static a non-static membery, kteří se vzájemně provalávali.
  5. Před-implementovaná část nahodile kombinovala procedurální a objektový přístup.
  6. Projekt neobsahoval žádnou přípravu pro unit testy, byť mi bylo řečeno, že pokud chci, můžu si testy napsat. Ano, pokud mám na zadání 30 minut, budu v IDE, který neznám rozcházet jak spustit unit testy (co třeba závislosti?).
  7. Pohovorující seděl celou dobu naproti mně a neviděl, co píšu. Prostě čekal, až skončím.

Přiznám se, na tomhle cvičení jsem pohořel. Ne že bych nic nenapsal, ale byl jsem trochu paralyzován. Asi na mě byl žalostný pohled, protože jsem byl požádán, abych napsal metody equals a toString. Nevěřícně jsem tak učinil.

Na závěr jsem byl požádán o zhodnocení. Přiznal jsem porážku a snažil se být diplomatický ve vysvětlení. Zakončil jsem tím, že daný kód, ten před-připravený projekt, by chtěl těžce zrefaktorovat.

Teď už být diplomatický být nemusím: Myslím, že je ostuda takový špatný kód ukázat kandidátovi na pohovoru. Je to první kód, který kandidát od firmy vidí. Pokud tato nemá problém ukázat něco takového, jako svou vizitku - rozumněj, něco čím můžu kandidáta nalákat - jak pak asi vypadají její produkční kódy?

Možná, že ve skuktečnosti píšou interně nesrovnatelně lepší kód. Potom ale hodně zanedbávají pohovory. Říkám si, jaké kandidáty asi chtějí tímto způsobem nabrat?

A ještě jedna poznámka - opět jedna z těch firem, kde musíte umět Java array jak když bičem mrská. Že od Java 5 používáte výhradně collections framework a v polích už nejste tak "fluent" jako kdysi, není argument.

Zpětná vazba

Zpětná vazba bylo dvojí. Jednak, hned po interview, mne zaskočila informace, že mne pohovorující kolegové "nepovažují za programátora". Budiž, názor je potřeba respektovat.

Následně jsem pak mailem dostal vyrozumění, které považujuza ilustrační příklad fixního mindsetu:
"Vaše zkušenosti a schopnosti jsou velice seniorní, bohužel však Vám nemůžeme nabídnout odpovídající pracovní pozici, kde byste tyto schopnosti uplatnil. To co děláte opravdu velmi dobře a na co se ve své práci zaměřujete, bohužel neodpovídá tomu, na co bychom se aktuálně v <jméno firmy> zaměřovali a není to v plánu ani v dohledné době, nebyli bychom tedy schopni Vám nabídnout odpovídající výzvy a začlenit Vás do některého z týmů."
Holt, s čím se jednou narodíš, s tím si musíš vystačit až do smrti. Proces učení se je iluze.

Mindset

Fixed ⚔

Velká (nejen) Java korporace, Big Data Engineer

Technický pohovor

Prvním kolem bylo zadání, které se skládalo ze tří částí:
  1. Programování RESTové služby s určitou business logikou.
  2. Doménový design jednoduché/zjednodušené business domény.
  3. Návrh solution pro zpracování nekonéčného streamu.

Na vypracování zadání jsem měl zhruba týden (minimálně 1. část), až dva. Řešení jsem komitoval do soukromé repository na GitHubu.

Druhé kolo bylo on-site, kde jsem se po dvojicích sešel s implementačním týmem: senior + standard(?) vývojáři, senior sysadmin + standard(?) vývojář.

S první dvojicí jsme si povídali o programovacích jazycích a pak jsem na white-boardu:
  • Vysvětlil řešení, na "které jsem pyšný" (granularita webových služeb v SOA řešení).
  • Navrhnul monitorování distribuované platformy.
  • Implementoval v Javě reverse Stringu, bez použití StringBuilder.reverse()

S druhou dvojicí jsem odpovídal na "linuxové" otázky a pak jsme si hlavně povídali, jak vypadá práce u nich.

Reflexe

Programovací zadání bylo celkem zajímavý a docela jsem si ho užil. Protože bylo velmi volné (to je rozdíl oproti vágní), tak jsem se rozšoupnul a půlku jsem naimplementoval ve Scale a půlku v Javě (že by potenciální článek?). Designové řešení doménového modelu bylo přímočaré, nic zvláštního.

Poslední část, streamové řešení, je pro mne exotické. Strávil jsem cca týden pročítáním internetu, abych se zorientoval a pak od stolu navrhl řešení v Clojure a jako zálohu Spark Streaming, s poznámkou nutného ověření (o Sparku nic nevím).

On-site práci na white-boardu hodnotím částečně pozitivně (popis mého řešení a monitorování), částečně negativně (programování a re-implementace core funkce). Programovat se má na počítači.

Jelikož většina pohovorujících měla z nějakého důvodu alespoň částečně načtený můj blog, cítil jsem během on-site pohovorů trochu přehnaný respekt, jenž nebyl adekvátní.

Zpětná vazba

První, krátkou zpětnou vazbu jsem dostal emailem po komitu prvních dvou částí zadání. Zbývající, opět krátkou, na začátku on-site interview.

Týden po on-site pohovoru jsem dostal další telefonický feedback. Řekl bych, že strukturovaný a vyvážený. Minimálně přesně pojmenoval mé slabší stránky.

Mindset

Growth ✔

Jak to zlepšit?

Mé hledání nové práce je momentálně u konce a doufám, že to minimálně dalších 5 let nebudu muset řešit. Shodou okolností a preferencí, se v blízké budoucnosti nebudu technickým hiringem zabývat. Jelikož ale pohory byly historicky vždy silným tématem tohoto blogu, měl bych aspoň doporučení (či zbožné přání):

Patero technického recruitera

1. Udělejte technické kolo co nejvíce praktické.

Nechte kandidáta vypracovat zadání. Udělejte s ním on-site workshop (jde to i přes Skype). Mějte zadání dostatečně volné, abyste kandidáta zbytečně netlačili do své škatulky. Nenuťte kandidáta programovat na white-board a už vůbec ne na papír! Neprogramujete děrné štítky.

2. Nechte si ukázat a vysvětlit kandidátův kód.

Uvidíte reálný kód, který vzniknul v určitém kontextu. Zadání, či workshop (předchozí bod) je pořád v laboratorních podmínkách, které nemusí každému sednout.

3. Testujte kandidáta na praktické věci, které reálně děláte.

Vykašlete se na re-implementaci algoritmů a core funkcí jazyka - nic podstatného pro váš business tím o kandidátovi nezjistíte. Naopak tím odfiltrujete slušné procento lidí, kteří excelují v něčem jiném. A zapomeňte na idiotské úlohy typu "kolik golfových míčků se vejde do letadla".

4. Nezkoumejte současný snapshot, hledejte projekci do budoucna.

Pokud něco neroste, je to pravděpodobně mrtvé. Současné kvality kandidáta jsou jen startovní bod. Snažte se najít jeho budoucí trajektorii.

5. Hledejte lidi s historií a schopností učit se.

Cílem nemusí být najít dokonalý technologický "match". Ale najít někoho flexibilního, kdo se potřebné věci rychle naučí, či do dané role doroste.
"You don’t hire for skills, you hire for attitude. You can always teach skills." ~ Simon Sinek

Související články


Související externí články