Uwaga! Trwają prace nad nową wersją serwisu. Mogą występować przejściowe problemy z jego funkcjonowaniem. Przepraszam za niedogodności!

🔥 Zgarnij PŁATNY STAŻ w 3 edycji kursu programowania front end (zapisy do 22.01) 🔥

Wnioski po 6 latach pracy w zawodzie programisty

Doświadczenia inżyniera informatyki

Marek Szkudelski, front-end developer w Allegro i trener programowania, opowiada o swoich doświadczeniach po 6 latach pracy w zawodzie programisty. Rozmawiamy nie tylko o rozwoju umiejętności miękkich i technicznych, lecz także o błędach popełnianych w nauce programowania oraz na różnych etapach kariery, o porażkach czy zdrowiu.

Poruszane tematy

  • Czy możesz się przedstawić i powiedzieć, co łączy Cię z branżą IT?
  • Pracujesz obecnie jako front-end developer w Allegro – dzięki czemu według Ciebie udało Ci się zdobyć tę posadę? Masz jakieś rady dla początkujących programistów?
  • Na podstawie swojego doświadczenia: jakie umiejętności miękkie uważasz za niezbędne w pracy programisty?
  • Czy Twoje podejście do rozwoju umiejętności technicznych zmieniło się po 6 latach pracy?
  • Co w kwestii rozwoju umiejętności technicznych doradziłbyś osobom, które dopiero uczą się programowania?
  • A tym, którzy już pracują na stanowisku juniorskim?
  • Prócz tego, że sam programujesz, uczysz też programowania innych. Jakie widzisz najczęściej popełniane błędy? Jak można ich unikać?
  • Czy na przestrzeni tych 6 lat pracy popełniałeś jakieś błędy, które uświadomiłeś sobie dopiero po pewnym czasie? Czego się wystrzegać, gdy mamy coraz więcej doświadczenia w pracy?
  • Trafiłem na LinkedInie na Twój artykuł „Jak radzić sobie z porażkami”, w którym dzielisz się m.in. swoją historią zwolnienia po dwóch latach pracy. Czy chciałbyś o tym opowiedzieć i podzielić się wskazówkami, jak pozbierać się w takiej sytuacji?
  • Na co stawiasz na rozmowie kwalifikacyjnej, z jakiej strony chcesz się najlepiej zaprezentować?
  • Czy doświadczyłeś już wypalenia zawodowego? A może świadomie mu przeciwdziałasz?
  • Tyle mówi się o umiejętnościach, a co z naszym zdrowiem? Czy komuś w tym zakresie odradzałbyś zawód programisty?
  • Jak radzisz sobie z dolegliwościami wynikającymi z pracy przy komputerze? Może masz jakieś wskazówki?
  • Jak zmieniła się Twoja perspektywa na branżę IT? Jak postrzegałeś ją na samym początku, a jak ją odbierasz teraz?
  • Jaką książkę polecisz osobie, która chce rozwijać się nie tylko jako programista, ale też wartościowy członek zespołu?
  • Gdzie możemy Cię znaleźć w sieci?

Polecana książka

Cytat z rozmowy: Nie wiem, czy poleciłbym jakąś książkę w tym temacie. Żadna mi nie przychodzi do głowy. Uważam natomiast, że najbardziej wartościowi członkowie zespołu dzielą się wiedzą zarówno merytoryczną, twardą, jak i miękką, domenową. Myślę więc, że trzeba słuchać bardziej doświadczonych ludzi z branży i również samemu rozwijać się w różnych aspektach.

Kontakt do gościa

➡ Blog: blog.szkudelski.dev

➡ LinkedIn: linkedin.com/in/mszkudelski

➡ Biuletyn Praca programisty na miękko

Transkrypcja

Dziś moim gościem jest Marek Szkudelski. Marek podzieli się z nami swoim doświadczeniem i opowie o wnioskach po sześciu latach pracy jako programista.

Marku, dziękuję, że przyjąłeś moje zaproszenie na rozmowę!

Dzięki za zaproszenie. Witam wszystkich słuchaczy.

 

Marku, to może zacznijmy od przedstawienia Twojej osoby. Powiedz nam, co łączy Cię z branżą IT.

Na co dzień pracuję jako inżynier front endu w Allegro, ale w moim życiu dużą rolę odgrywa też rodzina. Jestem ojcem i mężem. Jeśli chodzi o branżę IT, to po godzinach również uczę innych programowania zazwyczaj początkujące osoby. Dzielę się wiedzą przez swojego bloga, przez mój profil na LinkedInie i prowadzę też biuletyn Praca programisty na miękko.

 

Tak jak wspomniałeś pracujesz obecnie jako front-end developer w Allegro – dzięki czemu według Ciebie udało Ci się zdobyć tę posadę? Masz jakieś rady dla początkujących programistów?

Tę posadę w Allegro udało mi się zdobyć dlatego, że się nie poddałem. Pierwszy raz próbowałem się dostać do Allegro już w 2019 roku, ale byłem wtedy ledwo co regularem w ówczesnej firmie, w której pracowałem – wtedy był to mały software house. Nie dostałem się do Allegro za pierwszym razem i za kolejnym też nie. W sumie próbowałem 3-4 razy i dopiero wtedy mi się udało.

Przede wszystkim więc się nie poddawałem. Nie jest jednak tak, że po prostu próbowałem kolejne razy, tylko za każdym razem, kiedy dostawałem feedback od rekrutera i dowiadywałem się o tym, co poszło nie tak podczas rozmowy i podczas rozmowy technicznej, brałem sobie ten feedback do serca i starałem się w tym kierunku rozwijać. Starałem się poprawiać w tych aspektach, które wymagały poprawy. Próbowałem się dowiedzieć jak najwięcej na tematy, o których nie wiedziałem podczas rozmowy, i oczywiście cały czas rozwijałem się też w innych aspektach, które były mi potrzebne do tego, żeby dobrze wykonywać swoją pracę.

