Mało mówi się o projektowaniu kariery. Wywiad z Pawłem Plutą

– Przychodzi moment zmiany pracy i uczymy się pod daną ofertę. Ma to swój sens, ale nie nazwałbym tego projektowaniem kariery. W taki sposób swoją karierę powierzamy przypadkowi – powiedział nam Paweł Pluta, Senior System Software Engineer w IGT.

Opowiedz o pierwszej pracy w IT. Jak ją znalazłeś i czego nauczyłeś się w niej?

Zaraz po studiach, w wakacje, przed obroną pracy magisterskiej zacząłem przeglądać różne oferty. Z początku nie wiedziałem, że zostanę programistą. Mimo pokrewnego wykształcenia – elektronika i telekomunikacja, znajdowałem różne oferty. Byłem łącznie na czterech rekrutacjach: w dwóchkorporacjach, średniej firmie i małym software housie. Tam rozmowa poszła mi najlepiej, atmosfera bardzo mi się spodobała, kolejnego dnia otrzymałem ofertę pracy. Po kilku tygodniach rozpocząłem pracę.

Czas między rekrutacją, a startem starałem się wykorzystać na pogłębienie wiedzy technicznej. Mimo że proces rekrutacyjny przebiegł pozytywnie, nie ceniłem wysoko swoich skromnych umiejętności programowania. Mimo przeczytania kilku książek, prób pisania różnych aplikacji pierwsze dni w nowym miejscu były szokiem. Tego kodu było tak dużo!

Firma, do której trafiłem, to kilkuosobowy software house zajmujący się utrzymaniem i rozwojem aplikacji dla klientów niemieckojęzycznych. Sama aplikacja nie była czymś niezwykłym, nie o to chodziło w tamtym czasie. Ważne było rozwijanie umiejętności technicznych każdego dnia. Konsekwentnie, zadanie po zadaniu, starałem się iść do przodu. Zdarzało mi się zabierać laptopa po pracy do domu i wieczorami jeszcze trochę popatrzeć w kod. Mimo że nikt ode mnie tego nie wymagał, uważam, że były to dobre decyzje.

Z technicznego punktu widzenia, moje umiejętności, a raczej ich brak ewoluowały w kierunku osoby, która umiała swobodnie poruszać się po kodzie, wiedziała jak rozwiązywać problemy, jakiego kodu nie pisać, co mogą przynieść błędne decyzje. Gdybym miał wskazać tylko jedną rzecz, która później okazała się bardzo pomocna, a której nauczyłem się w pierwszej pracy to używanie debuggera. Nie takie proste ustawianie breakpointów, ale korzystanie w pełni z tego narzędzia.

Z perspektywy czasu uważasz, że to był dobry wybór? Najlepiej pracę w IT zacząć od software house’u?

Mając wybór myślę, że warto zdecydować się na software house. Często jednak sytuacja z pierwszą pracą wygląda tak, że trzeba brać co jest, nie ma co wybrzydzać. Software house czy korporacja, dla osoby stawiającej pierwsze kroki w nowej branży nie będzie to miało wielkiego znaczenia. Jestem na bieżąco z rynkiem i widzę, że wymagania stawiane juniorom są coraz wyższe. Osobiście cieszę się, że trafiłem do takiej firmy, a nie innej, sporo było w tym przypadku.

Co wpłynęło na to, że postanowiłeś zmienić miejsce pracy? Ten sam powód przyniósł kolejne zmiany pracy?

W pewnym momencie poczułem, że nie rozwijam się. Zacząłem szukać zmiany i trafiłem do dość dużej korporacji, ale niestety zawiodłem się. Trzy miesiące w jednym projekcie, trzy w drugim, później czas dzielony między dwa projekty. Dużo zamieszania, mało efektywnej pracy. Mimo wspomnianych wad nie żałuję zmiany. Doświadczenie to wskazało mi na co zwracać uwagę w trakcie kolejnych rekrutacji. Można powiedzieć, że byłem bardziej świadomy podczas kolejnych zmian miejsca pracy. To jedna z takich lekcji, z których korzystam do dzisiaj.

Od 2017 roku jesteś Mentorem w szkołach programowania. Skąd Twoje zainteresowanie dzieleniem się wiedzą?

