Wywiad z Adamem - czyli jak zostać one-man-army

Adamie, opowiedz proszę jak rozpoczęła się Twoja przygoda z Ragnarson.

Ragnarson to pierwsza firma związana z softwarem, w której pracuję. Wcześniej miałem do czynienia z różnymi pracami dorywczymi. Wtedy nie byłem jeszcze pewien gdzie jest moje miejsce w IT. Trochę serwisowałem komputery, trochę programowałem, trochę zajmowałem się bazami danych.

Nie ma tutaj raczej romantycznej historii z miłością od pierwszego wejrzenia, bo do firmy przekonywałem się stopniowo.

Kończyłem wtedy technikum na kierunku technik-informatyk. Ragnarson pojawił mi się w feedzie na Facebook-u

W lutym zaczęły się moje pierwsze przygody z programowaniem, a w maju, dokładnie dzień po maturze z matematyki, wysłałem CV do Ragnarson. Otrzymałem błyskawiczną odpowiedź i zanim dostałem wyniki matury, byłem już na praktykach.

Od jakiego stanowiska zaczynałeś?

Przeszedłem trochę niestandardowy tryb rekrutacji, bo miałem dużo swojego kodu do pokazania. Bawiłem się już w Pythonie, Rubym i trochę w innych językach. Aplikowałem na juniora, ale mój kod był wtedy jeszcze słabej jakości. Zacząłem więc od dwumiesięcznych praktyk, podczas których robiłem swój projekt.

Było to bardzo ciekawe przeżycie! Byłem jednocześnie product ownerem i developerem. Praktyki poszły bardzo dobre i dużo się nauczyłem z perspektywy czysto programistycznego podejścia.

Czy prowadzenie projektu samodzielnie, tylko pod opieką mentora nie było to dla Ciebie za dużym wyzwaniem jak na pierwsze kroki w branży?

Miałem ogromną ochotę pracować nad tym projektem, więc pasowało mi takie podejście. W internecie często można spotkać się z jakimiś kursami, w których można tworzyć różnego rodzaju projekty. Ale większość z nich jest po prostu nudna.

Kiedy zaczynasz programować zapał jest tak duży, że chce się kodować dosłownie cokolwiek.

Na dodatek miałem okazję pracować nad fajnym pomysłem, który faktycznie chciałem rozwijać. Uczestniczyłem w nim jeszcze długo po dostaniu się do Ragnarsona na pełen etat.

Ostatecznie projekt umarł śmiercią naturalną, ale wydaje mi się, że było to idealnie wyważone doświadczenie. Każdemu życzę praktyk na takim poziomie jak w Ragnarson: własny działający projekt z możliwością rozwijania go dalej.

A jak wspominasz zostanie “Ragnarem na pełen etat”?

W pierwszych miesiącach pracy dostałem projekt, w który zostałem wrzucony sam z Project Managerem (który swoją drogą też pracował w przeszłości jako programista Ruby). To był dopiero roller-coaster! Nie miałem doświadczenia w programowaniu komercyjnym, ale miałem mocne wsparcie ze strony PM’a. Nie spodziewałem się, że będzie to mentoring na tak dobrym poziomie. Minęły tak ze trzy, cztery miesiące na tej szalonej przejażdżce zanim pojawiły się pierwsze poważne problemy. Pamiętam taką historię z pierwszego deployu na produkcję.

Był poniedziałek - specjalnie przesunęliśmy deploy z piątku, żeby wszystko odbyło się bez stresu. Dzień później w Białymstoku odbywała się konferencja Smart Cities. W Ragnarson akurat wtedy dążyliśmy do wykształcenia wizji swojego produktu i Smart Cities było głównym obiektem researchu. Oczywiście dzień po deploy wszystko zaczęło się psuć. Jechałem akurat wtedy autobusem na konferencje, ale z telefonu utrzymywałem kontakt z Project Managerem. Wrzucałem tylko swojego approve’a w pull requeście z kodem PMa, który naprawiał mój kod. To dopiero były wyzwania! W porównaniu z takimi przeżyciami praktyki przebiegły bardzo spokojnie.

