devdebata

O czym w kontekście pracy Python Developera mówi się zdecydowanie za mało? Devdebata

Jak zmieniła się rekrutacja na Python Developera na przestrzeni lat? Jakie są ścieżki rozwoju? O czym w kontekście pracy Python Developera mówi się za mało? Na te i na wiele innych pytań odpowiedzi znajdziecie w tym tekście.

W devdebacie udział wzięli:

  • Michał Korzeniowski. Engineering Manager z wykształceniem technicznym i ponad 10-letnim stażem w IT. Doświadczenie zdobywał w wielu branżach, między innymi ecommerce, fintech, gamedev, telco, marketing i security. Dostarczyło mu to holistycznego spojrzenia na różnorodność rozwiązań zarówno od strony architektury, jak i procesu wytwarzania oprogramowania. Obecnie trzyma pieczę nad projektami w Ulam Labs oraz mentoruje młodym i zdolnym rozpoczynającym tam swoją karierę.
  • Mateusz Tomczyk. Python Developer w Ulam Labs. W programowaniu zakochał się jeszcze jako dzieciak, głównie tworząc modyfikacje do gier komputerowych. W zawodzie od 10 lat. Zaczynał od dużej korporacji i Javy, jednak dość szybko postanowił pójść w kierunku rozwiązań opartych o Pythona. Obecnie gustuje w mniejszych firmach. Przez większość czasu pracował przy tworzeniu aplikacji biznesowych jako fullstack developer, łącząc Pythona z różnymi technologiami frontendowymi. Traktuje programowanie również jako hobby i realizuje prywatne projekty, ciągle poszerzając swoją wiedzę. Codzienność jego pracy to ciągłe rozwiązywanie problemów, projektowanie nowych funkcjonalności i wspieranie zespołu.
  • Marcin Wronecki. Python Developer w Ulam Labs. Pracę jako programista zaczął już w ostatniej klasie szkoły średniej (Visual Basic/.NET.). Doświadczenie Pythonowca zdobywał zarówno jako freelancer w firme outsouringowej dla banków, jak i w organizacji z sektora finansowego. Aktualnie jest w projekcie, który pasuje do jego wartości i rozwija aplikację, która ma służyć zmniejszeniu czasu personelu medycznego na rzeczy mniej istotne typu brak płynu w dyspozytorze. Dzięki aplikacji medycy mogą więcej czasu poświęcić pacjentom.

Jak zmieniła się rekrutacja na Python Developera na przestrzeni lat? Czy wymagania uległy zmianie?

Michał Korzeniowski:

Oczekiwania w stosunku do kandydatów zmieniają się wraz z rozwojem technologii towarzyszących danemu stanowisku. Naturalne jest to, że obecnie wymagania są trochę inne niż 10 lat temu: wielu dziś już standardowych rozwiązań wcześniej po prostu nie było. Mimo tego, najbardziej nieoczekiwana i zaskakująca zmiana nie jest nawet uzasadniona rozwojem technologicznym. Jest nią wymaganie dość dobrej znajomości języka angielskiego. Kiedyś wystarczyło jedynie pasywne obycie, pozwalające na rozumienie dokumentacji technicznej. Jednak postępująca globalizacja rynku IT sprawiła, że bardzo często pracuje się dla zagranicznych klientów. Dlatego język obcy, a w szczególności angielski, okazuje się niezbędny. Inne rozszerzenia wachlarza oczekiwanych kompetencji są już stricte związane z rozwojem świata IT – znajomość zwinnych metodologii wytwarzania oprogramowania czy sposobów konteneryzacji, wymieniając tylko dwie.

Mateusz TomczykMateusz Tomczyk:

Myślę, że zmiany, które zaszły w rekrutacjach w ostatnich latach nie są specyficzne dla Pythona, ale dotyczą całej branży IT. Na pewno wymagania w stosunku do kandydatów wzrosły. Jeszcze 5-10 lat temu osobie rozpoczynającej swoją przygodę z programowaniem o wiele łatwiej było znaleźć zatrudnienie. Często wystarczyło ukończyć bootcamp z danej technologii, żeby bez trudu znaleźć w niej pracę. Dziś jest inaczej. Juniorów chcących wejść na rynek pracy wciąż jest mnóstwo, ale firmy szukają raczej specjalistów z doświadczeniem. Można powiedzieć, że rynek powoli się zamyka na nową krew. Czy ten trend się utrzyma, tego nie wiem.

