Między pracą a przygotowaniami do matury - wywiad z Nikodemem

W takim razie od początku - od czego się zaczęła się Twoja przygoda z programowaniem?

Zaczynałem bardzo klasycznie - od gier komputerowych. Jednak w pewnym momencie samo granie przestało mi wystarczać. Byłem ciekaw jak to wszystko działa. Wtedy dowiedziałem się, że istnieje coś takiego jak programowanie. Oczywiście moim pierwszym marzeniem było programowanie gier. Jednak wiem, że fascynacja to nie wszystko i chyba jednak nie pójdę w tę stronę.

Prawdziwa historia zaczęła się, jak kończyłem gimnazjum. Stwierdziłem, że pójdę do technikum informatycznego. W szkole zaczęliśmy programować aplikacje desktopowe, ale mi się to nie podobało, bo był to za wysoki próg wejścia. Potem odkryłem webówkę i od tamtego momentu jestem samoukiem.

W takim razie co skłoniło Cię do tego, żeby aplikować do Ragnarson?

Był grudzień 2019 roku. Zaczęły się plotki o kryzysie pandemicznym. Kończyłem 3 klasę technikum i pomyślałem, że chciałbym pójść do swojej pierwszej pracy z doświadczeniem, a nie tylko z maturą.

Przyszedł marzec, zamknęli nas w domach, a ja przypomniałem sobie rozmowę z koleżanką. Mówiła, że mogę spróbować swoich sił w webówce w Ragnarson jeśli będę znał Ruby on Rails i że to mega super software house. Nie byłem jednak pewien swoich umiejętności, więc wstrzymałem się z aplikacją do maja. Przez te parę miesięcy podszkoliłem się z Ruby’ego. Wysłałem aplikację i dzisiaj spotykamy się tutaj.

Z jakimi wyzwaniami spotkałeś się na początku w projekcie?

To było twarde lądowanie. Aczkolwiek byłem na to przygotowany.

Na trzecim etapie rekrutacji mówili mi, że projekt jest ciężki, ale zrobią wszystko, bym mógł się w nim zaaklimatyzować.

Trzy pierwsze miesiące były najgorsze. Jednak nie ze względu na złe samopoczucie w projekcie, tylko świadomość jak mało jeszcze wtedy wiedziałem. Całe szczęście, że nie aplikowałem na stanowisko juniorskie! Zderzyłem się z szokiem technicznym i miałem wrażenie, że nic nie umiem, a projekt jest bardzo skomplikowany. Jednak przeszedłem przez to dzięki wsparciu kolegów z zespołu, którzy wyciągnęli do mnie pomocną dłoń.

Minęły 3 miesiące, skończyły się wakacje i znów zaczęła się szkoła. Miałem do skończenia 4 klasę technikum, maturę do zdania i oczywiście pracę w Ragnarson. Nie wiedziałem czy uda mi się to wszystko pogodzić. Bardzo nie chciałem chodzić już do szkoły, ale został mi jeszcze jeden rok. Pomyślałem, że zacisnę zęby i dam radę.

A jak wyglądał zakres Twoich obowiązków?

Poszliśmy na układ w zespole, że dokładnie określę kiedy mogę pracować i ile jestem w stanie w ciągu tygodnia przeznaczyć na projekt. Wyszło pół etatu w Ragnarson, pół w szkole. Myślałem, że mógłbym jednym okiem patrzeć na zdalne lekcje, a drugim programować i nikt by nie zauważył. Okazało się, że to nie takie proste. Więc siedziałem po kilka godzin w szkole, a dopiero potem programowałem.

Chłopaki zawsze tak dobierali taski, żeby nie miały sztywno ustawionego deadline na konkretny dzień. Powiedzieli “Nikodem spoko, masz maturę. W międzyczasie my przygotujemy Cię, żebyś za rok mógł wejść w projekt większym krokiem”. Więc uczyłem się projektu, coś kodziłem, jednak nie było ode mnie wymagane nic, czego nie dałbym rady zrobić.

Na początku dali mi API do zrefaktorowania. Pomyślałem sobie “Wow, nigdy tego nie robiłem, ale to nie może być takie trudne”. Chciałem udowodnić, że jestem wart, by zostać w firmie. Spiąłem się jak mogłem i robiłem tyle, ile potrafiłem.