Czyli końcowo udało Ci się uratować projekt ze wsparciem Project Managera. Następnie trafiłeś do kolejnego na pół etatu i robiłeś jeszcze kilka projektów na supporcie. Czy trudno było Ci się przerzucić na pracę nad kilkoma rzeczami na raz?

Na początku nie było to trudne - byłem na fali entuzjazmu. Miałem podejście, że nieważne jaki projekt mi dacie, ja wszystko zakoduje.

Kiedy koduje się samemu dla siebie, nie ma tej przyjemności. Satysfakcja nie jest na takim poziomie jak wtedy, kiedy zaczynasz dowozić i klient uśmiecha się na callu i mówi, że jest zadowolony z rezultatów.

Więc na tej fali entuzjazmu wziąłem trochę za dużo na siebie. Pierwsze miesiące dzielenia obowiązków pomiędzy dwa-trzy projekty były spoko. W zasadzie miałem wszystko podzielone dniami: poniedziałek i wtorek w jednym projekcie, środę i czwartek w innym, a w piątek w zależności od tego co było do zrobienia. Trudności pojawiły się, gdy dwa projekty na raz zaczęły przyspieszać. Tutaj był problem z określeniem, ile jestem w stanie dowieźć. Cały czas mówiłem “co dacie, to zakoduje”. Trochę na tej płaszczyźnie się wywaliłem. Nie było dużych fuck-upów, ale klient widział, że nie jestem w pełni dostępny, że niektóre feature’y mogły być dostarczone szybciej.

Była to bardzo ciekawa lekcja na temat tego ile jestem w stanie poświęcić czasu i jak ten czas naprawdę przekłada się na wyniki. Po pół roku dzielenia czasu między kilkoma projektami poszedłem na urlop i przemyślałem kilka spraw. Po powrocie zdecydowałem się przejść do jednego z projektów na full-time i finalnie zostałem w nim na dłużej.

To był moment gdy zweryfikowałeś swoje możliwości?

Tak. I uznałem, że nie będę brał nadgodzin. Ustaliłem sobie, że mój czas pracy to jest X godzin i nic nie będę do tego dodawać.

Zrozumiałem, że jak dodaję kolejną godzinę do tych standardowych ośmiu, to dodatkowa godzina nie jest tak samo efektywna, jak ta pierwsza.

Tak samo jest przy rozszerzaniu zespołu - dodatkowa osoba nie zwiększa wydajności dwukrotnie, a co najwyżej o 1,75 raza.

Rozumiem, że sam możesz decydować o tym jak chcesz się angażować w projekty i nie jest to narzucone z góry?

Dokładnie tak. Kiedy trafiałem do projektu po urlopie, poczułem, że chciałbym robić coś więcej poza programowaniem. Mniej więcej wtedy zacząłem swoją przygodę z rekrutacją na drugim etapie, czyli rekrutacją techniczną. Sprawdzałem czy kandydaci mają odpowiednie umiejętności, żeby trafić do naszej firmy.

W skrócie: mamy trzy etapy rekrutacji. Pierwszy to rozmowa rekrutacyjna. Następny to weryfikacja techniczna. Najpierw kandydat robi zadanie domowe, a następnie ja lub inny zaangażowany w rekrutację developer je sprawdza. Potem umawiamy się na rozmowę, na której przechodzimy przez zrobione zadanie i robimy live coding. Ostatni krok to rozmowa z firmą i sprawdzenie fitu kulturowego.

Wróćmy do tego nowego, dużego projektu. W którymś momencie jeden z seniorów opuścił zespół, a Ty przejąłeś po nim rolę Team Leadera. Dlaczego zdecydowałeś się na taki krok będąc najmłodszą osobą w tym zespole?

... i najmłodszą osobą w całym Ragnarson na tamten moment.

