Każda zmiana pracy pomogła mi w rozwoju. Historia Jędrzeja Szczepaniaka

Czy częsta zmiana pracy wspiera nas w rozwoju? Zdecydowanie, czego przykładem jest historia Jędrzeja, który szukając nowego miejsca pracy za każdym razem chciał osiągnąć konkretny cel. Poznajcie historię Jędrzeja Szczepaniaka, Software Engineera w Tadaweb (Luksemburg), który doświadczenia zdobywał w pracy w STX Next, Egnyte czy w OLX.

Co przyciągnęło Cię do programowania?

Pierwszy raz zobaczyłem program komputerowy w gimnazjum. Tata mojego kolegi miał pracę związaną w jakiś sposób z komputerami i wtedy pierwszy raz zobaczyłem hello world w C++. Później było liceum o profilu matematyczno-fizycznym w VIII LO w Poznaniu z bardzo dobrymi zajęciami z informatyki. Moja klasa była silna i byłem raczej jednym ze słabszych ogniw. Nabrałem wtedy przeświadczenia, że programowanie nie jest dla mnie.

Po roku przerwy, po liceum trafiłem na Elektronikę i Telekomunikację na Politechnice Poznańskiej, gdzie zainteresowałem się sieciami komputerowymi. Wydaje mi się, że dosyć dużo o nich wiedziałem. Zdawałem certyfikaty Cisco i Junipera, próbowałem ćwiczyć umiejętności w wirtualnym domowym laboratorium. Kiedy jednak szukałem praktyk letnich, zorientowałem się, że niespecjalnie szuka się ludzi z umiejętnościami sieciowymi i są opłacani znacznie gorzej niż programiści. Zdrowy rozsądek podpowiedział mi, że może jednak lepiej jest robić coś, na co jest duże zapotrzebowanie.

Później okazało się, że znacznie łatwiej jest majstrować z programowaniem niż z sieciami. Często, żeby zasymulować jakąś skomplikowaną topologię sieciową, potrzebny był dedykowany sprzęt albo duża moc obliczeniowa, podczas gdy do zabawy z programowaniem wystarczył kiepskiej klasy laptop.

Od jakich materiałów zaczynałeś? Starzy wyjadacze opowiadają o Bajtku i książkach, a Ty?

To była chyba Symfonia C++ Jerzego Grębosza.

Pamiętasz swoje pierwsze wyobrażenie o branży IT? O pracy programisty?

Na początku byłem przekonany, że nie nie jestem wystarczająco dobry w przedmiotach ścisłych, żeby zajmować się programowaniem. Podobne przekonanie miałem chyba na temat całej branży, że trzeba umieć wyrecytować algorytm Aho-Corasick o każdej porze dnia i nocy, i że trzeba potrafić zaimplementować kopiec z zamkniętymi oczami.

Jak znalazłeś pierwszą pracę i czego to doświadczenie nauczyło Cię?

Pierwszą pracę (gdzie płacono mi za programowanie) znalazłem przypadkowo. Kolega ze studiów szukał programistów do swojej firmy. Myślę, że nauczyłem się, że programistom nie płaci się za pisanie kodu, tylko za rozwiązywanie problemów. Kod tylko pomaga biznesowi. Jeżeli problem da się rozwiązać bez kodowania – tym lepiej.

Często zmieniałeś pracę – choć nie wiem, czy “często” nie jest tu nadużyciem. Co zazwyczaj było powodem zmiany pracy?

Myślę, że „często” perfekcyjnie oddaje moją częstotliwość zmiany miejsca pracy. Każda zmiana była dla mnie w jakimś sensie krokiem do przodu. Do STX Next przeniosłem się dlatego, że było tam dużo świetnych specjalistów, od których dużo się finalnie nauczyłem. Do Egnyte przeszedłem dlatego, że chciałem spróbować pracy w firmie produktowej. Do OLX przeniosłem się, żeby pracować z chmurą i z serverless. Nie oznacza to oczywiście, że uważam, że jeżeli weźmie się moje CV, to można posegregować firmy od najlepszej do najgorszej. W kontekście mojego rozwoju – za każdym razem uważałem, że wybranie danego zespołu w danej firmie popchnie moją karierę do przodu.