Marcin WroneckiMarcin Wronecki:

Sam nie rekrutowałem innych, a z punktu widzenia osoby poszukującej pracy to też trudno powiedzieć obiektywnie, co zmieniło się przez lata. Myślę, że z czasem wybierałem lepsze firmy, więc nie wiem, czy to sama rekrutacja na przestrzeni lat się zmieniła, czy to ja trafiałem na inne (lepsze?) metody w procesie rekrutacji. Jednak pamiętam, że na początku kariery dostawałem pytania, które obecnie wydają mi się tylko zwykłą “pamięciówką” – nie sprawdzały umiejętności programowania, a wiedzę o języku. Na kolejnych rekrutacjach zaczęto przywiązywać większą uwagę do portfolio, a także wysyłać zadania. Dzięki temu sprawdzane jest to, jak ktoś potrafi oszacować czas swojej pracy, w jaki sposób przedstawi rozwiązanie, a jeżeli załączy link do githuba, to można dodatkowo sprawdzić, jak komentuje commity. Nawet jeśli nie uda mu się w pełni rozwiązać zadania, to można zobaczyć, na ile sobie z nim poradził oraz czy braki, które ma, są łatwe do uzupełnienia.

Jakie umiejętności, które zdobyliście samodzielnie, przydały wam się w karierze zawodowej?

Michał Korzeniowski:

Posiadanie zainteresowań dookoła świata IT jest według mnie kluczowe w rozwoju osobistym oraz zawodowym. Projekty często wiążą nas z konkretną technologią; te większe w dodatku mają tendencję dążenia do zachowania status quo za wszelką cenę. Doświadczenia wyniesione z własnej eksploracji nowych, ciekawych rozwiązań często są kluczem do wprowadzenia czegoś ciekawego do skamieniałych projektów, tchnięcia w nich odrobiny życia. Mając doświadczenie z pierwszej ręki w danych rozwiązaniach technologicznych, często możliwe jest przekonanie decydentów danego projektu do wykorzystania tych rozwiązań przy planowaniu nowych elementów systemu czy usprawniania starych.

Mateusz Tomczyk:

Jeżeli chce się być naprawdę dobrym w jakimś rzemiośle, to trzeba poświęcić na nie trochę swojego czasu. Monotonna praca po 8 godzin dziennie nie sprzyja chęci do samorozwoju. W pracy często nie ma czasu na eksperymentowanie z nowymi podejściami, technologiami. Dla mnie wybawieniem z tej rutyny są własne projekty, które od czasu do czasu realizuję w wolnym czasie. Nie są to poważne projekty, raczej małe rzeczy, przy których świetnie się bawię przez jakiś czas, wybucham uśpioną kreatywnością, przy okazji ucząc się nowych rzeczy, a potem zostawiam i wracam do swojej rutyny na kolejne długie miesiące. Z prawie każdego takiego projektu wyciągam coś, co potem przydaje mi się w pracy zawodowej. Warunek takiego podejścia jest jeden – trzeba programowanie po prostu lubić.

Marcin Wronecki:

Postawiłbym na debugowanie oraz pracę zdalną. Co do pierwszego, to na studiach nie nauczono mnie praktycznie niczego w tej kwestii, a jest to jednak umiejętność potrzebna w codziennej pracy. Wiele osób ogranicza się też do nauki samych podstaw, co skutkuje wydłużonym czasem znalezienia błędu, a w przypadkach krytycznych jest to szalenie ważne.
Jeśli chodzi natomiast o pracę zdalną, to nigdy za nią nie przepadałem – jestem osobą, która lubi pracować w biurze. Niemniej jednak, pracując jako freelancer, wypracowałem w sobie pewne zwyczaje, które pomagają mi teraz, gdy z jakichś powodów jestem zmuszony do pracy zdalnej. 

Jakie ścieżki rozwoju ma Python Developer?

Michał Korzeniowski:

