Wczoraj dostałem od rekruterki telefon, że firma, do której się rekrutowałem, nie jest zainteresowana współpracą ze mną, z powodów, których nie potrafię zrozumieć. Ten wpis jest moją próbą opisania rzeczywistości zawodowej, w której się znajduję, w poszukiwaniu tego zrozumienia. Bo na ten moment to nie ma sensu.

Praca jako pretekst do nauki

Zacznijmy w losowym miejscu. Pewna firma, nazwijmy ją A, postanowiła podziękować mi za współpracę, a to uruchomiło z mojej strony chęć znalezienia nowej. W firmie A pracowałem od kilku lat, przez większość czasu tworząc i rozwijając projekty na iOSa, co jest moją główną kompetencją. Projekty były przeróżne: aplikacja sportowe integrujące się z zegarkiem i mierzące różne dane, aplikacje do śledzenia nawyków i planowania, aplikacje do czytania artykułów i odtwarzania podkastów, nawet aplikacje medyczne. Około rok temu, firmie "skończyły się" projekty iOSowe, i dostałem wtedy propozycję, żebym spróbował swoich możliwości w innych technologiach, których firma aktualnie potrzebuje, czyli Node.js oraz React. Nie będę ukrywał, że na tamten czas byłem mocno uprzedzony do JavaScriptu, ale jeszcze bardziej byłem uprzedzony do niezarabiania pieniędzy, więc wybór był oczywisty. Naturalnie wjechały też różne racjonalizacje pod tytułem "poszerzanie horyzontów, powiększanie kompetencji". Summa summarum nie była to najgorsza rzecz w moim życiu zawodowym. Po roku pracy z JSem nabrałem wystarczająco doświadczenia, żeby być mniej uprzedzonym do samej technologii, a bardziej do sposobu, w jaki jest wykorzystywana - prawdopodobnie 99% stron w internecie korzystających z Reacta, mogłoby być statycznymi stronami - dokładnie tak jak moja. Ale to osobny temat. Minął rok, firmie "skończyły się" (hehe) projekty dla mnie, no i już nie było mnie gdzie migrować, więc się pożegnaliśmy, miło i sympatycznie mimo wszystko.

Zanim trafiłem do firmy A, pracowałem dla firmy B. W firmie B jednym z podstawowych elementów systemu, który rozwijaliśmy, była komunikacja po Bluetooth. Nigdy wcześniej nie pracowałem z Bluetoothem, ale to nie było problemem, bo jak praktycznie każdy programista, czas nauczenia się nowej technologii skraca się wykładniczo wraz ze wzrostem ogólnego doświadczenia. Przygód z Bluetoothem było co niemiara, szczególnie fascynujące było testowanie integracji tych urządzeń z aplikacjami mobilnymi, co doprowadziło do powstania nowych, fascynujących narzędzi. W międzyczasie na tapet wjechał pomysł stworzenia aplikacji we Flutterze - kolejnej technologii - którą również po skończonym czasie opanowałem w stopniu wystarczającym.

Pomiędzy firmą A i B, pracowałem w firmie C. Produktem firmy C znowu było coś kompletnie odmiennego od A i B, ale główną różnicą było to, że pewna część aplikacji była realizowana nie natywnie, a w WebView. Na tę decyzję architektoniczną też byłem wtedy bardziej obrażony niż jestem teraz, ale nie zmienia to faktu, że takie było wymaganie, więc nauczyłem się tego, co było mi potrzebne, i robiłem to, co było konieczne, dzięki czemu rezultat był taki, jaki był oczekiwany. Ta wiedza przydała mi się później w kolejnej firmie, D - znowu, kompletnie inna branża - gdzie mogłem te doświadczenia zaadaptować i ulepszyć. Na ten moment produkt firmy D ma się świetnie i jestem z niego bardzo zadowolony.

Produkt i technologia

