Transkrypcja
Dziś moim gościem jest Paweł Truszkowski. Paweł opowie nam o płatnym stażu w roli Python Developera. Pawle, dziękuję, że przyjąłeś moje zaproszenie na rozmowę!
Cześć wszystkim, cześć Mateusz! Bardzo dziękuję za zaproszenie do podcastu.
Nie ma sprawy! Powiedz nam proszę coś więcej o sobie, czym zajmujesz się na co dzień i co łączy Cię z branżą IT, a potem przejdziemy do głównych tematów naszej dzisiejszej rozmowy.
Pochodzę z okolic Wrocławia i na co dzień pracuję jako inżynier w dziale utrzymania ruchu w dużej korporacji pod Wrocławiem. Jest to dział techniczny, w którym moim głównym zadaniem jest diagnozowanie awarii maszyn oraz zapobieganie im w przyszłości. Moje pierwsze zetknięcie z programowaniem miało miejsce na studiach. Studiowałem telekomunikację na Wydziale Elektroniki Politechniki Wrocławskiej i tam około 2015 roku, na pierwszym i drugim semestrze, miałem styczność z językiem C++ oraz programowaniem obiektowym. Później programowanie odpuściłem, ponieważ musiałem skupić się na nauce kolejnych przedmiotów wymaganych na studiach. Po studiach, pracując już na etacie, pomyślałem, że spróbuję wrócić do programowania. Zacząłem czytać, szukać informacji i powoli uczyć się PHP z losowych tutoriali. To było na przełomie 2022 i 2023 roku. Spędziłem nad tym jakieś trzy lub cztery miesiące, robiąc proste aplikacje, ale nauka odbywała się bez jasnego planu. W pewnym momencie chciałem dostać się na staż w formie akademii organizowanej przez wrocławski software house, ale po wysłaniu aplikacji nikt się nie odezwał. Z dzisiejszej perspektywy wiem, że moja wiedza była wtedy po prostu niewystarczająca.
Mimo zniechęcenia, wciąż ciągnęło mnie do kodowania. Chciałem po prostu opanować nową umiejętność, dokładnie tak, jak ktoś postanawia nauczyć się nowego języka obcego. Po kolejnej przerwie postanowiłem spróbować Pythona. Kupiłem książkę do podstaw, zacząłem ją przerabiać i ten język spodobał mi się na tyle, że zostałem z nim na dłużej. Obecnie uczę się głównie backendu. Jestem świeżo po półrocznym, indywidualnym kursie mentoringowym w DevMentorze, po którym mój mentor Piotr zaproponował mi płatny staż.
Warto dodać, że przebranżawiam się w biegu. Nadal pracuję na pełny etat, mam rodzinę i małe dziecko w domu, więc nie jestem osobą, która mogła rzucić pracę i kodować po dziesięć godzin dziennie. W trakcie samej nauki udało mi się zbudować między innymi produkcyjny system rezerwacji dla salonu urody, który wdrożyłem na serwerze od zera przy użyciu Django, DRF, Dockera, Nginxa, SSL, CI/CD oraz Celery, a także drugi projekt – Task Manager wystawiony na własnym VPS-ie.
Jakie Twoim zdaniem umiejętności są niezbędne, aby móc poradzić sobie na stażu w technologii Python?
Kluczowe są fundamenty samego języka, stojące ponad znajomością konkretnych frameworków. Na mentoringu skupiałem się głównie na Django i Django Rest Framework, natomiast na stażu wszedłem w projekt oparty o FastAPI. Dzięki temu, że dobrze opanowałem same podstawy Pythona, mogłem bez problemu i bardzo szybko wdrożyć się w zupełnie nowy framework.
Kolejną niezbędną umiejętnością jest czytanie cudzego kodu. W realnej pracy rzadko pisze się aplikacje od zera, najczęściej dołącza się do istniejącego projektu i trzeba potrafić sprawnie wejść w kod napisany przez kogoś innego, aby zrozumieć, co tam się dzieje.
Bardzo ważny jest też Git w wydaniu zespołowym, czyli dbanie o sensowną historię commitów, sprawne mergowanie branchy, rozwiązywanie konfliktów czy umiejętność przyjmowania uwag podczas code review. Nie można też zapominać o systematyczności, bo przy dwóch lub trzech godzinach dziennie regularność potrafi wygrać z talentem.
Większość z tych elementów dotyczy pracy w zespole. Przy samodzielnej nauce trudno o takie doświadczenia, chyba że bierze się udział w projektach open source. Staż pozwala wejść w ten proces bez obaw przed dotykaniem cudzego kodu. Czy na początku miałeś jakąś blokadę lub lęk, że coś zepsujesz?
Oczywiście, na samym początku pojawiały się obawy przed zepsuciem czegoś w projekcie. Rozmawiałem o tym z Piotrem podczas naszych rozmów i szybko rozwiał moje wątpliwości. Wyjaśnił mi, że będzie skrupulatnie sprawdzał mój kod przed jakimkolwiek wdrożeniem. Na tym właśnie polega rola opiekuna na stażu. Z jednej strony odpowiadasz za swoje zadania, ale z drugiej masz poczucie bezpieczeństwa, bo ktoś doświadczony stale kontroluje Twoje działania.
Jak bardzo różni się etap nauki od etapu pracy na stażu?
Staż to wciąż nauka, ale zmienia się jej charakter. Na kursie uczysz się liniowo, krok po kroku według ułożonej ścieżki. W projekcie komercyjnym dostajesz konkretne zadanie i jeśli czegoś nie wiesz, musisz od razu doedukować się z danego fragmentu dokumentacji, aby to zadanie zrealizować.
Przede wszystkim zadania na stażu mają realny cel biznesowy, a nie jedną poprawną odpowiedź. Na kursie zadanie jest zamknięte, a mentor zna rozwiązanie. W pracy dostajesz cel, na przykład działającą funkcjonalność, i sam musisz znaleźć właściwą drogę do jego realizacji, robiąc po drodze sporo rozpoznania i analizy.
Dodatkowo kod przestaje być tylko Twój. Na kursie piszesz głównie dla siebie i mentora, a w projekcie komercyjnym tworzysz kod, który będzie sprawdzany, utrzymywany i używany przez innych. To realnie zmienia sposób, w jaki myślisz o strukturze, nazewnictwie czy podziale funkcji. Zmienia się też presja – nie ma sztywnych narzuconych terminów, ale świadomość, że na końcu jest prawdziwy klient i działający produkt, motywuje o wiele mocniej niż ocena za zadanie.
Wspomniałeś, że staż ma charakter zadaniowy. Jak wygląda Twój typowy dzień pracy i łączenie go z etatem?
Łączenie stażu z pracą na etacie jest możliwe właśnie dzięki temu, że praca ma charakter zadaniowy, a nie wymaga sztywnych godzin spędzonych przed ekranem. Mentor rozpisuje dla mnie roadmapę oraz kolejne fazy projektu w GitHub Issues, a ja dzielę sobie pracę na bloki czasowe. Mój dzień zazwyczaj zaczyna się tuż po 5:00 rano. Wstaję wcześnie, gdy w domu jest jeszcze cisza, brak powiadomień i mam pełne skupienie. Siadam wtedy do projektu na około godzinę przed wyjściem do etatowej pracy. Po powrocie do domu spędzam czas z rodziną i synkiem, a kolejną godzinę na kodowanie wygospodarowuję wieczorem, kiedy syn już zaśpi, lub w ciągu dnia, jeśli mam wolną chwilę. Większe bloki czasowe nadrabiam w weekendy.
Sam przebieg pracy mocno mnie zaskoczył, bo nie polega on na ciągłym pisaniu kodu. Najwięcej czasu zajmuje czytanie – analizowanie istniejącego kodu, dokumentacji oraz robienie rozpoznania, jak chociażby testowanie możliwości różnych modeli AI do generowania wideo. Samych proporcji czytania i debugowania jest w praktyce znacznie więcej niż samego pisania nowych funkcji.
Projekt, nad którym pracujesz, dotyczy generowania wideo przy użyciu AI. Jak sam wykorzystujesz sztuczną inteligencję w codziennej pracy? Gdzie pomaga, a gdzie przeszkadza?
Wykorzystuję AI na co dzień i w dzisiejszych czasach trudno sobie wyobrazić inną pracę. Najbardziej pomaga mi przy tłumaczeniu cudzego kodu. Dostałem od Piotra fragmenty aplikacji w FastAPI, której wcześniej nie znałem. AI idealnie sprawdza się w roli asystenta, którego mogę zapytać o konkretną linijkę kodu i dostać natychmiastowe wyjaśnienie w moim tempie. Oszczędza to całe godziny szukania informacji w sieci. Pomaga też przy wchodzeniu w nowe technologie i pojęcia, choć każdą odpowiedź i tak na końcu weryfikuję w oficjalnej dokumentacji.
Gdy koduję sam o 5:00 rano, traktuję AI jako partnera do rozmowy. Pytam o to, jak rozwiązać dany problem i czy widzi w moim podejściu jakieś słabe punkty. Pomaga mi to również przy przeglądzie własnego kodu przed wystawieniem Pull Requesta – proszę o wytknięcie błędów, poprawiam je i dzięki temu Piotr ma mniej pracy na code review. Używam w tym celu narzędzia Claude w wersji Pro, gdzie korzystam z trybów planowania i nauki przez praktykę, co pozwala mi budować najpierw szkielet rozwiązania, a potem samemu pisać kluczowe funkcjonalności. AI potrafi jednak mocno zaszkodzić. Na początku stażu wygenerowałem fragment kodu, który działał idealnie, ale gdybym miał wytłumaczyć, dlaczego działa, nie umiałbym tego zrobić. Wtedy zapaliła mi się czerwona lampka. Zrozumiałem, że kod, którego się nie rozumie, stanie się ogromnym problemem w momencie, gdy przestanie działać, bo model nie będzie pamiętał, co wygenerował trzy tygodnie wcześniej. Generowanie kodu bez zrozumienia daje złudzenie postępu – aplikacja rośnie, ale nasze umiejętności stoją w miejscu. Dlatego stosuję zasadę: nie wystawiam Pull Requesta z kodem, którego nie umiałbym obronić. Traktuję AI jako narzędzie do rozumienia i nauki, a nie do bezmyślnego produkowania kodu.
Jakie są największe wyzwania podczas stażu i jak sobie z nimi radzisz?
Największym wyzwaniem jest zarządzanie czasem i energią. Łączenie etatu, rodziny i stażu wymaga dobrej organizacji, dlatego dzielę pracę na małe bloki, a większe zadania przekładam na weekendy. Dużym wyzwaniem jest też konieczność szybkiego wchodzenia w nowe technologie, z którymi wcześniej nie miałem do czynienia, oraz sprostanie wymaganiom biznesowym komercyjnego projektu.
A co z błędami, które możesz popełnić? Kto za nie odpowiada?
Formalnie za projekt odpowiada mentor i to on stanowi ostatnią linię obrony, ale moim celem jest pisanie kodu w taki sposób, aby miał przy review jak najmniej poprawek. Na stażu praca odbywa się na osobnej gałęzi, a każdy etap trafia do głównego kodu dopiero po akceptacji Pull Requesta przez mentora. W normalnej firmie stażysta czy junior po prostu nie ma dostępu do środowiska produkcyjnego, więc nie ma możliwości przypadkowego położenia aplikacji.
To też wyjaśnia, dlaczego firmy niechętnie przyjmują stażystów – weryfikacja kodu i opieka nad początkującym wymagają sporej ilości czasu doświadczonego programisty, co generuje dla organizacji realny koszt.
Jaką największą wartość widzisz w stażu, który odbywasz?
Największą wartością jest zdobycie autentycznego doświadczenia przy komercyjnym projekcie oraz sam proces code review. Doświadczony programista patrzy na mój kod i zwraca mi uwagę na błędy, które bez jego wsparcia popełniłbym za pół roku. Niezwykle cenna jest też nauka pracy w realnym procesie – praca z roadmapą, zadaniami na GitHubie, osobnymi branchami i Pull Requestami. Dzięki temu, wchodząc w przyszłości do nowej firmy, nie będę musiał uczyć się od zera samej organizacji pracy, a jedynie konkretnego kodu. To także ciągłe wychodzenie ze strefy komfortu, które daje mi poczucie stałego i szybkiego rozwoju.
Jaką jedną radę przekazałbyś sobie przed rozpoczęciem nauki programowania?
Moja główna rada to: buduj i wdrażaj projekty wcześniej, niż uznasz, że jesteś na to gotowy. Zbyt długo zbierałem wiedzę teoretyczną na zapas. Prawdziwy skok moich umiejętności nastąpił dopiero w momencie, gdy musiałem samemu wdrożyć własną aplikację na serwer, skonfigurować Dockera, Nginxa, SSL oraz CI/CD i zmierzyć się z problemami, o których nie mówi się na kursach. Moment, w którym poczujesz, że "jesteś już w pełni gotowy", może nigdy nie nadejść, bo zawsze znajdzie się kolejna rzecz do nauczenia. Trzeba po prostu zacząć budować.
Z drugiej strony nie należy przesadzać w drugą stronę i porywać się na ogromne projekty na samym początku nauki, bo łatwo się przytłoczyć i zniechęcić. Ważne jest znalezienie balansu dopasowanego do aktualnego etapu.
Jaki materiał polecisz osobie, która chciałaby dotrzeć do miejsca, w którym obecnie się znajdujesz?
Zdecydowanie polecam indywidualny mentoring jeden na jeden. Jest to największa dźwignia w nauce – nie po to, by ktoś czytał Ci teorię, ale po to, by wskazał właściwą drogę, zweryfikował kod i wytykał błędy, na których uczysz się najszybciej.
Polecam również wyrobienie nawyku czytania oficjalnej dokumentacji. To jedyne źródło wiedzy, które się nie dezaktualizuje i z którego i tak trzeba korzystać w codziennej pracy. Do codziennego ćwiczenia myślenia programistycznego warto wykorzystywać też platformy z zadaniami, takie jak HackerRank. Pozwalają one rozwinąć krytyczne myślenie i uczą, jak dzielić złożone problemy na czynniki pierwsze. Przy rozwiązywaniu takich zadań warto jednak próbować dochodzić do rozwiązań samodzielnie lub prosić AI jedynie o wskazanie pierwszego kroku, a nie o podanie gotowej odpowiedzi.
Gdzie możemy Cię znaleźć w sieci?
Najłatwiej znaleźć mnie na LinkedInie pod imieniem i nazwiskiem Paweł Truszkowski. Zapraszam do kontaktu, chętnie porozmawiam i odpowiem na pytania. Jestem też dostępny na Facebooku oraz na GitHubie, gdzie można przejrzeć moje portfolio. Wszystkie odnośniki będą dostępne w opisie odcinka.
Pawle, bardzo Ci dziękuję za rozmowę i podzielenie się swoimi doświadczeniami!
Super, bardzo dziękuję za rozmowę i zaproszenie! Trzymaj się, hej!