Jeżeli założymy, że wybór Python Developera był dla danej osoby trafiony, czyli że sprawdza się w tej roli, i że sprawia to jej przyjemność, to wówczas można przyjąć, że stoją przed taką osobą dwie główne ścieżki rozwoju. Z jednej strony mamy drogę bardzo silnie techniczną, idącą przez senior developera w kierunku różnego rodzaju architektów systemów, a z drugiej mamy stanowiska liderskie idące w kierunku menedżerskim. Oba kierunki kariery wymagają bardzo dużego doświadczenia, jednak elementarne wymagane kompetencje są różne. Zarządzanie ludźmi wymaga pewnego opanowania umiejętności tzw. miękkich, które nie zawsze idą w parze z umysłami ścisłymi, zaś od architektów wymaga się kompleksowej wiedzy ze wszystkich obecnie stosowanych rozwiązań. Niezależnie od obranego kierunku rozwoju dobrze jest pamiętać, że konieczne jest również rozwinięcie zdolności komunikacyjnych, zanim stanie się to przeszkodą na dalszej ścieżce kariery.

Mateusz Tomczyk:

Na to pytanie można odpowiedzieć dwojako. Jeżeli traktujemy ścieżki rozwoju jako „drabinkę awansów”, to Python Developer niczym się nie różni od np. Java Developera. Zaczynamy od juniora, stopniowo w kolejnych latach nasze doświadczenie rośnie, a razem z nim nasza odpowiedzialność w zespole. Jeżeli jesteśmy dobrzy, to zostajemy liderem zespołu. Z czasem jest coraz mniej programowania, a coraz więcej zarządzania. Typowy schemat w IT.

Druga wersja odpowiedzi brzmi tak: Python jest bardzo uniwersalnym językiem programowania. Najłatwiej jest w nim znaleźć pracę w branży webdevu, ale silniejszą pozycję ma w branży data science czy uczenia maszynowego. Dzięki temu Python Developer ma dość szeroki zakres możliwości, jeśli chodzi o wybór ścieżki zawodowej.

Marcin Wronecki:

Jest ich bardzo wiele i nie ma znaczenia, czy chcesz pracować nad danymi czy projektować aplikacje, zawsze znajdą się projekty, dla których Python jest odpowiedni. Python jest wspaniały pod tym względem, że bardzo szybko adaptuje się do nowych trendów, co widać świetnie na przykładzie AI. Dzięki temu, że jest prosty, czyni wiele rzeczy szybkimi do implementacji i nie komplikuje tego.  

Jakie dodatkowe kompetencje pomagają w branży IT?

Michał Korzeniowski:

Odwrócę to pytanie i zapytam: jakich kompetencji najczęściej brakuje w branży IT? Najbardziej dotkliwie odczuwane są braki w umiejętnościach komunikacyjnych oraz… cierpliwości. Częstą barierą jest duży problem w przekazywaniu i obrazowaniu problemów i zagadnień. Żeby efektywnie wytłumaczyć jakieś zagadnienie drugiej osobie, trzeba umieć postawić się na jej miejscu. Potrafić odgadnąć jaki mniej więcej jest stan wiedzy tej osoby i na tej podstawie skroić przekaz na miarę. Niestety, ludzie z branży IT najczęściej zakładają, że rozmówca wie przynajmniej tyle, co oni sami, co często prowadzi do licznych problemów komunikacyjnych.
Drugim elementem, którego często bardzo brakuje jest cierpliwość. Każdy by chciał zawsze pracować w najnowszych technologiach, z nieskazitelnie napisanym kodem, mieć idealną specyfikację zadań, które ma wykonać, ponadprzeciętnie kompetentnych współpracowników, przełożonych, klientów i czasu tyle, ile tylko chce. Niestety, rzeczywistość najczęściej przybiera bardziej pesymistyczne barwy, dlatego też pewna doza cierpliwości jest na wagę złota.

Mateusz Tomczyk:

Praca w IT to praca zespołowa i szeroko pojęte umiejętności miękkie to rzecz, o której zawsze mówi się za mało. Podstawą jest dobra komunikacja. Osoba, która świetnie dogada się z klientem często jest bardziej wartościowa dla zespołu niż zamknięty w swoim świecie geniusz programistyczny. Byłem w swojej karierze świadkiem niejednego zwolnienia pracownika i prawie zawsze powodem były problemy natury „miękkiej”, jak np. brak umiejętności pracy w zespole. Braki techniczne z reguły łatwo jest uzupełnić, kwestie „miękkie” w dużej mierze wynikają z naszych cech osobowości i są o wiele trudniejsze do zmiany.