Potem robiłem rzeczy obok głównego nurtu aplikacji, które trochę leżały i się kurzyły. Nie były to jednak zadania bez znaczenia, tylko na bieżąco są dokładane nowe, konkretne funkcjonalności, za to trochę mniej ważne niż te najpilniejsze.

Jest taki stereotyp, że jak przychodzi junior to zawsze robi to, czego nikt inny nie chce i przysłowiowo przesuwa guziki w tę i z powrotem. Ale nie w Ragnarson.

Czy miałeś wsparcie mentorów?

Miałem w zasadzie dwóch mentorów. Jednym z nich był Witek. Na początku gdy miałem problemy, to pytałem go co zrobić. Gdzieś po trzech miesiącach zacząłem się zakopywać i potrzebowałem większego wsparcia. Ustaliliśmy, że będziemy robić pair programming dwa razy w tygodniu. Nie zawsze rozwiązywaliśmy tylko aktualne problemy - czasami robiłem swoje zadania, a on patrzył mi na ręce i nadzorował, czy robię dobrze. To jest zdecydowanie największa wartość, którą z tego wyniosłem i był to największy mój progres.

Potem zaczął mnie mentorować Tomek i zmieniła się dynamika. Aktualnie jestem już dłużej w projekcie i nikt mi na ręce nie patrzy :D Oczywiście w przenośni - tak naprawdę nigdy nie czułem presji czy oddechu na karku. Teraz, gdy mam jakiś problem to się z nim zgłaszam, a mentor przychodzi mi z pomocą. Obecnie czuje się bardziej swobodnie, ale nadal mam oparcie w chłopakach gdy czegoś potrzebuje.

W Ragnarson mamy tzw. płaską strukturę, czyli brak formalnej hierarchii w zespołach i firmie. Jak się w tym odnalazłeś?

Nie ukrywam, byłem zaskoczony. Wyobrażałem sobie wszystkich w garniturach, każdego w swoim boxie - zdecydowanie obraz korporacji jak z filmu. Natomiast płaska struktura sprawiła, że gdy zostałem częścią firmy to nie czułem, żeby którykolwiek z pracowników uważał się za “wyższego” nawet jeśli jest 10 lat starszy. Tak było na przykład z Maćkiem - naszym CEO - który podbił do mnie jak do kumpla na boisku i pierwszego dnia zagadał jak podobała mi się rekrutacja. Czułem się jakbyśmy spotkali się na mieście na kawie, a nie rozmawiali jak na dywaniku u szefa gdzie czeka Cię kaplica za źle zrobione zadanie.

W zespole pracuje też z naszym CTO Grzegorzem i tu widać ewidentnie, że mamy tę płaską strukturę. Kiedy rzuca on jakiś pomysł, to czasem się zdarza, że jednak przechodzi moje rozwiązanie. A przecież mój staż jest niczym w porównaniu do jego. Potrafi stwierdzić “A, faktycznie! Ja przez 10 lat robiłem to zawsze w ten sposób, a Ty dałeś mi świeże spojrzenie”.

Nigdy nie było momentu zawahania ze strony zespołu tylko dlatego, że pracuje tu krócej. Jeśli dam fajne rozwiązanie, to będzie przyjęte. Wszyscy są tutaj jak równy z równym.

Ponadto niezależnie od działu (czy to inwestycje, czy rekrutacja), każdy może przyjść i dodać swoje trzy grosze. Nikt nie powie “Dobra, Ty nie wiesz o co chodzi, więc twoje zdanie się nie liczy”, tylko każdy uwzględni w dyskusji Twój punkt widzenia.

Oprócz tej transparentności stawiamy również na otwarty feedback. Zarówno na co dzień, jak i w trakcie organizowanych dwa razy do roku warsztatów. Jakie było Twoje pierwsze wrażenie?

Pierwsze warsztaty pamiętam bardzo dobrze. Dostałem radę by przeczytać sobie rachunki sumienia napisane przez innych (tak nazywamy spis osiągnięć i potknięć z ostatniego pół roku). Pomyślałem ”Jestem świeży, napisze taki rachunek sam dla siebie”. Chciałem zmniejszyć sobie presję dostawania feedbacku od całej firmy i jednocześnie dać innym wgląd w to, co robiłem.

Gdy przyszedł dzień warsztatów, kompletnie nie wiedziałem z czym to się je - nigdy czegoś takiego nie robiłem. Okazało się, że jest to super inicjatywa. Spotykamy się w małych grupach i dzielimy opiniami oraz spostrzeżeniami na temat swojej pracy.