Ucząc innych można samemu bardzo dużo się nauczyć. Idąc tą drogą myślałem o pisaniu bloga, udzielaniu się w społeczności. Jest to łatwe tylko w słowach, konkretne podejście do tematu i działanie jest dużo bardziej złożone. Swoją przygodę z dzieleniem się wiedzą rozpocząłem od nagrania kursu wideo. Z perspektywy czasu wiem, że teraz zrobiłbym to inaczej.

Przez pierwsze pół roku kursu prowadziłem stacjonarnie. Na początku był spory stres, podobno było widać. Nigdy wcześniej nie występowałem publicznie. Bardzo pozytywne oceny, które otrzymałem do pierwszej edycji zmotywowały mnie do dalszego działania. Przygotowywałem się coraz lepiej do kolejnych zadań. Nadszedł moment, w którym dojazdy stały się męczące – pracę kończyłem o 17, o 17:30 kurs w innym miejscu. Logistycznie było to trudne do zrobienia. Zaaplikowałem do firmy zajmującej się szkoleniami online, rekrutacja przebiegła szybko i od tamtego czasu (ponad 4 lata) jestem Mentorem online.

Same rozmowy z Kursantami, robienie review kodu, sprawdzenie zadań i bieżąca komunikacja mi nie wystarczyły. Zostałem też autorem kilku materiałów, z których przyszli programiści i testerzy czerpią wiedzę.

Jakimi zasadami kierujesz się jako Mentor?

Swoją uwagę dzielę po równo, nie ważne czy ktoś ma predyspozycje, czy musi poświęcać znacząco więcej czasu na naukę, ode mnie każdy dostaje tyle samo. Swoje obowiązki staram się wykonywać sumiennie. Nie mogę sobie pozwolić nawet na jeden dzień na nie sprawdzanie zadań czy nie odpisywanie. Doskonale wiem, że ktoś po tej drugiej stronie czeka na moją wskazówkę. Nie oznacza to, że nie mam dni wolnych, urlop mam jak w każdej innej pracy.

Oferty pracy z

Z jakimi problemami/wyzwaniami spotykasz się na co dzień jako Mentor?

Osoby, z którymi pracuję często nie mają żadnego doświadczenia z programowaniem. Staram się wytłumaczyć całą ideę np. programowania obiektowego, jak i najdrobniejsze szczegóły. Początki w tej branży są istotne. Nabranie złych praktyk czy niewłaściwe zrozumienie poszczególnych zagadnień może mieć duży wpływ na dalsze losy nauki.

Kursy, które prowadzę, trwają nawet 9 miesięcy, to dużo czasu. Często spotykam się ze spadkiem zaangażowania czy zmęczeniem u Kursantów. Staram się ich odpowiednio motywować, przypomnieć czemu zdecydowali się na kurs. Czasem kilka minut zwykłej, luźnej rozmowy zamiast omawiania tematów technicznych wystarczy.

Innym wyzwaniem jest brak czasu u Kursanta – to sytuacja, w której ciężko coś poradzić. Z mojej strony mogę takiej osobie zaoferować elastyczne godziny spotkań wideo – nie są mi obce rozmowy o 7 rano czy 22, a nawet 23. Staram się przekazać wskazówki, jak zastosować pewną rutynę – mając wolną tylko jedną godzinę w ciągu dnia, można nauczyć się czegoś ciekawego i pożytecznego. Warto wyrobić sobie pewne nawyki zamiast marnować czas.

Co mogłoby przyspieszyć Twoją pracę, dzielenie się wiedzą?

Myślę, że dłuższa doba bardzo by mi pomogła, a tak poważnie, ciężko dzielić wiedzę szybciej. Widzę u siebie pewne rzeczy do poprawy: czasem nie mogę się zabrać, by coś napisać/opublikować. Z mojej perspektywy, aby utworzyć np. bloga, trzeba poświęcić sporo czasu, by wyglądało to tak, jak chcę. Mówi się, że to tylko kilka kliknięć. Tak, jeśli zgadzamy się na standardowy wygląd, podobny do tysiąca innych powstających w danym momencie blogów. Customizacja niestety trwa. Kolejna kwestia to dotarcie do potencjalnych odbiorców – zamiast tworzyć wartościowe treści, trzeba zajmować się przygotowaniem kanałów komunikacji. Start z własną treścią nie jest łatwy.