Inną ważną cechą jest umiejętność rozwiązywania problemów. Swoją pracę lubię traktować jak serię problemów lub nawet łamigłówek do rozwiązania. Każdego dnia mam do rozwiązania nowe problemy i nowe łamigłówki. Gdy znajdę już rozwiązanie, to implementacja jest z reguły prosta, mechaniczna i nieabsorbująca. Osoby, które rozkładają ręce, gdy napotykają na problemy, będą miały spore trudności z wejściem w świat programowania.

Marcin Wronecki:

Jest ich kilka: umiejętność współpracy, zrozumienia i zauważania potrzeb innych osób w swoim zespole. Nikt z nas nie wie wszystkiego – i właśnie po to tworzymy zespoły, aby uzupełniać się wiedzą i doświadczeniem. Zdecydowanie pomocnym jest też zrozumienie potrzeb klienta oraz otwarta konwersacja z nim. Warto otwarcie mówić i wymieniać się wiedzą, ponieważ czasami klient może czegoś nie zauważyć, może nie być osobą techniczną, albo może to my po prostu mamy złe doświadczenie z danym rozwiązaniem. 

ZOBACZ TEŻ: Python ma już 30 lat! Od czego wszystko się zaczęło?

Co może zaskoczyć osoby pierwszy raz wchodzące w świat produkcyjnego tworzenia oprogramowania?

Michał Korzeniowski:

Myślę, że możemy tu wyróżnić 3 najczęściej spotykane elementy. Pierwszym jest zderzenie się z istniejącą infrastrukturą, kodem i metodologią panującą w projekcie, do którego się dołącza. W przypadku bardzo dużych projektów odczucie może być porównywalne do zderzenia się z pędzącą ciężarówką, dlatego dobrze jest trafić do firmy z życzliwymi współpracownikami, którzy pomogą w tym najtrudniejszym czasie. Drugim takim elementem jest odkrycie, jak mało się wie w stosunku do swojego wyobrażenie o swojej wiedzy. A trzecim jest to, do czego już trochę nawiązałem w poprzednim pytaniu – często jako junior trafia się do dość prostych, ale żmudnych i mało interesujących zadań, w których wpierw trzeba się wykazać, żeby udowodnić swoje umiejętności i wartość.

Mateusz Tomczyk:

Większość osób zaczynających pracę spodziewa się dostać listę zadań z jasno określonymi wymaganiami. Niestety, problem numer jeden w większości projektów to nieprecyzyjne, ciągle zmieniające się wymagania i niezdecydowanie klientów. Stąd popularność metodologii Agile w zarządzaniu projektami, która pozwala w pewnym zakresie adaptować się do ciągle zmieniających się warunków.

Zaskakująca dla niektórych może być też  ilość interakcji z innymi ludźmi, częściej będą widzieli twarze innych ludzi niż kod, choć dziś, w czasach pracy zdalnej to się zmienia. Kolejną rzeczą są projekty rozwijane od długiego czasu przez wiele osób, często pracujących przy nich “z doskoku”. Jakość kodu w takich projektach potrafi zaskoczyć każdego 🙂 I ostatnia rzecz: 40 godzin pracy w tygodniu to nie to samo, co szkoła, czy studia. Będziecie zmęczeni.

Marcin Wronecki:

Zaskakującym może być fakt, że nasze estymacje przez pierwszych kilka lat będą nierealne. Nie zawsze da się wszystko dobrze oszacować, ponieważ tworzenie oprogramowania jest bardzo rozbudowaną kwestią i na wielu warstwach potrafią pojawić się problemy, które ciężko przewidzieć lub nie da się ich przewidzieć na etapie estymacji. Dla mnie najczęściej takim elementem wydłużającym pracę są problemy związane z firmami zewnętrznymi. Przykład? Integracja z serwisem zewnętrznym – patrzysz na dokumentację API, wygląda dobrze, więc dajesz swoją estymację. Bierzesz się za zadanie i nagle okazuje się, że dokumentacja API jest nieaktualna, a kontakt z podmiotem jest utrudniony. 


Zdjęcie główne pochodzi z unsplash.com.

Zapraszamy do dyskusji

Patronujemy

 
 
More Stories
Command Query Responsibility Segregation
Command Query Responsibility Segregation — pierwsze kroki