Jakiś czas przed tym wydarzeniem zacząłem czytać książkę “The Obstacle is the Way” Ryana Holidaya. Tak jak mówi tytuł, opowiada ona o tym, że przeszkoda jest drogą i sposobem na rozwój. Wyjście tego seniora z projektu było przeszkodą, bo na placu boju zostali dwaj frontendowcy i ja sam na backendzie. Dodatkowo klient nie był zbyt techniczny. Czyli innymi słowy mówił, że chce żeby coś wyglądało lub działało w jakiś określony sposób - i trzeba było to dowieźć.

Muszę powiedzieć, że koordynacja pracy w takim zespole była trudna. Nie każdy chce wziąć odpowiedzialność za to, co robi. Niektórzy mają tendencję do zakopywania się w swoich sprawach i finalnie po prostu nie wywiązują się ze swoich deklaracji. Czułem, że jest to przeszkoda, która wytycza moją dalszą drogę.

#Wtedy do mnie dotarło, że jeśli sam rzucam się na głęboką wodę, to umiem pływać. Czułem jak aktywizują się wszystkie części mojego mózgu związane z odpowiedzialnością i orientacją na cel.#

Myślę, że sporą rolę w całości miał mentoring otrzymany od wspomnianego senior developera. Zawdzięczam mu bardzo dużo w kontekście kierunku, który mi pokazał i w którym mnie popchnął. Dodatkowo świetnie zadziałał wtedy mechanizm wsparcia ze strony firmy i i feedback loopy.

Co masz na myśli?

Nie zostałem pozostawiony sam sobie jako team lead. Nie czułem oczywiście niczyjego oddechu na plecach. Ale kiedykolwiek potrzebowałem wsparcia, zawsze je dostawałem. Kiedykolwiek trafił się jakiś większy problem, mogłem po prostu zapytać kogoś bardziej doświadczonego i przegadać opcje. Zawsze mogłem też zrobić coś po swojemu i dostać feedback co poszło fajnie, a co można by jeszcze zrobić inaczej. Ostatecznie mam wrażenie że wszystko udało się dzięki supportowi ze strony ludzi w Ragnarson.

Wspomniałeś o tym, że zainspirowała Cię konkretna książka. Jak w ogóle wciągnąłeś się w czytanie?

Może nie ma się czym chwalić, ale przed Ragnarsonem nie czytałem książek w ogóle. Jedyna literatura jak stała na półce w domu, to były lektury. Były dla mnie nieatrakcyjne i po prostu mnie odrzucały. Całą swoją naukę języka polskiego przeleciałem na streszczeniach. Z jednej strony nigdy nie czułem, żebym miał talent do tego przedmiotu, a z drugiej nie byłem po prostu w stanie usiąść do czytania. Wtedy pojawił się wątek czytelniczy w Ragnarson. Obecnie funkcjonuje on jako kanał na Slacku oraz osobny wątek na Agency Kit [wewnętrzny tool i tablica ogłoszeń] w którym dzielimy się opiniami, piszemy reviews’y itd. To było w dużym stopniu paliwo dla mnie - zacząłem czytać sporo fikcji. Z kolei pierwszym dziełem z gatunku non-fiction był u mnie Sapiens. Było to pierwsze polecenie w wątku i od razu zmieniło moje spojrzenie na świat. Nie wiem jakich słów użyć, żeby opisać jak poszerzyła moje horyzonty. Uczyłem się historii dziesięć czy trzynaście lat, a autor opisała ją całą w skrócie. I to w dużo lepszy sposób. Drugim dziełem, które bym polecił, jest właśnie “The Obstacle is the Way”. Świetnie uczy współpracy i radzenia sobie z problemami w życiu. Była to pierwsza pozycja zahaczająca o stoicyzm i filozofię, którą przeczytałem.

Trzecią książką jest “The Selfish Gene” Richarda Dawkinsa i ona jest w podobnej tematyce co Sapiens, ale zagłębia się w tematykę genów i tego jak działa ewolucja.

‍