Ten brak czasu na customizację oraz czas na dotarcie do potencjalnych odbiorców były powodem tego, że zainteresowałeś się dzieleniem wiedzą w postaci kursów? Kursy, z perspektywy osoby dzielącej się wiedzą, są prostsze?

Na pewno jest to droga na skróty – rekrutacja, zapoznanie się z materiałami i już. Realnie to zajmuje kilka godzin (pomijam czas między rozmową, a odpowiedzią ze szkoły programowania). Start na pewno jest łatwiejszy jednak są też minusy. Kursanci uczą się z przygotowanych materiałów, jest to dość sztywno wytyczona ścieżka. Jeśli ktoś ma jakiekolwiek doświadczenie np. z innym językiem programowania czy uczył się wcześniej samodzielnie, nie mogę mu powiedzieć “zacznij od X”. Każdy zaczyna w tym samym punkcie i ma taki sam materiał do przerobienia. Mogę jedynie polecać dodatkowe rzeczy i rozmawiać o nich.

Jak łączysz pracę mentora i Software Engineera?

Nie mieszam dwóch obowiązków tzn. mam wyznaczony czas, w którym sprawdzam zadania i odpisuję na komunikatorze Kursantom. Poza tymi godzinami jestem niedostępny. Na początku nie miałem tego tak poukładanego. Chciałem każdemu na bieżąco odpisywać, ale cierpiała na tym moja praca zawodowa. Ustalenie odpowiedniego czasu na jedno i drugie zajęcie wprowadziło trochę porządku i przy okazji poukładało mój dzień. Dzięki temu Kursanci też wiedzą, kiedy mogą spodziewać się odpowiedzi na pytanie czy sprawdzenie zadania.

O czym Twoim zdaniem mówi się za mało w branży IT? Co zazwyczaj jest pomijane w projektowaniu ścieżki kariery zarówno przez pracodawców, jak i pracowników?

Myślę, że mało się mówi albo praktycznie nie mówi o projektowaniu kariery. Gdzieś, kiedyś o tym słyszałem, ale to historia na zasadzie “znajomy znajomego”. Wielu ludzi zaczyna pracę w IT i uczy się tego, co potrzebne jest w danym projekcie/firmie. Przychodzi moment zmiany pracy i uczymy się pod daną ofertę. Ma to swój sens, ale nie nazwałbym tego projektowaniem kariery. W taki sposób swoją karierę powierzamy przypadkowi. Od jakiegoś czasu myślę nad rozwiązaniem tego problemu.

Ostatnio myśli przerodziły się w bardziej konkretne plany. Na bazie swoich doświadczeń, chciałbym pomóc osobom, które już mają pierwszą czy drugą pracę i szukają rozwoju. Co z tego wyjdzie? Mam nadzieję, że pomogę przynajmniej kilku osobom rozwinąć skrzydła.

Jak podchodzisz zatem do projektowania kariery? Co powinno wpływać na projektowanie kariery programisty: potrzeby własne czy potrzeby rynku?

Na pewno trzeba monitorować rynek i oferty pracy jednak widząc ofertę: “fullstack developer” nie warto rzucać backendu i uczyć się frontu czy na odwrót jeśli ktoś tego nie czuje. Warto spróbować, zobaczyć na czym polega inna technologia jednak bardzo trudno jest być ekspertem od wszystkiego. Osobiście, będąc backendowcem, przeglądam różne oferty w mojej dziedzinie i wyłapuję nowo pojawiające się słowa kluczowe. Część oczywiście pomijam, bo mogą to być niszowe technologie jednak widząc kilkakrotnie powtarzające się słowo “mikroserwisy” zaczynam się interesować tematem. Młodszym koleżankom i kolegom radziłbym zastanowić się nad zmianą pracy lub co najmniej projektu co 2-3 lata. Można nie tylko nauczyć się nowych technologii, ale poznać też inne podejście do prowadzenia projektu.

Paweł Pluta. Senior System Software Engineer w IGT. Programista, lider zespołu i mentor w szkołach programowania. Mimo wykształcenia technicznego, wiedzę zdobywał sam, a teraz chętnie się nią dzieli. Autor kursu Javy dla Heliona i materiałów dla bootcampów.