Mówisz, że próbowałeś dostać się cztery razy do jednej firmy. To nie jest jedyna firma w Polsce, która ma, powiedzmy, dobre warunki. Dlaczego akurat do niej chciałeś się dostać?

Myślę, że Allegro w Polsce jest bardzo znaną i dobrze postrzeganą firmą w branży IT. Szczególnie w Poznaniu, gdzie mieszkam, ma swoją największą siedzibę. Mam znajomego, który pracuje w Allegro, i to on też zachęcał mnie, żeby się tam dostać. Opowiadał mi o tym, jakie są tam perspektywy rozwoju, i myślę, że te perspektywy rozwoju najbardziej mnie zachęciły – że jest to bardzo duża firma, duży projekt i są naprawdę duże perspektywy na to, żeby się rozwijać w różnych kierunkach.

Bardzo fajnie brzmi. Chyba muszę napisać do nich, żeby zasponsorowali odcinek albo lepiej Ciebie docenili, że tak dobrze o nich mówisz.

 

To skoro już jesteśmy przy rozwoju: jakie umiejętności miękkie uważasz za niezbędne w pracy programisty? Często się mówi o kompetencjach technicznych – o tych twardych umiejętnościach. A co z miękkimi?

 

Myślę, że taką najważniejszą umiejętnością jest umiejętność ciągłego rozwoju w różnych aspektach. Branża IT jest o tyle specyficzna, że tutaj bardzo szybko dużo rzeczy się zmienia: zmieniają się technologie, zmieniają się języki programowania, są nowe standardy, nowe wzorce, nowe procesy, nowe sposoby wytwarzania oprogramowania. Myślę więc, że ta chęć i umiejętność ciągłego rozwoju jest tutaj bardzo ważna – żeby nie zniknąć w tej branży.

Sądzę też, że w tym zawiera się umiejętność zarządzania czasem żeby umieć znaleźć czas na rozwój, ale też żeby już poza rozwojem umieć sobie poukładać odpowiednio zadania i priorytety w pracy.

Bardzo ważna jest tutaj samokrytyka, bo nie będziemy się rozwijać, jeśli nie będziemy wiedzieli, w jakich aspektach możemy się rozwinąć – czyli w jakich obszarach nasze umiejętności nie są zbyt wysokie albo w ogóle ich nie mamy.

Myślę, że ważna jest też umiejętność adaptacji do nowych sytuacji. Dzięki temu, że możemy się zaadaptować do nowej sytuacji, możemy też w prosty sposób nauczyć się czegoś nowego.

Kolejną ważną umiejętnością miękką w pracy programisty jest komunikacja interpersonalna. Z dwóch powodów: po pierwsze dlatego, że pracujemy w zespołach, więc musimy się komunikować, żeby jako zespół efektywnie dowozić oprogramowanie, a nie tylko jako jednostki; po drugie w firmach trzeba po prostu komunikować się na wielu poziomach. Trzeba umieć rozmawiać z szefem, trzeba umieć rozmawiać ze współpracownikami, z ludźmi z innego działu, z którymi musimy współpracować.

Dodajmy, że czasem musimy też umieć rozmawiać z klientem. Zależy od struktury. Jeżeli jesteśmy firmą produktową, tak jak Allegro, to pewnie tutaj coś takiego nie występuje, ale jeżeli pracujemy w software housie, to być może będziemy oddelegowani właśnie do klienta – żeby go o coś podpytać: czy to ma wyglądać tak, czy inaczej. To też pewnie jest bardzo ważne, a nie wszyscy chcą iść do klienta. Nie wszyscy też potrafią porozmawiać z klientem

Wspomniałeś o tym, że trzeba znaleźć czas na rozwój, na naukę. Jak to z Twojej perspektywy wygląda? Nie chodzi mi tutaj o Twojego obecnego pracodawcę, ale czy uważasz, że ten czas powinien być zawarty w tych ośmiu godzinach pracy? Czy to robimy po godzinach?

Myślę, że bardzo dobrze, jeśli to się zawiera w tych ośmiu godzinach pracy. Ale nie zawsze jest taka możliwość. Jestem świadomy, że są niektóre firmy, które nie dają pracownikom zbyt dużo czasu na to, żeby się rozwijać w kierunku nowych umiejętności.

Myślę jednak, że możemy zrobić kilka rzeczy, które przyspieszą nasz rozwój pomimo tego, że nie poświęcamy na to dodatkowego czasu. Warto na przykład podejmować się nowych wyzwań w pracy – jeśli kodujemy we front endzie, to być może wziąć jakieś zadanie, bardzo proste, back-endowe; być może jakieś zadanie DevOps-owe, żeby stworzyć na przykład jakieś automatyczne budowanie się projektu.

Warto też poświęcać chwile, które mamy w pracy, gdy na przykład czekamy, aż przejdą testy, czy aż projekt się zbuduje. Można wtedy przeczytać jakiś artykuł, można obejrzeć jakąś lekcję z kursu online. Myślę więc, że bardzo dobrze, jeśli możemy to robić w czasie pracy. A jeśli nie, to możemy znaleźć go też poza pracą. Od każdej osoby zależy, jaki to będzie czas. Niektóre osoby wolą pewnie uczyć się rano, niektóre wieczorem.

A jak sądzisz: jak ważną rolę gra ten element czasu na rozwój przy zmianie pracy? Jak rozmawiasz ze znajomymi, to jest dla nich istotne, czy mogą się w pracy rozwijać – mieć, powiedzmy, godzinę dziennie na naukę tego, co można potem wykorzystać w pracy?