Wielu inżynierów, z którymi rozmawiałem, uważa, że częsta zmiana pracy to jedyny sposób na podnoszenie umiejętności. Jesteś podobnego zdania?

Jestem głęboko przekonany, że nie ma jednej metody osiągnięcia czegokolwiek. Natomiast trudno jest mi odpowiedzieć na to pytanie, dlatego, że nie pracowałem w żadnej firmie wystarczająco długo, żeby doświadczyć samorozwoju w jednym miejscu. Nie mam porównania.

Wierzę, że częsta zmiana, powoduje, że umiejętności podnosi się szybciej. Po prostu ilość różnych środowisk, z którymi ma się do czynienia jest większa i ma się okazję poznać więcej sposobów pracy. Pracuję jako programista dopiero od pięciu lat. W tym krótkim czasie z perspektywy całej kariery miałem do czynienia z aplikacjami wdrażanymi na bare-metal serwerach, w kontenerach, jako funkcje serverless, za firewallem klienta. Pracowałem w kompletnie różnych od siebie zespołach. Rozwiązywałem zupełnie różne od siebie problemy biznesowe. Myślę, że te doświadczenia poszerzyły moje horyzonty.

Pewnie da się pracować w jednej firmie, a tych wszystkich dodatkowych rzeczy uczyć się po godzinach, ale nauka płynąca z zabawy z narzędziem zupełnie różni się od użycia tego narzędzia na produkcji.

Częste zmiany miejsc pracy to również częste rekrutacje, a to oznacza przygotowania. Dla mnie każdorazowo to wytężony okres, gdy przygotowuję się na rozmowy rekrutacyjne. To też w jakimś stopniu rozwija.

Jednak to tylko mój punkt widzenia. Podejrzewam, że są tacy programiści, którzy rozwijają się w imponującym tempie, pracując w jednej firmie. Być może zależy to od rodzaju i rozmiaru firmy.

Warto też wspomnieć, że często zmieniając organizacje, nie mam okazji w długim terminie utrzymywać swojego kodu. Wydaje mi się, że to cenne doświadczenie, którego ja nie miałem okazji jeszcze zaznać, czyli poznać się na tym czy metody, które stosuję są skuteczne długofalowo. Utrzymuję jednak kod napisany przez innych programistów, więc być może wychodzi na to samo.

Oferty pracy z

O czym Twoim zdaniem mówi się za mało w kontekście nauki programowania, jak i samej pracy?

Z całą pewnością o wartości testów jednostkowych. Pracowałem tylko w jednym zespole, gdzie brano ten temat w 100% na poważnie. W innych miejscach było naprawdę rozmaicie. Zupełnie nie potrafię zrozumieć, dlaczego tak się dzieje. Dlaczego wciąż wrzucamy na code review nieotestowany kod? Zgadzam się z Uncle Bobem, który twierdzi, że nieodpowiedzialne jest uruchamianie na produkcji kodu, dla którego nie mamy testów. Ale nie idzie tylko o zasady. Przecież testy jednostkowe to narzędzie dla programistów. Dzięki nim można znacznie spokojniej przeprowadzać refactoring, dzięki nim nie trzeba uruchamiać całej aplikacji tylko po to, żeby sprawdzić, jak zachowuje się tylko jeden z modułów.

Uważam, że taki stan rzeczy wynika z nieumiejętności pisania i testów, i przede wszystkim testowalnego kodu, dlatego powinno się o tym mówić znacznie więcej.