Całą tę pętle feedbackową, zaraz po pair programmingu, mógłbym postawić na czele hierarchii mojego rozwoju od stażysty do juniora.

Mimo że na codzień w projekcie dostaje się feedback, to ten zbiorczy pozwala Ci przypomnieć sobie o rzeczach, które mogły wylecieć z pamięci, a ktoś inny sobie gdzieś zapamiętał. Było to bardzo pozytywne zaskoczenie. Nie myślałem, że tak można dużo wynieść z rozmowy z ludźmi, z którymi masz styczność na co dzień, ale w innej formie.

Podczas drugich warsztatów miałem trochę więcej wkładu od siebie - dawałem o wiele więcej feedbacku i rozmawiałem na różne tematy. To jest umiejętność, którą trzeba sobie wytrenować - nie jest łatwo powiedzieć komuś w twarz, że zrobił coś źle i musi wziąć za to odpowiedzialność. Pamiętając jednocześnie, żeby feedback był konstruktywny i pomocny.

Dostawanie negatywnego feedbacku jak i dawanie go może nie jest przyjemne, ale gdy nauczysz się robić to dobrze, reszta przyjdzie naturalnie.

Teraz nie mogę się doczekać swoich trzecich warsztatów. Po całym roku w firmie myślę, że będą przełomowe. Ponownie będę mógł ustalić sobie własną stawkę, w dodatku mam cały rok bagażu doświadczenia, żeby dyskutować z innymi.

Właśnie, jak to jest ustalać własną stawkę - łatwo czy trudno?

Na pewno nie jest łatwo. Przy pierwszym zetknięciu pomyślałem sobie “Jak to działa? Przecież firmy tak nie funkcjonują. Indywidualne negocjacje stawki z szefem i te sprawy - rozumiem. Ale tak po prostu ustalać sobie wynagrodzenie samemu?”.

Przeczytałem wcześniej post Maćka na blogu, gdzie napisał “Moi deweloperzy ustalają sobie stawki i nie mogę nic z tym zrobić”. Pomyślałem “Jakaś utopia!” Ale nie wygląda to też tak prosto. Jednym z elementów feedbacków jest przedstawienie propozycji ile by się chciało zarabiać. Wtedy reszta grupy odpowiada czy uważają, że jest to stawka adekwatna do tego, co zrobiło się przez pół roku. To daje dużo do myślenia.

Ja na przykład na początku nie doceniałem siebie i myślałem, że nic nie umiem więc powinienem zarabiać dużo mniej. Jakie było moje zaskoczenie, gdy każda osoba na warsztatach powiedziała mi, że chyba pomyliłem cyferkę i powinienem wziąć sobie większą podwyżkę. Gdy pod koniec warsztatów tak jak każdy deklarowałem na głos swoją nową stawkę, czułem ekscytację i niepewność jednocześnie.

Uważam, że ustalanie wynagrodzenia daje poczucie pewnego bezpieczeństwa. Nie musisz się martwić czy będziesz mógł porozmawiać o podwyżce, tylko świadomie weryfikujesz stawkę co pół roku.

Podoba mi się taki model, bo pozwala dobrze zaplanować rok albo dwa-trzy lata w przód. Jeśli do rozwoju motywują kogoś wyłącznie pieniądze - to ten model jest idealną szansą na określenie celów i planów, by następnie myśleć o lepszej kasie. Ale to tylko jedna strona medalu. Druga jest taka, że jeżeli kogoś motywuje progres i pasja, to podwyżka jest po prostu wisienką na torcie. Ma się świadomość, że zarobiło się na podwyżkę i pokazało, że jest się w stanie dowozić i wywiązać z odpowiedzialności.

W jakie jeszcze obszary angażujesz się w Ragnarson?

Głównie w praktyki, które uruchomiliśmy po raz kolejny w tym roku.

Na poprzednich warsztatach robiliśmy sobie wewnątrz firmy ewaluacje gdzie widzimy siebie za kilka lat. Czy chcemy ze względu na płaską strukturę więcej obejmować ról w firmie, czy raczej zająć się samym kodowaniem? Padło też pytanie czy chcemy pełnić więcej ról technicznych, czy nietechnicznych - czyli czy będąc developerem chce również pomagać np. w sprzedaży. Mi wyszło, że chciałbym robić coś więcej niż tylko kodować.