Na pewno jest to istotne. Jeśli pracodawca oferuje czas w czasie pracy na to, żeby się rozwijać, albo wysyła na jakieś zewnętrzne szkolenia, albo organizuje jakieś szkolenia wewnętrzne, to na pewno jest to bardzo duży plus dla takiej firmy.

Tak że ważna informacja dla firm: mówcie o tym na rekrutacji, mówcie o tym w ofertach pracy, bo ludzie na to zwracają uwagę. Myślę, że dla mnie to też by było bardzo istotne, bo tak jak i Ty, też jestem mężem i ojcem i po prostu po powrocie do domu chciałbym poświęcić ten czas rodzinie, a niekoniecznie robić jeszcze coś dodatkowego, żeby się rozwijać. Rozwój w czasie pracy jest też na plus dla tej firmy, bo potem wykorzystuję te umiejętności w tej firmie – warto więc robić to w czasie pracy.

 

No dobrze, to mamy ze sobą umiejętności miękkie. Trochę sobie porozmawialiśmy na temat czasu pracy i rozwoju. To jak to wygląda, jeśli chodzi o umiejętności techniczne? Czy z Twojej perspektywy po tych sześciu latach pracy jako programista coś się pozmieniało? Czy patrzysz na te umiejętności techniczne w inny sposób? Jakoś inaczej do tego podchodzisz niż na samym początku?

Zdecydowanie. Jeśli chodzi o same umiejętności techniczne, to na początku byłem bardzo skupiony na takim dosłownym traktowaniu kodu. Zastanawiałem się, co robi dana funkcja, metoda, dany operator. Skupiałem się na tych rzeczach, które pozwolą mi samodzielnie pracować. Często jednak na przykład nie potrafiłem rozpoznać, czy dana funkcja to element języka czy frameworka, tylko skupiałem się na tym, co robi ta funkcja.

Skupiałem się też przede wszystkim na nauce konkretnych technologii, czyli poznawałem konkretny framework, konkretny język programowania, w którym akurat wtedy pracowałem (to był JavaScript). Dopiero w kolejnym etapie starałem się poznawać też inne technologie, żeby rozszerzyć sobie perspektywę na to, czym w ogóle jest programowanie, i w jaki sposób się programuje. Starałem się też dostrzegać takie rzeczy, które są niezależne od języka czy frameworka. Bardziej skupiałem się na wzorcach projektowych, na dobrych praktykach. Później też zorientowałem się, że bardzo ważne są umiejętności miękkie, nie tylko techniczne.

Co na podstawie tej ścieżki, którą tutaj przedstawiłeś, doradziłbyś teraz osobom, które dopiero zaczynają naukę programowania? Sugerowałbyś trochę inne podejście, czy wydaje Ci się, że jest to naturalna ścieżka i w ten sposób powinniśmy właśnie podchodzić do nauki umiejętności technicznych?

Myślę, że takie podejście na początku jest dobre, dlatego że pozwala szybko zobaczyć efekty i dzięki nim znaleźć radość z programowania. Jeśli widzimy efekt, to wtedy mamy motywację, satysfakcję i chcemy dalej się rozwijać. Warto więc wziąć konkretny język, konkretny framework i po prostu zacząć programować w tym frameworku, żeby – zobaczyć szybko efekty i żeby zmotywować się do dalszego rozwoju.

Też tak myślę: że nie ma co się zagłębiać na początku w abstrakcyjne tematy, bo to powoduje, że zamiast skupić się na rozwoju i poznawaniu języka, zaczynamy troszkę błądzić. Wówczas zamiast nauczyć się programowania, powiedzmy, w rok, poświęcamy nie wiadomo jak dużo czasu, zagłębiamy się w różne tematy i nie jesteśmy w stanie pójść do przodu.

Na samym początku trudno też nam ocenić taką ogólną perspektywę – bo skoro nic jeszcze sami nie zrobiliśmy, nie widzieliśmy, jak cały system działa, to trudno, żebyśmy mogli sobie wyobrazić, o co chodzi w abstrakcji. Zgodzisz się?

Dokładnie. Myślę, że może też dochodzić do czegoś takiego jak over engineering, czyli przerost formy nad treścią, bo do końca nie znamy jeszcze przypadków użycia danego wzorca, ale wiemy, że jest taki fajny wzorzec i chcemy się pochwalić przed kolegami, że umiemy czegoś takiego używać. Używamy go więc i okazuje się, że ten poziom abstrakcji w ogóle nie był tutaj potrzebny i można było to zrobić dużo prościej.

Tak, i często staramy się wszędzie go wykorzystywać – gdzie tylko możemy – żeby pokazać, że umiemy.

 

OK, no dobrze, to to było pytanie odnośnie do osób, które zaczynają naukę. A jak to wygląda u osób, które już są na stanowisku juniorskim i mają doświadczenie komercyjne? Co byś takim osobom polecił?

Myślę, że takie osoby powinny skupić się na tym, żeby stać się samodzielne w pracy – czyli dojść do poziomu regulara. Powinny dobrze poznać framework, z którym pracują, i język programowania. Jednocześnie powinny starać się już zacząć dostrzegać jakieś wzorce, elementy, które się powtarzają w programowaniu i które w danych sytuacjach mają adekwatne użycie

Takie osoby powinny też więcej czasu spędzać na analizowaniu kodu, a nie tylko na pisaniu. Powinny podglądać bardziej doświadczone osoby – to, jak one rozwiązują dane problemy, w jaki sposób piszą kod, jakich wzorców i dobrych praktyk używają. Warto również takie osoby odpytywać: dlaczego zrobiły coś w dany sposób, a nie inaczej.