Wydaje mi się również, że mało się mówi o tym, w jaki sposób budować swoje moduły/klasy/paczki. Brzmi bardzo trywialnie, ale często widzę kod niepotrzebnie skomplikowany. Z jednej strony zdarzają się przekombinowane hierarchie klas czy interfejsów, a z drugiej fragmenty kodu, który zajmuje się zbyt wieloma aspektami. Dużo w tym kontekście mówi się o zasadach SOLID. Proponuję jednak do tego tematu podejść od innej strony.

Polecam ponadczasową książkę Johna Ousterhouta „A Philosophy of Software Design”, która w przystępny sposób tłumaczy te zagadnienia. Dla mnie była przełomowa. Warto zwrócić uwagę na jej tytuł – „a philosophy”, a nie „the philosophy”. Autor proponuje punkt widzenia, bez narzucania swojego zdania. Gorąco polecam zapoznać się z nim i zapewniam, że znacznie prościej będzie też otestować swój kod.

Na koniec jeszcze jedna rzecz – zauważyłem, że programiści uczą się jakiś zasad i kurczowo się ich trzymają nie biorąc pod uwagę, że ważny jest kontekst. Jednoliterowa zmienna być może nie jest fantastycznym pomysłem w większej funkcji, ale jeśli jej zakres jest mały, to może być okej. Pisanie komentarzy bywa zbędne, jeśli komentarz nie wzbogaca w żaden sposób wiedzy o danym fragmencie kodu, ale jeśli robimy coś nieoczywistego – co rozwiązuje błąd z produkcji – być może warto zostawić parę słów wyjaśnienia (i oczywiście test udowadniający pozbycie się błędu). Powtarzanie tego samego kodu bywa złe, ale nie zawsze warto taki kod uwspólniać. Różne reguły działają w różnych kontekstach.

Powiedziałeś, że pracowałeś tylko w jednym zespole, który brał testy jednostkowe na poważnie. Jak myślisz, z czego to wynikało, że akurat ta firma brała je “na poważnie”?

Po prostu trafiłem na wyśmienitych specjalistów w zespole. To chyba nawet nie jest tak, że jakaś firma bierze testowanie na poważnie albo nie. Dużo moim zdaniem rozgrywa się na poziomie zespołu. Myślę, że w każdej firmie zdarzają się wyśmienite zespoły, a ja miałem szczęście właśnie w takim zespole pracować.

Wydaje mi się, że w zespole w ogóle można wprowadzać dużo ciekawych usprawnień. Sprawdzać jak działają rozwiązania i propagować je w całej firmie jeśli działają. Dlatego też na etapie rozmów rekrutacyjnych warto dowiedzieć się o zespole, do którego ma się dołączyć. Nie zawsze jest to możliwe – ale jeśli się da, to warto dowiedzieć się, z kim będziesz pracować na co dzień.

Mieszkasz i pracujesz w Luksemburgu. Opowiedz o kontekście wyjazdu.

Bardzo chciałem żyć za granicą, chciałem przekonać się, jak to jest. Udało się zrealizować ten pomysł dzięki mojej żonie, która dostała ofertę pracy w Amazonie w Luksemburgu. Nigdy wcześniej nie myśleliśmy o tym kraju ani jako o miejscu do zamieszkania, ani nawet do odwiedzenia.

Sprawdziliśmy, że TGV z Luksemburga do Paryża jedzie nieco ponad dwie godziny, że w Alpy z Luksemburga mamy bliżej niż z Poznania w Tatry, że z Frankfurtu będziemy mogli polecieć w dowolne miejsce na świecie. Po tym jak moja żona podpisała umowę, sam też znalazłem pracę w firmie, która pracuje w stosie technologicznym, w którym nieźle się czuję. Wsiedliśmy w samochód i pojechaliśmy.

