Między kodem, a tapasem. Wywiad z Marcinem Czerneckim

Leave this field empty if you’re human:

Dlaczego minęły? Mi nadal wydaje się to przerażające.

W Barcelonie życie miejskie trwa do późnych godzin nocnych, a wiele codziennych czynności można wykonywać późno w nocy. Dodatkowo, przerwa na lunch, trwająca obowiązkową godzinę, jest traktowana bardzo poważnie. Zgodnie z tradycją, powinno się ją spędzać z kolegami i koleżankami z pracy dla lepszej integracji. Obecnie, w modelu pracy hybrydowej, wspólne posiłki są możliwe tylko podczas pracy w biurze. Praca z domu pozwala mi na komfortowe zrobienie sobie siesty, czyli krótkiej drzemki. Popołudniowa siesta na leżaku, w upalne dni, na tarasie przy dźwiękach mew w oddali, szybko stała się czymś, co bardzo polubiłem.

Warto również wspomnieć o najgorętszych miesiącach, jakimi są lipiec i sierpień. W Hiszpanii w tym okresie wiele mniejszych firm zamyka się na wakacje. W branży IT często wprowadza się tzw. 'czas letni’. Na przykład w Sage, w tych miesiącach wszyscy pracują w systemie 8-15, co daje 35 godzin tygodniowo.

A z perspektywy pracy programisty? Jak wygląda hiszpańska kultura pracy w IT?

Na pewno warto wspomnieć o podejściu do sprint backlogu. Moje doświadczenie opiera się wyłącznie na pracy w dużych firmach. W Polsce sprint backlog często ustalany był na podstawie 'prędkości’ zespołu, ale management nierzadko dokładał dodatkowe zadania czy zmieniał priorytety. Panuje przekonanie, że 'im więcej, tym lepiej’. W Hiszpanii styl pracy jest bardziej swobodny; sprint backlog nie jest przeładowany. Jeśli zostaje dodatkowy czas, zadania są dokładane, ale nie wynika to z 'leniwej’ mentalności, co jest typowym stereotypem dotyczącym Hiszpanów.

W Polsce to podejście zaczyna być popularne, ale w Hiszpanii od wielu lat funkcjonuje coś, co nazywa się Dniem Fundacji (Foundation Day). To kilka dni w roku (w przypadku Sage jest to 5 dni), które pracownicy mogą wykorzystać na wolontariat i działalność charytatywną, indywidualnie lub zespołowo. Można na przykład prowadzić mentoring dla młodych programistów, czy czytać książki dzieciom w domach dziecka. W zeszłym roku miałem okazję po raz pierwszy wziąć udział w Dniu Fundacji, gdzie wraz z zespołem zbieraliśmy oliwki w jednym z katalońskich sadów, przeznaczone na produkcję oliwy z oliwek.

W branży IT jesteś od 2012 roku. Co przez ten czas nie zmieniło się, jeśli chodzi o polski rynek pracy?

Pracując tylko w Polsce, wiele rzeczy się nie zauważa, a wiele innych przyjmuje się za pewnik, w stylu „bo tak jest”. Dzięki moim poprzednim pracodawcom w Polsce, miałem okazję odbyć wiele podróży służbowych, nie tylko po Europie i już wtedy zacząłem zauważać różnice w zachowaniach w branży IT. Rynek w Polsce zmienia się i to na lepsze, ale z moich obserwacji wynika, że pewne rzeczy pozostają niezmienne.

Pierwszym przykładem jest zwyczaj przerwy na lunch. Ustawowo, każdy pracownik ma prawo do przerwy, ale często słyszałem komentarze menedżerów, że ktoś za długo spożywa posiłek, choć nikt tego czasu nie kontrolował. Typowe jest również jedzenie przy biurku, w pośpiechu. Sam często musiałem zakładać w kalendarzu spotkanie o nazwie „lunch break”, aby mieć czas na chwilę wytchnienia między spotkaniami.