Dlatego myślę, że jeśli chodzi na przykład o proces code review, to powinny być zaangażowane w niego wszystkie osoby z zespołu, nie tylko senior albo regular, ale również junior – właśnie dlatego, że może on podglądać, jak pracują bardziej doświadczone osoby i w jaki sposób piszą one kod.

A jak myślisz: jak najprościej zacząć od wzorców? Czy powinniśmy wziąć książkę, doczytać, jak one wyglądają i szukać ich w kodzie? Czy raczej prosić doświadczone osoby, żeby określały, czego używają – żeby wiedzieć, że to jest to i starać się odwzorować to w swoim projekcie?

Myślę, że obydwa sposoby są dobre. Z jednej strony powinniśmy poznać teorię, czym w ogóle jest dany wzorzec i kiedy teoretycznie powinno się go wykorzystywać, a z drugiej strony powinniśmy też pochylić się nad naszym projektem, nad naszym kodem i zastanawiać się, gdzie taki wzorzec mógłby być użyty. I być może właśnie wtedy weryfikować to z bardziej doświadczonymi osobami – czy faktycznie dobrze dostrzegam, że tutaj powinien być użyty dany wzorzec.

A czy jest w ogóle czas na taką rozmowę w pracy – żeby zespół się spotkał i powiedział: OK, może byśmy tutaj użyli tego wzorca, bo to i to; a może tutaj innego; a tu jest bez sensu, bo mamy przerost formy nad treścią. Czy trudno w pracy znaleźć czas na takie omawianie poszczególnych elementów systemu?

Myślę, że powinien znaleźć się taki czas w pracy, dlatego że z jednej strony rozmawiamy o tym, w jaki sposób lepiej napisać dany system, ale z drugiej strony też dzielimy się wiedzą, czyli zwiększamy kompetencje członków zespołu. Przez to właśnie te osoby piszą system lepiej. Być może czasami nawet takie spotkanie będzie lepsze niż wysłanie pracowników na jakieś zewnętrzne szkolenia.

I może też będzie to taka informacja dla pracodawcy, że warto to robić – żeby nie oceniać tego jako strata czasu. Wówczas okaże się, że jeżeli zabraknie jednego programisty, to drugi będzie w stanie go zastąpić. Natomiast jeżeli każdy będzie trzymał wiedzę dla siebie, to tak naprawdę jedno „L4” i nie jesteśmy w stanie pójść do przodu.

Dokładnie, zgadzam się.

 

No dobrze, to w takim razie przejdźmy do kolejnego tematu, bo oprócz tego, że sam programujesz, to uczysz też programowania innych. Jak z Twojej perspektywy wygląda temat błędów – jakie są najczęściej popełniane i jak osoby uczące się programowania mogą ich unikać?

Myślę, że najczęściej popełnianym błędem, który ja obserwuję, jest takie pchanie swojego rozwoju do przodu zbyt szybko. Ja to rozumiem, bo takie osoby często są bardzo zapasjonowane programowaniem i bardzo zmotywowane do tego, żeby się rozwijać. Często pewnie – jeśli są w czasie przebranżowienia się – chcą jak najszybciej znaleźć pracę w branży.

Sądzę jednak, że może to prowadzić do luk w wiedzy, gdzie na późniejszym etapie się okaże, że zabraknie nam jakichś podstaw, jakiegoś lepszego zrozumienia podstawowych mechanizmów danego języka programowania czy frameworka. Czasem więc warto się cofnąć i lepiej zrozumieć podstawy, żeby później efektywniej pójść do przodu.

Ja również to obserwuję. Mam takie przemyślenie, że to wynika z tego, że te osoby za dużo od siebie wymagają – myślą, że programowania można się nauczyć w miesiąc czy dwa, co powoduje, że mówią: dobra, to ja muszę przyspieszyć, bo zaraz nie starczy mi czasu na znalezienie pracy. I to jest ten pośpiech, który potem tak naprawdę kosztuje nas dwa razy, bo nie dość, że nie pójdziemy do przodu, możemy się zniechęcić, to jeszcze dodatkowo tracimy czas na cofnięcie się o nadrabianie braków,

Trzeba więc dać sobie trochę więcej czasu i więcej luzu. Łatwo się mówi, wiem, ale to jest dobra rada: żeby czasami zwolnić po to, by móc potem przyspieszyć, a nie się zniechęcić.

Dokładnie. Myślę, że trzeba po prostu zastanowić się, co musimy wiedzieć na danym stanowisku, które nas interesuje, i żmudnie przechodzić przez każdy z tych tematów – może nie zgłębiając się jakoś bardzo, ale na pewno poznając je dobrze i oczywiście sprawdzając się też w praktyce, czyli wykorzystując tę wiedzę w jakimś projekcie.

Jeżeli mamy możliwość, to fajnie byłoby też poprosić kogoś o przeanalizowanie kodu, o code review takiego projektu, bo to pozwoli nam sprawdzić, czy faktycznie rozumiemy wszystko tak, jak trzeba. Z drugiej strony ta osoba może nam podrzucić inne pomysły, które też się przydadzą. I wcale to nie musi być superdoświadczona osoba, bo nawet od kogoś, kto zaczyna, można się dużo nauczyć.

Jak sam stwierdziłeś: junior też powinien robić code review, bo dzięki temu nie dość, że sam się nauczy, to może też coś podpowiedzieć lub zadać pytanie, które otworzy nasz umysł. Przynajmniej tak to widzę u siebie – że czasami coś robię, bo tak robię, bo zawsze tak robiłem, i nawet się nie zastanowię, czy można podejść do tematu trochę inaczej.