W każdej z tych prac największą satysfakcję dawała mi możliwość używania nowych, lepszych technologii. Nowe narzędzia, nowe biblioteki, szybszy, bardziej zoptymalizowany kod, mniej kodu, prostszy kod, mniej narzędzi, brak narzędzi. Nad samym produktem w żadnej firmie, w której pracowałem, nigdy nie czułem, że mam jakąkolwiek kontrolę, bo zawsze był nade mną jakiś właściciel produktu, który te wszystkie moje (i nie tylko mojej) pomysły najczęściej bagatelizował, a w lepszy dzień - torpedował. Ale technologia to moja kompetencja, i tutaj mogłem się wykazać, i często się wykazywałem, będąc nierzadko siłą napędową różnych małych rewolucji, z których moimi ulubionymi są migracje projektów do Swift Package Manger, przejście na SwiftUI, czy tworzenie aplikacji w nowej architekturze The Composable Architecture. To są duże rzeczy, które mają wpływ na wiele aspektów danego projektu.

Ten podział na skupienie na produkcie i technologii odkryłem pierwszy raz we wpisie na blogu Michelle Lim i bardzo mocno zarezonował we mnie, bo nagle byłem w stanie precyzyjnie określić to, co w każdej pracy tak naprawdę mnie "jara". W każdej firmie, w której pracowałem, każdy projekt dotyczył zupełnie innego tematu, często nawet kilku, gdy pracowałem w tak zwanym "software house". I to nie jest tak, że mogę sobie w pewnym momencie powiedzieć, że chcę, żebyśmy zmienili aplikację bankową na aplikację do komunikacji publicznej. Ale żebyśmy zmienili system zależności - już jak najbardziej. Poczucie satysfakcji wynika z poczucia kontroli.

Umiejętności jako pretekst do zabawy

W międzyczasie tych wszystkich wojaży zawodowych, zainspirowany doświadczeniami około-webowymi, zacząłem interesować się nowymi tematami.

Na pierwszy ogień wjechał ten oto blog - czy już raczej pełnoprawny internetowy portal osobisty. Najpierw sam próbowałem pisać silnik w PHP, który dynamicznie czyta pliki Markdown i formatuje je do HTMLa, później zacząłem korzystać z bibliotek do parsowania, stylowania , kolorowania składni kodu, a na dzień dzisiejszy korzystam z Zoli jako frameworka. Do koszyka umiejętności wjechały technologie takie jak HTML, PHP, SQLite, CSS, SCSS, a nawet szablony Tera.

Druga fascynacja to self-hosting. Albo self-serving? Z jednej strony kupiłem sobie kilka domen, standardowy hosting, jakiegoś małego VPSa, i mały serwer domowy. Zacząłem eksperymentować z Proxmoxem, OPNsense, Dockerem, Minifluxem, HomeAssistantem. Na pewnym etapie stwierdziłem, że fajnie byłoby móc taki serwer postawić jedną komendą, i tak zanurzyłem się w świat DevOps i Terraforma. W głowie mam milion pomysłów dotyczących tego, co chcę jeszcze zrobić. Chciałbym mieć swój własny serwer haseł i sekretów, np. VaultWarden, własny serwer ze zdjęciami, np. Immich albo Ente. Ostatnio zaczęło mi przeszkadzać to, że w OPNsense nie da się łatwo postawić konfiguracji od razu podczas instalacji, i dokopałem się do czegoś, co nazywa się "VyOS" i na YouTube jest więcej wygenerowanych śmieci na jego temat niż rzetelnych materiałów.

Zaznajomienie się z PHP sprawiło, że napisałem sobie kilka bardzo prymitywnych, ale działających RSS-scraperów, np. do strony https://dlapilota.pl/, która w tamtym czasie nie miała żadnego kanału RSS, a teraz ma jakiś kulawy - więc, znowu, kolejny pomysł na aplikację, tym razem porządny scraper RSS, napisany w Swifcie, odpalony na VPSie. Jak tyko znajdę czas.

No i oczywiście mój koronny projekt: Mapa Apostazji.

Bądź doskonały