Dopiero po przyjeździe na miejsce okazało się, że oprócz tego, że jesteśmy w centrum Europy i wszędzie mamy blisko, to sam kraj jest wspaniały, mimo tego, że jest niewiele większy niż Kotlina Kłodzka. Panują tu świetne warunki do uprawiania kolarstwa i wycieczek pieszych. Najwyższy punkt Luksemburga to mniej niż 600 m n.p.m., ale teren ukształtowany jest w ten sposób, że z łatwością można zrobić kilkugodzinną wyprawę z przewyższeniami około 1000 m. Jeżeli kogoś interesuje taka forma spędzania wolnego czasu – Luksemburg nadaje się idealnie. Być może warto nadmienić, że administracja Luksemburga nastawiona jest przychylnie przyjezdnym specjalistom. Bardzo dużo spraw w urzędzie można załatwić po angielsku (chociaż najlepiej znać po prostu francuski).

Jak wyglądają koszty życia? Potrafiłbyś je ogólnie porównać do pracy i życia w Polsce?

Portal numbeo.com daje dobry obraz tego jak wyglądają koszty życia w Luksemburgu. Jedzenie jest tutaj dwa razy droższe, wynajem mieszkania cztery razy droższy. Trudno porównywać stronę przychodową, bo to bardzo zależy od tego, ile zarabiało się przed wyjazdem. Łatwo można jednak sprawdzić on-line, ile zarabiają programiści w Luksemburgu.

Ciekawie przedstawia się także sytuacja z mieszkaniami i transportem publicznym. Od ponad roku transport publiczny jest w całym kraju bezpłatny. Opłacany jest oczywiście z podatków, natomiast faktycznie, wchodząc do pociągu czy autobusu nie trzeba przejmować się biletem. Rząd w ten sposób, próbuje zachęcić do korzystania z komunikacji publicznej i zmniejszyć ilość samochodów na drogach. Problem jest poważny dlatego, że do Luksemburga codziennie przyjeżdżają tłumy z Belgii, Francji i Niemiec (portal rządowy mówi o niecałych 200 000 pracowników transgranicznych). Wiele ludzi wybiera taki dojazd dlatego, że w krajach ościennych da się wynająć czy kupić mieszkanie przynajmniej dwukrotnie taniej.

Mamy więc ludzi, którzy decydują się na życie w Luksemburgu i płacą więcej za mieszkanie, ale nie muszą dojeżdżać, i tych którzy wolą mieszkać poza granicami i płacą za mieszkanie znacznie mniej, ale muszą liczyć się z czasem spędzonym w korkach.

Jaki masz plan na siebie? Czym chciałbyś się zajmować w ciągu najbliższych lat i czy warto takie rzeczy planować?

Chciałbym kontynuować naukę technik chmurowych. Myślę, że w tych czasach oprócz wiodącego języka programowania warto znać też dobrze, przynajmniej jednego dostawcę usług chmurowych. Znam trochę AWS i chciałbym rozszerzyć tę wiedzę. Niedawno zacząłem uczyć się Clojure. Chciałbym też poznać Rusta. Nie myślę o ścieżce menedżerskiej, chciałbym być specjalistą.

Mój plan na siebie to poznawanie świata na różne sposoby. Kiedy cztery lata temu zaczynałem uczyć się języka francuskiego nie spodziewałem się, że będę go w przyszłości używał na co dzień w Luksemburgu. Chcę kontynuować naukę rzeczy które mnie interesują, nawet jeśli wydają się one aktualnie nieprzydatne.

W długim terminie myślę o otwarciu restauracji z moją żoną.

---

Jędrzej Szczepaniak. Software Engineer w Tadaweb. W zawodzie od około 5 lat. W ciągu tego czasu pracował w PHP, Pythonie i Go. Orędownik czystego, testowalnego i otestowanego kodu. Nie lubi stać w miejscu. Po pracy wynajduje tematy warte zgłębienia i poświęca czas swoim projektom. Doświadczony w pracy w firmach produktowych i w firmach typu software house. Domorosły pianista, kolarz amator, miłośnik gotowania, wieczny początkujący.