Dokładnie. Myślę, że właśnie dlatego warto pomagać początkującym osobom czy juniorom. Sami możemy się przy tym czegoś nauczyć albo lepiej zbadamy jakiś temat, bardziej go zagłębimy; albo okaże się, że jednak czegoś tak dobrze nie wiemy – bo jeśli nie umiemy tego wytłumaczyć, to tak naprawdę sami tego do końca nie rozumiemy.

Tak jest.

 

Jak już jesteśmy przy temacie błędów, to chętnie bym się Ciebie zapytał, czy na przestrzeni tych sześciu lat pracy popełniłeś jakieś błędy. To oczywiste, że na pewno tak, ale czy były takie błędy, które sobie uświadomiłeś dopiero po jakimś czasie? Gdy mamy coraz więcej doświadczenia w pracy, nasza perspektywa się zmienia. Może jesteś w stanie podpowiedzieć, jak się takich błędów wystrzegać.

Myślę, że takim największym błędem, który zrobiłem na początku swojej kariery, było skupienie się na samym kodowaniu. Skupiałem się na tym, co mam zaprogramować, a nie skupiałem się na całej tej otoczce, która się wiąże z procesem wytwarzania oprogramowania. W związku z tym nie byłem za bardzo aktywny na spotkaniach, nie podejmowałem się żadnych analiz technicznych, żadnych researchu czy code review. Nie było to dla mnie zbyt ciekawe, więc się w to nie angażowałem

Dopiero po czasie zorientowałem się, że to jednak jest ważna część pracy programisty – że programista nie powinien się skupiać tylko na programowaniu (bo wtedy będzie takim zwykłym koderem), lecz na tym wszystkim, co jest wokół. Wtedy staje się inżynierem oprogramowania.

Mówisz, że się nie udzielałeś. Czy przede wszystkim było to z powodu tego, że nie widziałeś w tym sensu, czy też trochę się obawiałeś? Pewnie wokół Ciebie byli bardziej doświadczeni koledzy i być może nie chciałeś popełnić jakiejś gafy, żeby Cię źle nie ocenili.

Dobrze powiedziałeś: nie chciałem popełnić jakiejś gafy. Myślałem, że jeśli już coś mówię, to musi mieć to sens i musi przynosić wartość innym. A teraz, jak patrzę na spotkania, to widzę, że nawet pytanie może przynieść wartość zespołowi. Z jednej strony dlatego, że być może reszta zespołu nad tym w ogóle się nie zastanawiała lub być może ktoś inny z zespołu też tego nie wie i boi się zadać pytanie; z drugiej strony im szybciej ja zdobywam wiedzę – czy to techniczną, czy merytoryczną, domenową – tym szybciej przynoszę wartość dla zespołu.

Czyli można byłoby powiedzieć, że nie ma co się bać pytań i pokazywania, że czegoś nie wiemy. Jest to naturalne i na tej podstawie też będziemy się uczyć. Może się okazać, że nikt się nie odzywa, a potem nikt nic nie wie i nie ma czasu na zgłębienie tematu – bo każdy myślał, że inni wiedzą. A potem trzeba w zaciszu we własnym zakresie dowiedzieć się, o co chodzi.

Dokładnie. Kiedy ja wdrażam jakiegoś juniora albo po prostu nową osobę do zespołu, to zawsze powtarzam, że nie ma głupich pytań i żeby zadawali ich jak najwięcej. Im więcej pytań, tym lepiej.

Warto również pamiętać, że na rekrutacji też można pytać. Wydaje mi się, że wiele osób zapomina o tym, że to ma być dialog, a nie monolog. Nie tylko jedna strona pyta, druga też może. W ten sposób dowiemy się dużo więce i wyjaśnimy ewentualne niedomówienia. Podejście „a, zobaczymy, co będzie w pracy” nie jest najlepsze. Wtedy już pewnie będzie trochę za późno.

Dokładnie.

Warto więc od razu pytać na rekrutacji.

Dokładnie. Z jednej strony sami więcej się dowiadujemy, a z drugiej możemy pokazać potencjalnemu pracodawcy, jakie mamy podejście do pracy, co jest dla nas ważne.

 

No dobrze, to kolejny temat, ważny i trudny. Na LinkedInie przedstawiłeś swoją perspektywę na radzenie sobie z porażkami. Dzielisz się tam również historią zwolnienia z pracy. Czy chciałbyś o tym opowiedzieć i podzielić się z nami swoimi wskazówkami? Jak sobie z tym poradzić?

Jasne. Kiedy zostałem przyjęty do pracy, to wszystko było super. W końcu znalazłem to swoją wymarzoną pracę w branży IT jako programista. Szybko się rozwijałem i awansowałem, nawet dostawałem podwyżki. Nagle się okazało, że pracodawca mnie zwalnia. Był to dla mnie cios prosto w serce i ciężko było mi się po tym pozbierać, bo pracodawca jako powód zwolnienia podał różne aspekty, m.in. to, że dostarczam kod złej jakości, że źle robię code review, albo że project managerowie nie chcą ze mną współpracować. Tak naprawdę każdy aspekt mojej pracy jako programisty został podważony. Byłem więc w mega dużym dołku

Przede wszystkim jednak nie pozwoliłem, żeby ten bardzo negatywny feedback od ówczesnego pracodawcy mnie definiował, tylko poszukałem feedbacku u innych osób. Kiedy mówiłem o tej sytuacji moim współpracownikom, to pytałem ich też, czy z ich perspektywy jest tak samo. Mówili oni, że nie, że dobrze im się ze mną współpracuje, albo że code review robię dobrej jakości, albo że nie mają większych zastrzeżeń do mojego kodu. Dzięki temu udało mi się podbudować swoją wartość.