No więc gdy firma A i ja pożegnaliśmy się, zacząłem rozglądać się za pracą w innej firmie. O dziwo, bardzo niedługo po tym, po długiej suszy na LinkedInie, odezwała się do mnie rekruterka, szukająca pracownika do firmy X. Podczas pierwszej rozmowy powiedziała mi, że proces rekrutacji będzie miał trzy etapy: "programowanie", "projektowanie systemów" oraz "dopasowanie kulturowe" (to moje frywolne tłumaczenia).

Test z programowania był zabawny. Dostałem jakąś super prostą aplikację, z jakimiś super trywialnymi błędami, super. Problem polegał jedynie na tym, że użyta w nich architektura oraz biblioteki również w pewnym sensie były "super stare". Tzn. sama aplikacja była napisana w architekturze MVVM, którą ja ostatni raz na oczy widziałem z pięć lat temu. Zarządzanie sygnałami w aplikacji było zrealizowane przy pomocy Combine, które ostatnio raz na oczy widziałem pewnie z 7 lat temu. I ja naprawdę nie rozumiem, co ten test miał sprawdzić. Oczywiście rozumiałem problem leżący u podstawy, więc większość testu spędziłem nad szukaniem odpowiednich funkcji. Ale to nie ma znaczenia, bo finalnie ten etap przeszedłem bardzo dobrze.

Kolejnym etapem było projektowanie systemu. Nigdy wcześniej nie słyszałem o czymś takim, więc trochę to zbagatelizowałem - co było taktycznym błędem, biorąc pod uwagę, że rekruterka w materiałach do stanowiska podesłała mi tytuły dwóch KSIĄŻEK na temat "Mobile System Design". Czajcie to? Żebym przeszedł jeden z etapów rekrutacji, muszę przeczytać dwie KSIĄŻKI. I już widzę te protesty, że w tych książkach jest wiedza niezbędna do bycia kompetentnym programistą - i pozwolę sobie nie zgodzić się. Z moich dotychczasowych doświadczeń wynika, że wiedza w tym etapie rekrutacji jest oceniana w 20%, a to co jest najważniejsze, to forma, albo raczej formuła. To dosłownie kojarzy mi się z egzaminem maturalnym, gdzie albo wstrzelisz się w klucz, albo odpadasz. Masz do zrobienia bardzo konkretne rzeczy, w bardzo określonej kolejności, nie możesz o niczym zapomnieć, musisz to wszystko zaplanować w czasie, narysować na diagramie, ogarnąć przypadki brzegowe. Musisz zadawać odpowiednie pytania, podejmować decyzje. Dosłownie musisz się nauczyć, jak przejść ten etap, bo żadna ilość wiedzy, umiejętności i kompetencji nie pomoże, jeśli nie będzie odpowiedniego "formatu". Aha, no i oczywiście to nie ma nic wspólnego z prawdziwą pracą, bo ten projekt, który musisz podczas rekrutacji odwalić w mniej niż godzinę, w prawdziwym świecie projektujesz tygodniami, jeśli nie miesiącami. No i w prawdziwym życiu możesz się pomylić, a następnie poprawić błąd. Na rozmowie masz być doskonały. Innymi słowy, musisz odwalić balet, żeby potem móc być statystą w superprodukcji.

Ostatni etap w firmie X to było dopasowanie kulturowe. Tutaj też dostałem instrukcję od rekruterki, że firma ma wartości, że będzie pytać o przykłady z mojej kariery, które pokrywają się z wartościami. Straszny bełkot dla mnie, ale tutaj się postarałem, zrobiłem sobie tabelkę, wypisałem wszystko co chciałem powiedzieć. Gdy doszło do rozmowy, po drugiej stronie ekranu siedział rozleniwiony typ, który sennym głosem czytał pytania z kartki, i to w taki sposób, że gdy odpowiedziałem już na jakieś pytanie w poprzedniej odpowiedzi, to i tak to pytanie padało wraz z sakramentalnym "wiem, że już na to pytanie odpowiedziałeś, ale [powrót do leniwego głosu] opowiedz jakim rodzajem pizzy jesteś i w jakiej sytuacji". Dam sobie zabrać komputer, że gość miał odpaloną transkrypcję, albo jakiś model, który mnie nagrywał, i potem napisał mu raport.

