Pisząc relację z Confitury’12 postanowiłem, że nie będę oceniał ostatniej prezentacji Wojtka Seligi. To był keynote rządzi się on swoimi prawami. Jednak dziś Wojtek zamieścił slajdy z prezentacji i swój komentarz do tejże. Jako, że zostałem dyskretnie wywołany do tablicy (wywołanie sponsorują liczby 20 i 18) to postanowiłem jednak odnieść się do prezentacji oraz komentarza.

Prezentację można podzielić na trzy części. Dwie pierwsze poświęcone rekrutowi trzecia „sierżantowi” z punktu rekrutacyjnego.

Część pierwsza poświęcona została umiejętnościom „miękkim”, a w zasadzie tylko jednej – znajomości języka angielskiego. Był co prawda całkiem śmieszny przykład wymiany maili, ale to raczej ciekawostka niż coś konkretnego. Rację miał Wojtek, że angielski w IT to podstawa. Nie zgodzę się jednak, że musi być on na poziomie biegłej znajomości. Język trzeba znać na poziomie pozwalającym na szybką komunikację. Ciekawostką przyrodniczą jest to, że na slajdzie pokazała się flaga Indii, gdzie wbrew pozorom znajomość angielskiego nie jest dobra w rozumieniu standardów polskiej edukacji. Przeciętny pracownik call center w BangaloreW potrafi się komunikować po angielsku, ale uwaliłby sprawdzian z tego języka na poziomie dawnego liceum. Braki nadrabiają jednak ilością (+1,2mld ludności) i dzięki temu nie jest to aż tak dostrzegalne, bo tam gdzie trzeba trafiają ludzie z odpowiednią znajomością języka. I nie ma tu nic dziwnego, bo Indie to kraj w którym jest używane ponad 1600 dialektów pogrupowanych w ponad 120 „języków”, a samych języków oficjalnych jest 23 (ogólnokrajowe hindi i angielski + 21 lokalnych w poszczególnych stanach). O co jednak mi chodzi? Język używany do komunikacji nie musi być perfekt musi być jednak zrozumiały dla ludzi, z którymi rozmawiasz. Inaczej nie będzie spełniał podstawowej funkcji – komunikacji. Zaletą języka ludzkiego, naturalnego w porównaniu z językami programowania jest to, że „kompilator” rozmówcy jest wstanie ogarnąć i wybaczyć naprawdę grube błędy.
//OT
Tak swoją drogą to czasami na BBC można obejrzeć programy gdzie są wywiady z Jamajczykami. Rasta mówią po angielsku, a BBC i tak musi ich tłumaczyć co mówią… na angielski.
//EOOT
W tej części przyczepię się jeszcze trochę o brak omówienia innych cech kandydata takich jak cierpliwość, dokładność, odporność na stres czy poczucie humoru. One też są ważne, bo Programming ist Krieg więc ciężko może być z człowiekiem, który w razie poważnej awarii załamie się psychicznie (widziałem na własne oczy, straszna sprawa i piekielnie kosztowna dla firmy).