Myślę więc, że warto szukać dodatkowego feedbacku w przypadku, gdy ponosimy jakąś porażkę, bo być może ten feedback nie jest prawdziwy. Być może to jest perspektywa tylko jednej czy dwóch osób.

Przede wszystkim też wtedy się nie poddałem, nie zrezygnowałem z pracy jako programista, tylko zacząłem szukać nowej. Bardzo motywujące było dla mnie to, że dość szybko znalazłem tę nową pracę – dostanie konkretnej oferty zajęło mi bodajże siedem czy dziesięć dni. To mi również pokazało, że mogę być wartościowy dla kogoś z rynku.

Czyli przesłanie jest takie: przede wszystkim się nie poddawać, wierzyć w siebie i po prostu iść dalej.

Trzeba też jednak patrzeć w drugą stronę. Jeżeli faktycznie ten feedback był negatywny, to należy poprawić te rzeczy i pójść dalej. Nie można tak jednoznacznie powiedzieć „jestem najlepszy”. Oczywiście nie mówię tu o Twojej historii, Marku – że tak nie było – tylko chodzi o to, że jeżeli feedback faktycznie jest negatywny i nasi współpracownicy to potwierdzają, to pamiętajmy o tym, żeby się poprawić, a nie powiedzieć: pewnie nie mają racji, ja wiem lepiej. Czasem trzeba po prostu posypać głowę popiołem, prawda?

Dokładnie. Myślę, że tutaj dobrym przykładem są moje próby dostania się do Allegro. Po prostu brałem feedback pod uwagę i starałem się rozwijać. A jeśli chodzi o ewentualne zwolnienia z pracy, to możemy też temu zapobiegać i szukać feedbacku wcześniej niż na ostatecznej rozmowie – po prostu pytać współpracowników, przełożonego, szefa o tom co robimy źle, co robimy dobrze, co moglibyśmy robić lepiej.

 

Wracając do samych starań o pracę – wspomniałeś, że cztery razy przechodziłeś proces rekrutacyjny w Allegro. Pracowałeś też w innych firmach, więc masz spore doświadczenie. Na co stawiasz przy rozmowie kwalifikacyjnej? Z jakiej strony chcesz się zaprezentować? Na co Twoim zdaniem warto zwrócić uwagę: co działa, a co nie działa?

Ja przede wszystkim staram się być autentyczny. Nie chcę udawać kogoś, kim nie jestem, ale oczywiście staram się zaprezentować jako ekspert w swojej dziedzinie. To jednak nie oznacza, że udaję, że wiem, gdy czegoś tak naprawdę nie wiem. Czyli jeśli czegoś nie wiem albo czegoś nie jestem pewien, to mówię o tym wprost i staram się nie lać wody. Myślę, że jeśli udajemy, że coś wiemy, a tak naprawdę tego nie wiemy i po prostu lejemy wodę, to rekrutacja może przynieść odwrotny efekt.

Spotkałem się też z taką opinią, że jeżeli czegoś nie wiemy, to warto o tym powiedzieć. Wówczas pewnie dostaniemy kolejne pytanie i zwiększymy prawdopodobieństwo tego, że na większość pytań odpowiemy. Bo jeżeli będziemy się męczyć z jednym pytaniem przez całą rekrutację, to będzie to to jedno pytanie, na które nie odpowiedzieliśmy. A jeżeli powiemy, że nie wiemy, i dostaniemy kolejne, to bardzo możliwe, że na nie odpowiemy I wtedy ten procent udzielonych odpowiedzi jest dużo lepszy niż przy laniu wody.

Dokładnie. Być może się też okaże, że rekruter źle zadał pytanie, być może zada jakieś pytanie pomocnicze, które nam trochę więcej rozjaśni. Warto więc przyznać się do tego, że czegoś nie wiemy.

Nie wiem, jak u Ciebie wyglądały procesy rekrutacyjne, ale jeżeli pisałeś kod albo miałeś zadania rekrutacyjne, to czy mogłeś korzystać z Internetu albo jakichś innych pomocy? Być może sam powiedziałeś, że coś Ci wypadło z głowy i chcesz się wspomóc.

Chyba nie przypominam sobie takiej sytuacji, żebym podczas rozmowy rekrutacyjnej miał do napisania jakiś kawałek kodu. Za to wiadomo, że podczas takich zadań, nazwijmy to „domowych”, rekrutacyjnych wszystkie chwyty są dozwolone, bo nikt nie sprawdzi tego, czy korzystamy z Internetu, czy wzorujemy się na jakichś dodatkowych materiałach. Myślę, że to nie jest nic złego, bo jest to naturalna część pracy programisty – że coś, czego nie wiemy, sprawdzamy w Internecie. Nie mamy obowiązku zapamiętywać wszystkich funkcji i metod.

Zgadza się. A czy możesz nam powiedzieć, ile mniej więcej czasu miałeś na takie zadanie rekrutacyjne? Czy był deadline na jego wykonanie?

Na pewno były deadline’y. W przypadku wcześniejszych rekrutacji nie pamiętam, ile trwały, ale w Allegro na rozwiązanie zadania był chyba tydzień.

A czy jesteś w stanie powiedzieć mniej więcej, ile godzin Ci to zajęło? Wiadomo, że pewnie pracowałeś i musiałeś poświęcić swój czas po godzinach. Czy to było na przykład dziesięć godzin, czy pięć, czy dwie?

Na ostatniej rekrutacji w Allegro był wykorzystywany portal DevSkiller – nie było to takie jednolite zadanie rekrutacyjne na zasadzie stworzenia jakiegoś projektu, tylko bardziej pisanie jakichś kawałków kodu albo odpowiadanie na pytania otwarte lub zamknięte. Zajęło mi to coś w granicach godziny-dwóch.