Generalnie od kiedy pamiętam to zawsze chciałem być kapitanem, który wybierał składy - zarówno jak robiłem projekt ze znajomymi z klasy, czy gdy kopaliśmy piłką między blokami. Więc od małego ciągnęło mnie żeby być liderem i zarządzać ludźmi.

No i nadarzyła się okazja, gdy ruszyliśmy z praktykami. Wcześniej chciałem uczestniczyć w etapach rekrutacji technicznych, sprawdzać zadania i możliwości kandydatów, ale jeszcze nie mam takich umiejętności. Dlatego pomyślałem, że zaangażuje się jako wsparcie dla praktykantów. Na zasadzie “Hej, niedawno byłem tu gdzie wy, jeżeli coś to mogę wam pomóc”. Przy okazji będę mógł sprawdzać ich pracę i wiedzę, jednocześnie rozwijając siebie.

Zostałem technicznym “sprawdzaczem”. Mam w mojej drużynie razem z dwoma innymi mentorami pięć osób i dowozimy dwie niekomercyjne, komunikujące się ze sobą aplikacje. Moje zadaniem jest bycie trochę SCRUM masterem, trochę team leaderem. Inni mentorzy z firmy, którzy są ze mną w grupie, chyba podświadomie zeszli na bok, żebym mógł sprawdzić się w boju.

Jednocześnie też starasz się brać pod swoje skrzydła nowe osoby i trochę wspierać je jako “buddy”, prawda?

Tak. Robię to, bo poczułem że nowe osoby, które przychodzą do firmy i nie mogą się na żywo spotkać w firmie, mogą czuć się trochę zagubione. Jakoś tak naturalnie wyszło, że łatwo mi nawiązywać nowe znajomości. Gdy przychodzą nowe osoby, to zawsze znajduje czas by z nimi pogadać, pograć w jakieś gierki i tak dalej. Gdy ktoś boi się zapytać kogoś z większym stażem, to podbijają do mnie i razem kombinujemy. Nie zawsze znam odpowiedzi, ale w takich sytuacjach we dwie osoby łatwiej się myśli niż w pojedynkę.

A jak z pracą zdalną - czy łatwo było się dostosować?

Raczej zauważyłem przewagę dobrych elementów. Nie muszę wstawać na 9 do biura i zastanawiać się, czy mogę wstać sobie dwie godziny później.

Taka niezależność jest bardzo dużym plusem. Mogę z tygodnia na tydzień jeździć do innego miejsca - potrzebuje w zasadzie tylko laptopa, telefon z internetem i mogę pracować.

Jeżeli chodzi o mój rozwój - wydaje mi się, że nie ma tu różnicy. Pair programming można zrobić patrząc tylko na jeden monitor albo można połączyć się zdalnie. Tak samo gdy muszę się zapytać kogoś o cokolwiek, to mogę po prostu wysłać wiadomość na Slacku. Jest to trochę upośledzona wersja komunikacji, ale za to mniej inwazyjna. Nie muszę czuć się dziwnie siedząc w biurze i czekając, aż będę mógł do kogoś podejść i zagadać.

Podsumowując: jaką masz radę dla młodych ludzi jak Ty, którzy chcieliby zacząć karierę?

Przede wszystkim rada do ludzi, którzy zastanawiają czy są w stanie pogodzić naukę czy studia z pracą - tak, jesteście w stanie, i to wcale nie jest tak trudne jak się wydaje. Trzeba po prostu dobrze zaplanować dzień. Miałem dużo momentów w których miałem ogrom obowiązków na głowie i nie wyrabiałem, ale po jakimś czasie miałem bardziej klarowny podział dnia. Ustaliłem, że nie będę pracował ani minuty ponad plan, mimo tego że chciałem pokazać się z jak najlepszej strony.

Trzeba sobie konkretnie ustalić czas pracy, żeby się nie wypalić.

Jeśli chodzi o Ruby, to kilka osób z projektu poleciło mi “Programming in Ruby” autorów Dave Thomas, Chad Fowler i Andy Hunt. Dzięki tej książce wiele rzeczy stało się mega jasne. A przede wszystkim należy programować, programować i jeszcze raz programować. I nie bać się podbijać do firm, bo nawet każde odrzucenie dużo daje i można z tego wyciągnąć jakąś lekcję. Poza tym - róbcie, to co lubicie. I żyjcie ze sobą w zgodzie.

‍