Kolejną niezmienną sytuacją jest brak zaufania do pracownika pracującego z domu. Może to wyglądać inaczej dla większości z Was, ale piszę to z perspektywy pracownika zatrudnionego na podstawie umowy o pracę w międzynarodowych korporacjach. Zawsze odnosiłem wrażenie, że pracując z domu, jesteśmy postrzegani jako mniej wydajni, jako osoby, które spędzają czas na obowiązkach domowych, telewizji czy innych rozrywkach. Nieraz słyszałem o praktykach monitorowania ruchów myszki, kontroli statusu na komunikatorze czy innych tego typu zagrywkach. To moim zdaniem jest bardzo krzywdzące dla nas i wpływa na nasze morale.

Niezmienną cechą w Polsce jest także nasza wydajność. Polscy programiści są bardzo wydajni i potrafimy wykonać większość zadań w relatywnie krótszym czasie w porównaniu do innych narodowości. Niestety, jak wcześniej wspomniałem, widoczne jest to również podczas tworzenia sprint backlogu. W Polsce panuje zasada wrzucania jak najwięcej zadań, co niestety później skutkuje koniecznością tłumaczenia się, dlaczego zadanie nie zostało zrealizowane przez zespół.

Ostatnim elementem, który chciałbym poruszyć, jest rozmowa rekrutacyjna, a dokładniej jej techniczna część. Większość firm prowadzi ją poprawnie, w formie dialogu, z zachowaniem kultury i przyjaznego podejścia. Jednak nadal zdarzają się sytuacje, w których przepytujący programista wręcz stara się pogrążyć kandydata, wykazując zażenowanie czy gniew. Sam niejednokrotnie doświadczyłem tego, gdy dostałem bardzo trudne zadanie do rozwiązania „przy tablicy”, przy jednoczesnym ponaglaniu i zadawaniu dziwnych pytań, takich jak „czy jestem pewien, że mój kod to na pewno C#?”. Zazwyczaj kończyło się to przepraszaniem ze strony działu HR za zachowanie kolegi.

Co z kolei zdecydowanie powinno ulec zmianie?

Wiele zachowań jest głęboko zakorzenionych w naszej kulturze i relacjach społecznych, co sprawia, że trudno dokonać zmian. Jednak z mojej perspektywy, istnieją dwie kwestie z wcześniej wymienionych, które wymagają zmiany.

Pierwszą z nich jest wspomniane wcześniej zaufanie do pracownika. Wiadomo, że zdarzają się przypadki osób o obniżonej wydajności, lecz nie można wszystkich oceniać tą samą miarą. Każdy dobry menedżer czy team leader powinien dostrzegać wydajność poszczególnych jednostek i adekwatnie reagować na wszelkie problemy.

Druga kwestia dotyczy rozmowy rekrutacyjnej technicznej w opisanej wcześniej sytuacji. Zdaję sobie sprawę, że kandydaci mają różny poziom wiedzy i że programista oceniający może mieć lepszy lub gorszy dzień. Jednakże, bez względu na okoliczności, należy zachować profesjonalizm. Przyszłość kandydata nie powinna zależeć od osobistych problemów osoby przeprowadzającej rekrutację. Niestety, czasami panuje błędne przekonanie o wyższości osoby oceniającej.

Na podstawie jakich czynników zazwyczaj oceniałeś, że to już czas zmienić miejsce zatrudnienia?

Mówi się, że średni czas zatrudnienia w jednej firmie wynosi dwa lata (tak przynajmniej było przed kryzysem). Jednak uważam, że jeśli jesteśmy zadowoleni z naszej pracy i osób, z którymi współpracujemy, nie ma potrzeby jej zmieniać. Osobiście kieruję się trzema czynnikami, które pomagają mi ocenić, czy nadszedł czas na poszukiwanie nowych wyzwań.