W przypadku poprzednich rekrutacji faktycznie miałem jakiś większy kawałek kodu do napisania. To mogły być cztery godziny.

 

No dobrze, to może przejdźmy do kolejnego tematu, który być może jest trochę kontrowersyjny, ale wydaje mi się, że trzeba mocno na niego uważać. Mam tu na myśli temat wypalenia zawodowego. Czy już go doświadczyłeś i czy myślisz, że jesteśmy w stanie jakoś mu przeciwdziałać?

Mnie się wydaje, że nie odczułem takiego typowego wypalenia zawodowego. Być może jeszcze za krótko pracuję w branży, bo to dopiero sześć lat, aczkolwiek były takie okresy, kiedy mniej mi się chciało. Jednak to mijało. Zawsze też starałem się przeciwdziałać temu, żeby mi się nie chciało albo żebym się wypalił zawodowo.

Myślę, że możemy zrobić przede wszystkim dwie rzeczy. Po pierwsze: nie przepracowywać się, czyli pracować maksymalnie osiem godzin dziennie. Jeśli już robimy jakieś dodatkowe zlecenia, to najlepiej niech będzie to coś zupełnie innego, niż robimy podczas etatu – żeby właśnie nie poświęcać na coś podobnego więcej niż te osiem godzin. Warto mieć jakieś inne zajęcia po pracy, warto się spotykać z ludźmi, warto mieć jakieś hobby.

Jeśli chodzi o samą pracę, to warto szukać nowych wyzwań i zmian. Ja osobiście – jeśli jakiś projekt mi się za bardzo nudził, moje zadania stawały się za bardzo powtarzalne – starałem się go zmienić. Jeśli nie miałem akurat możliwości zmienić pracy, to na przykład prosiłem przełożonego o zmianę projektu. Jeśli pracowałem w software housie, to było to możliwe, a jeśli nie, to po prostu zmieniałem pracę.

Zastanawiam się, na ile to jest temat pracodawcy, a na ile pracownika. Czy sądzisz, że pracodawca też powinien o tym myśleć i jest to jego ważne zadanie, czy raczej to pracownik powinien mieć z tyłu głowy, że jeżeli czuje, że coś jest nie tak, to powinien to zgłaszać? Jak to wygląda z Twojej perspektywy?

Myślę, że jak najbardziej jest to temat również dla pracodawcy i że może on podjąć realne kroki, żeby zapobiegać wypaleniu pracownika. Przede wszystkim nie zlecać nadgodzin, żeby nie doprowadzać do tego, że pracownicy są przemęczeni i przepracowani. Z drugiej strony warto też zadbać o jakieś aktywności pracowników niezwiązane z pracą: być może benefity typu MultiSport albo integracja zespołowa.

 

To może poruszę teraz temat zdrowia. Czy uważasz, że jeśli chodzi o aspekt zdrowotny praca programisty może być dla kogoś nie najlepszym rozwiązaniem?

Myślę, że raczej nie. To znaczy ja nie znam takiego przypadku, żeby ktoś musiał zrezygnować z tej branży albo nie wchodził w tę branżę ze względów zdrowotnych. Nawet słyszałem o osobach, które z bardzo kiepskim wzrokiem świetnie radziły sobie w programowaniu.

Myślę, że możemy zrobić kilka rzeczy, żeby zadbać o swoje zdrowie, gdy pracujemy jako programista. Na wstępie zaznaczam, że nie jestem lekarzem, więc jeśli ktoś potrzebuje profesjonalnej porady, to powinien się skonsultować z lekarzem albo z fizjoterapeutą. Ale jeśli chodzi o mnie, to robię parę rzeczy, żeby m.in. zapobiegać napięciom mięśni czy bólom pleców, karku.

Przede wszystkim taka najprostsza rzecz to krótka aktywność w ciągu przepracowanej godziny. Jeśli chodzi o zatrudnionych na umowę o pracę, to prawnie mamy zapewnioną pięciominutową przerwę w ciągu godziny pracy. Jeśli pracujemy przy biurku, warto z tego korzystać – warto wstać, popatrzeć przez okno, dać odpocząć mięśniom, oczom, warto się trochę poruszać, przejść się po kawę

Po pracy też warto zadbać o jakąś aktywność, pójść chociażby na spacer albo pobiegać, pojeździć na rowerze, pójść na basen. Staram się również regularnie rozciągać, szczególnie mięśnie karku, bo to mi akurat ostatnio doskwiera, ale też mięśnie pleców. Jeśli ktoś jest rodzicem kilkuletnich dzieci, to myślę, że to jest świetna forma na jakąś dodatkową aktywność.

Tak jest, potwierdzam w stu procentach. A co myślisz o bieżni przy biurku, przy komputerze i podczas kodowania? Nie wiem, czy sam miałeś okazję spróbować, ale może masz znajomych, którzy z czegoś takiego korzystają?

Słyszałem o tym. Kiedyś czytałem artykuł: że programista zainstalował sobie taki… może nie bieżnię, ale chodzik i przechodził tam 6 km czy mil w ciągu dnia pracy. Sam nie testowałem tego rozwiązania, więc nie jestem w stanie się wypowiedzieć. Natomiast w poznańskim biurze Allegro w jednym z pomieszczeń mamy taki rower przy biurku – i to akurat fajnie zdaje egzamin. Przy takich luźniejszych zadaniach, kiedy muszę się skupić np. na kodzie, to ciężko jest pedałować, ale kiedy mam na przykład spotkanie czy coś do przeczytania, to jest idealne połączenie.