Druga część była już poświęcona umiejętnościom technicznym kandydata. Pierwszy fragment poświęcony certyfikatom… powiem tak, wartość dawnego SCJP spada i to nie ze względu na jakieś drastyczne obniżenie wymagań czy trudności testów. Po prostu API języka od czasu Javy 1.3 rozrosło się na tyle, że ten certyfikat nie weryfikuje już przekrojowej znajomości języka i API. Jest tego za dużo i jeden egzamin tego nie ogarnia. Ponad to przez ostatnie kilka(naście) lat bardzo mocno zmieniła się filozofia tworzenia oprogramowania w Javie i podstawą jest raczej znajomość narzędzi i umiejętność ich odpowiedniego łączenia.
Temat bibliotek został poruszony później w prezentacji i ciężko się nie zgodzić z tezą, że biblioteki trzeba znać, ale… jeżeli posiedzi się trochę na forach javowych w okresie przed sesyjnym można zaobserwować pewną ciekawą sytuację. Pada pytanie dotyczące programu w stylu „stacja paliw” czy „kolejki w markecie” i od razu pojawia się zastrzeżenie „ale można użyć tylko metod z klasy Thread”. Co to znaczy? Ano, taki student jest zmuszany do napisania programu, który pomoże mu zrozumieć zasady pracy na wątkach (to zacne i ważne) jednocześnie jednak odcinany jest od informacji o elementach API języka, które później powinien używać. Nawet jeżeli wpadnie na ten genialny pomysł i zajrzy gdzie trzeba to zazwyczaj trafia to na półkę „obczaić później” (softlinkowaną na /dev/null). Podobnie rzecz ma się z bibliotekami. Przykład z życia – napisać proste „ESB”, czyli cztery procesy JVM komunikują się na cztery różne sposoby (WS-XML, RMI, CORBA, sokety). Temat bajka, bo można w praktyce 90% kodu „napisać” za pomocą archetypów mavena i później dodać ze dwie biblioteki, ale nie… nie wolno wszystko należy z palucha i w dodatku poszczególne instancje muszą uruchamiać całkowicie niezależne jary nie współdzielące klas poza minimum z API. No i najważniejsze choć komunikat jest taki sam to nie wolno opędzić tego jednym obiektem. Czyli piszemy 4x to samo… I przykładów można mnożyć, a wniosek jest taki. Jeżeli nawet piszesz pracę magisterską w javie nie oznacza to, że będzie ci dane poznać mechanizmy tego języka. Dlaczego? Ponieważ, i to jest cholernie przykre, 90% kadry to ludzie, którzy na zajęcia przychodzą jako „B-players” i to niezależnie od tego czym zajmują się na co dzień (sam kiedyś wyleciałem z laborki za stwierdzenie, że pisanie własnego lacha zliczającego w javie to poroniony pomysł skoro jest w standardowym API i jak chcemy pisać to niech to będzie coś co ma jakąś wartość ponad standard API).
Co zaś tyczy się javowego abecadła to też tutaj trochę Wojtek popłynął. Po pierwsze nie zaznaczył najważniejszej rzeczy, że wymagania które prezentuje dotyczą jego specyficznej firmy. Naprawdę inaczej ustawia się wymagania dla producenta cmsów, a inaczej dla firmy robiącej rozbudowane systemy zarządzania softem. I tu właśnie odniosłem wrażenie, że te 20 i 18 zaczynają królować w prezentacji. Oczywiście są ludzie i takich znam, którzy mając lat niecałe 20 i 2-3 lata doświadczenia w programowaniu ogarniali to jak działa JVM na poziomie znacznie przewyższającym wszystko z czym się wcześniej spotykałem, ale to są wyjątki. Później było jeszcze chwilkę o książkach (dodałbym jeszcze do tego efektywne narzędzia, bo to dobry przegląd toolkitu dla programisty). Czego mi zabrakło? Ano ważnego zdania, że każdej z tych rzeczy można się douczyć i „awsome” nie koniecznie i nie zawsze musi oznaczać 100% znajomości wszystkiego.

Krotko podsumowują. Kiedyś trafiłem na świetny artykuł na fnord i pozwolę sobie zacytować coś co jest dla mnie podstawą do takiego, a nie innego podejścia do prezentacji Wojtka:

Sam popełniłem kiedyś ten błąd podczas rekrutacji do zespołu, szukałem kandydata z wiedzą merytoryczną (Linux, sieci) i doświadczeniem podobnym do mojego. Tylko komuś takiemu jak ja mogłem spokojnie oddać połowę pracy i odpowiedzialności w projekcie. Oczywiście skończyło się to porażką, i też byłem załamany poziomem aplikantów i opowiadałem na ten temat czerstwe historyjki. Ale gdyby moja druga pracowa połówka istniała — też wówczas szukałąby ludzi do swojego projektu, zamiast aplikować do cudzego.

Trzecia część prezentacji była poświęcona „sierżantowi”, który ma kilka chwil na wyłuskanie kandydatów do kompanii szturmowej i tych do garkuchni. Tu powiem szczerze, że prezentacja weszła na mało znany mi grunt „psychologii HR” i traktuję ją jako ciekawą lekcję na przyszłość.