Po pierwsze, praca musi być dla mnie satysfakcjonująca finansowo. Jest to kwestia oczywista dla wszystkich i nie ma co się nad nią rozwodzić. Wiadomo, że na początku negocjujemy odpowiednią stawkę. Jednak jeśli przez lata nasze zarobki w danej firmie zaczynają odstawać od standardów rynkowych w tym samym regionie, warto rozważyć zmianę.

Programowanie jest jak miłość, gdzie chemia musi wydzielać się z obu stron. Jeśli kocham to, co robię, oczekuję pozytywnej reakcji w postaci zadowolenia użytkowników. Motywacja jest zatem drugim kluczowym czynnikiem. Na przykład w mojej karierze miałem okazję pracować dla jednej z największych firm dostarczających rozwiązania software’owe i hardware’owe dla przedsiębiorstw z sektora sprzedaży detalicznej. Odczuwam dreszczyk dumy za każdym razem, gdy robię zakupy w Decathlonie, Ikei czy Sephorze, widząc jak mój kod funkcjonuje w stanowiskach samoobsługowych, kasach fiskalnych i terminalach płatniczych.

Ostatnim czynnikiem jest stagnacja i brak rozwoju. Jestem świadomy, że oprogramowanie w dużych korporacjach często zmienia się bardzo wolno i że pracujemy na starszych wersjach języków programowania czy bibliotek. Jeśli jednak ta sytuacja utrzymuje się przez lata, otrzymujemy ciągle te same powtarzalne zadania i zaczynamy odstawać od aktualnych trendów na rynku pracy, warto przemyśleć swoją pozycję w firmie.

Co wpływa na to, że pozytywnie oceniasz daną firmę?

Podczas poszukiwania nowej pracy mam ustalone kryteria, na podstawie których oceniam potencjalne firmy. Rozumiem, że każdy z nas ma inne przekonania i doświadczenia, ale chciałbym podkreślić, że odpowiadam z własnej perspektywy.

Przede wszystkim istotna jest dla mnie liczba pracowników i wielkość firmy. Moje pierwsze doświadczenie zawodowe zdobyłem w małym startupie, gdzie liczba pracowników wynosiła około dziesięciu osób. W takim środowisku „bus factor” często wynosił 1. Od tamtej pory wiedziałem, że małe firmy nie są dla mnie. Obecnie skłaniam się ku dużym organizacjom o stabilnej pozycji na rynku, co daje mi poczucie bezpieczeństwa (przynajmniej do czasów obecnych fal zwolnień).

Bardzo pomocnym narzędziem jest także wskaźnik średniej długości zatrudnienia według LinkedIn na koncie Premium, który wyraźnie pokazuje średni poziom zadowolenia pracowników.

Pochodzę ze Śląska i ten rynek pracy jest mi najbliższy. W Katowicach i okolicach nie ma zbyt wielu firm w porównaniu z Warszawą czy Krakowem, ale dzięki rozbudowanej sieci kontaktów często mam możliwość porozmawiania z osobami pracującymi w danej firmie o warunkach pracy u potencjalnego pracodawcy. Kolejnym ważnym czynnikiem są zatem opinie pracowników. Nigdy nie kieruję się opiniami publikowanymi w Internecie, które często są jednostronnie negatywne i rzadko odzwierciedlają rzeczywistość. Preferuję rozmowę z obecnymi lub byłymi pracownikami firmy, jeśli to możliwe.
Ostatnim aspektem jest już wspomniane podejście do kandydata podczas rozmowy rekrutacyjnej. Sposób, w jaki traktowany jest potencjalny pracownik, często odzwierciedla przyszłe relacje w miejscu pracy.

Na przestrzeni lat to podejście zmieniało się?

Na przestrzeni lat podejście do zmiany miejsca oraz wskaźniki, którymi się kierowałem przy jej wyborze się nie zmieniały. Zawsze się one sprawdzały i nigdy mnie nie zawiodły.

Jaką radą chciałbyś podzielić się z naszymi czytelnikami? Co dało ci największy boost w karierze?