Powiem przy okazji, dlaczego w ogóle rozmawiamy o zdrowiu. Możliwe, że niewiele osób ma tego świadomość, ale jak to mówią: w zdrowym ciele zdrowy duch. Jeśli będziemy dbać o kondycję fizyczną, to będziemy też bardziej sprawni umysłowo, co przełoży się na lepszy kod i szybsze znajdowanie rozwiązań. Pewnie również nie będziemy się tak szybko męczyć. Powinniśmy więc o to zadbać. Chyba dużo osób o tym zapomina, prawda?

Myślę, że tak. Szczególnie młodzi, zmotywowani programiści mają tendencję do tego, żeby siedzieć nad kodem przez kilka godzin bez przerwy. Myślę, że zadbanie o zdrowie jest bardzo ważne, bo kiedy lepiej się czujemy, to mamy więcej motywacji do pracy i lepiej pracujemy.

Może też dodam od siebie, że ta praca ponad osiem godzin, o których wspomniałeś, może powodować, że faktycznie w parę dni zrobimy dużo więcej, ale możliwe, że za jakiś czas dopadnie nas choroba i będziemy wyłączeni na tydzień. Pytanie więc: czy warto poświęcić te parę dodatkowych godzin tylko po to, żeby potem na tydzień wypaść z obiegu? Jeżeli mielibyśmy to kalkulować, to zazwyczaj się to nie opłaca.

Spójrzmy też na to w ten sposób: lepiej na spokojnie, ale w jednym tempie robić wszystko, niż na szybko w jeden tydzień, a w drugim nie zrobić nic, bo zachorujemy i nie będziemy w stanie pracować, myśleć, czy skupić się na kodzie.

 

Wróćmy może do Twojego doświadczenia, czyli tych sześciu przepracowanych lat. Jak zmieniła się Twoja perspektywa na branżę IT? Jak postrzegałeś ją na samym początku, a jak ją odbierasz teraz?

Na początku pracowałem w software housie, więc byłem skupiony na tym, żeby dowieźć projekt – żeby go zakodzić jak najlepiej, jak najszybciej. Bardziej skupiałem się więc na kodzie. Myślałem, że branża IT polega na tym, żeby programować. Teraz widzę, że tego kodu nie tworzymy po to, żeby sobie programować, ale programujemy go dla użytkowników, dla ludzi, którym chcemy ułatwić życie albo pracę. I to tak naprawdę powinno być w centrum działań danej firmy – to, żeby przynieść jakąś korzyść ludziom, a nie żeby programować dla samego programowania czy dla pieniędzy.

A to nie jest trochę też tak, że to mocno zależy od firmy, od tego, w jaki sposób do tego podchodzi przełożony albo zespół zarządzający firmą? Pewnie w zależności od ich podejścia Twoja perspektywa też trochę inaczej wygląda.

Myślę, że z jednej strony tak, ale z drugiej strony są też rzeczy, które my możemy robić, żeby dbać o doświadczenia użytkownika albo żeby wywierać jakiś wpływ na zespół, na przełożonego, na to, w jaki sposób oni podchodzą do wytwarzania oprogramowania.

Czyli nie dać się temu, powiedzmy, złemu podejściu. Jeżeli faktycznie takie występuje w firmie, to starać się je zmienić. A jeżeli to się nie udaje, to pewnie trzeba zmienić firmę. Tak to można byłoby skwitować, brzydko mówiąc.

Prawdopodobnie tak.

Delikatnie, dyplomatycznie „prawdopodobnie”. No dobrze, to już w zasadzie końcówka moich pytań do Ciebie.

 

To tak na koniec. Czy jesteś w stanie polecić jakąś książkę osobie, która chce rozwijać się nie tylko jako programista, ale też wartościowy członek zespołu?

Nie wiem, czy poleciłbym jakąś książkę w tym temacie. Żadna mi nie przychodzi do głowy. Uważam natomiast, że najbardziej wartościowi członkowie zespołu dzielą się wiedzą zarówno merytoryczną, twardą, jak i miękką, domenową. Myślę więc, że trzeba słuchać bardziej doświadczonych ludzi z branży i również samemu rozwijać się w różnych aspektach.

 

No dobrze, Marku, to w takim razie na koniec powiedz nam, proszę, gdzie możemy Cię znaleźć w sieci. Może ktoś będzie chciał zapytać Ciebie, jako doświadczoną osobę, jak coś zrobić lepiej. Gdzie najlepiej Cię pytać?

Myślę, że najprościej znaleźć mnie na LinkedInie, ale można też zajrzeć na mój blog: blog.szkudelski.dev. Tam znajdziecie wszystkie kontakty do mnie: maila i linki do social mediów.

 

To w takim razie ja mogę tylko polecić ludziom, żeby się z Tobą kontaktowali, a Tobie dziękuję bardzo za tę rozmowę i podzielenie się swoimi doświadczeniami.

Dzięki bardzo.

Słuchaj także na:

Udostępnij ten artykuł:

Mentoring to efektywna nauka pod okiem doświadczonej osoby, która:

  • przekazuje Ci swoją wiedzę i nadzoruje Twoje postępy w zdobywaniu umiejętności,
  • uczy Cię dobrych praktyk i wyłapuje złe nawyki,
  • wspiera Twój rozwój i zwiększa zaangażowanie w naukę.

Mam coś dla Ciebie!

W każdy piątek rozsyłam motywujący do nauki programowania newsletter!

Dodatkowo od razu otrzymasz ode mnie e-book o wartości 39 zł. To ponad 40 stron konkretów o nauce programowania i pracy w IT.

PS Zazwyczaj wysyłam 1-2 wiadomości na tydzień. Nikomu nie będę udostępniał Twojego adresu e-mail.