Ostatecznie firma podziękowała mi, bo nie jestem wystarczająco "liderski". Ja, pchający nowe technologie i rozwiązania do wszystkich projektów, przy których pracuję - zawodowych i prywatnych. OKEEJ.

Druga firma, Y, z którą wiązałem największe nadzieje, miała identyczne etapy - i tutaj przyznaję, każdy z tych, w których uczestniczyłem, był na poziomie. Test programistyczny to był prosty mechanizm do zaimplementowania, i było tam dużo więcej pytań o podstawy, które mają istotne znaczenie podczas pisania kodu. Do projektowania systemów przygotowałem się lepiej, obejrzałem kilka materiałów w internecie, przeczytałem kilka artykułów. I chyba starając się ponad miarę, sam sobie podłożyłem nogę, bo zamiast opisać architekturę, na której znam się doskonale (TCA), zacząłem opisywać tę, której używałem tak dawno, że już jej nie pamiętam (MVVM), bo była ona najczęściej używana w oglądanych przeze mnie materiałach, i stwierdziłem, że programista po drugiej stronie może nie znać tej mojej. Po szkodzie stwierdzam - a co mnie to obchodzi, że on nie wie? To miał być jego problem, a ja zrobiłem go moim. Tym kończą się intensywne próby baletowania ponad miarę.

"Nie to, czego szukamy"

W trzeciej firmie, Z, od której zaczyna się ten post, zabawa skończyła się bardzo szybko, bo po "dopasowaniu kulturowym", który był pierwszą rozmową. Sama rozmowa przebiegła moim zdaniem wybitnie. Miałem okazję powiedzieć o moich doświadczeniach, projektach w których pracowałem, dostałem kilka pytań o to, co mnie motywuje, z czego jestem najbardziej dumny w mojej karierze. Powiedziałem o wspomnianym wyżej artykule, o tym jak postrzegam moją pracę, i co mnie w niej najbardziej satysfakcjonuje. Było kilka pytań stricte programistycznych, w których mogłem zabłysnąć wiedzą i historiami o moich rewolucjach. Po rozmowie byłem święcie przekonany, że to była wręcz formalność, i że zaproszenie na kolejny etap dostanę bez żadnego problemu.

Jakież więc było moje zdziwienie, gdy okazało się, że "firma szuka kogoś bardziej zajawionego produktem", a ja jestem "za bardzo skupiony na technologii". To mnie złamało. Naprawdę nie kompiluje mi się w głowie to, że z mojego doświadczenia można wyciągnąć taki wniosek. I to nie jest tak, że uważam się za jakiegoś boga programowania, bo osobiście znam ludzi dużo młodszych ode mnie, którzy jednocześnie są dużo lepsi, zarówno pod względem znajomości technologii, jak i zrozumienia potrzeb klienta. Chwała im za to, życzę im jak najlepiej. Ale naprawdę chciałbym zrozumieć, czego w oczach tych wszystkich rekruterów mi brakuje, że pomimo trzynastu lat pracy, przeoraniu siebie przez kilkanaście projektów, języków programowania, technologii, platform, kilku firm o różnym stylu zarządzania, co najmniej kilku osobnych około-programistycznych hobby - nadal nie znajdują we mnie tego, czego szukają.

Tak naprawdę to doskonale wiem, czego mi brakuje. Nie umiem w balet.

Jeśli dotarliście do końca tego smutnego wpisu, to rzućcie okiem na podstronę z moimi projektami, z których na dzień pisania tego posta żaden nie jest stworzony w mojej "macierzystej" technologii, każdy opera się o zupełnie inny produkt i rozwiązuje zupełnie inny problem.