Każdy z nas wie, jakie kroki podjąć, aby stać się lepszym programistą. Nie chcę powielać tych samych, oklepanych fraz. Chciałbym jednak podzielić się kilkoma spostrzeżeniami, które pomogły mi osiągnąć znaczący postęp w mojej karierze.

Najważniejsze jest rozwijanie się i samokształcenie po godzinach pracy. Wszyscy o tym wiedzą, ale znam wielu, którzy tego nie robią, skupiając się wyłącznie na swoich codziennych zawodowych obowiązkach. To sprawia, że pozostają w tyle i mają trudności z adaptacją do nowych zmian w projekcie. Na przykład, w dużych korporacjach nowinki technologiczne są wprowadzane z opóźnieniem. Gdy wstrzykiwanie zależności (przynajmniej w .NET) zostało wprowadzone, osoby, które nie rozwijały się na własną rękę, miały trudności ze zrozumieniem jego potrzeby, sensu czy zasad działania.

Kolejnym ważnym elementem jest sposób nauki. Moja rada? Stwórz problem i go rozwiąż. Nauka nowego frameworka nigdy nie polegała u mnie na oglądaniu kursów na Pluralsight czy LinkedIn Learning. Ślepe podążanie za wykładowcą nigdy nie przynosiło mi takich efektów, jak stworzenie i rozwiązanie własnego problemu. Zawsze staram się zaprojektować proste narzędzie, jak na przykład przepiśnik, menadżer haseł czy książka telefoniczna, a następnie, opierając się na dokumentacji, dokonać jego implementacji. Problemy, które napotykam, rozwiązuję tak samo, jak w normalnej pracy: przez dokumentację, StackOverflow, Google, teraz także ChatGPT i inne podobne źródła. Dzięki temu czuję, że zdobywam wiedzę, która zostanie ze mną na dłużej.

W pracy zawsze dążę do rozwoju. Bardzo pomocne (choć pewnie nie wszyscy się ze mną zgodzą) jest posiadanie przynajmniej podstawowej wiedzy na tematy spoza swojej specjalizacji. Przykładowo, jako programista mam świadomość co robi QA, z jakimi narzędziami pracuje, jakie mamy rodzaje testów, itp. Mam także pewną wiedzę o DevOps, o czym świadczy znajomość pojęć takich jak infrastructure as a code, np. terraform czy bicep, i sposobów przygotowywania CI/CD. Rozumiem również problemy, z jakimi boryka się project management, znam wykres Gantta i różne techniki dostarczania oprogramowania.
Chcę przez to powiedzieć, że wychodząc poza swoją strefę komfortu, jesteśmy w stanie lepiej zrozumieć innych członków zespołu, zarówno tych z działu technicznego, jak i pozostałych, co pozwala nam efektywnie realizować wyznaczone cele i daje nam impuls do rozwoju zawodowego.

Ostatnim elementem jest nasze podejście do siebie. Praca czy nauka po godzinach wymagają dużo czasu, ale bardzo ważne jest znalezienie złotego środka przez zapewnienie sobie czasu na relaks. Nie możemy być robotami czy stereotypowymi informatykami, pracującymi po 20 godzin dziennie w ciemnej piwnicy. Należy odnaleźć swoje pasje i je pielęgnować. Pozwoli to na regenerację i zapewni lepszą gotowość do codziennych zadań. Szanowanie czasu pracy, unikanie nadgodzin i dbałość o rekreację pozwolą nam skuteczniej zapobiegać wypaleniu zawodowemu.

---

Marcin Czernecki. Inżynier oprogramowania z ponad 12-letnim doświadczeniem. Ostatnie trzy lata jako pracownik firmy Sage w słonecznej Barcelonie. Karierę oparł głównie na technologiach Microsoftu, ze szczególnym zamiłowaniem do Azure i AWS, jako backend developer. Ostatnio coraz większe zainteresowanie kierowane również w stronę frontendu. Poza pracą zawodową – mąż, ojciec, pasjonat eksperymentów kulinarnych oraz entuzjasta podróży bliskich i dalekich.