Czego nauczył mnie pierwszy rok pracy jako front-end developer

Ten wpis miał powstać ponad półtora roku temu, czyli dokładnie wtedy, kiedy rzeczywiście stuknął mi pierwszy rok pracy na stanowisku programistycznym. Spuśćmy na to, proszę, zasłonę milczenia.

W ostatnim sezonie, czyli co się działo, kiedy się nie działo

Większość osób, które tutaj zagląda, trafia na mój tekst poświęcony kursowi programowania Coders Lab (oto jest magia pozycjonowania). Wpis kończy się swoistym cliffhangerem, nie wiadomo bowiem, czy w końcu udało mi się tę pracę znaleźć, czy nie, czy kurs mi w tym w jakikolwiek sposób pomógł, czy był tylko wyrzuceniem pieniędzy w błoto. Do samego kursu nie chcę już wracać – wszystkie moje wrażenia na świeżo spisałam w tamtym poście – chciałabym natomiast napisać o tym, co było potem.

Znalezienie pierwszej pełnoetatowej pracy na stanowisku front-end developera zajęło mi półtora roku od momentu skończenia kursu. Wam pozostawiam ocenę, czy to długo, czy krótko; dla mnie tamten okres był bardzo trudny i niejednokrotnie chciałam już odpuścić, bo kolejny brak odzewu na nadesłane CV lub jakiegokolwiek feedbacku po rozwiązaniu zadania rekrutacyjnego był już nie tyle deprymujący, co bardzo mocno wpływający na stan mojego zdrowia psychicznego. Zanim nadszedł dzień, w którym w stopce mojego firmowego maila zamiast Administratora systemu strony pojawił się Programista front-end (do feminatywów jeszcze ewidentnie w firmie nie dorośliśmy), realizowałam zlecenia jako freelancer, co oznaczało mniej więcej tyle, że w jednym miesiącu starczało na czynsz i jedzenie, a w drugim już tylko na rachunki (dlatego zawsze będę powtarzać, że przed rzuceniem pracy KONIECZNIE trzeba mieć oszczędności). Dzięki poczcie pantoflowej i dobrej woli mojej koleżanki przez kilka miesięcy mogłam sobie ćwiczyć swoje umiejętności CSS-owe i HTML-owe, wprowadzając zmiany na stronach jej klientów i kodując mailingi. To oczywiście za mało, jeśli chodzi o zdobywanie doświadczenia na stanowisko programisty, dlatego w międzyczasie tłukłam kolejne kursy i projektowałam proste aplikacje.

18 miesięcy później…

W końcu moje trudy zostały wynagrodzone – po wykazaniu się w jednym dziale jako administrator systemu dla sprzedaży biletowej (praca niemająca z IT nic wspólnego – po prostu obsługa CMS-a) i po przypominaniu się dyrektorowi działu IT raz na miesiąc przez ok. 5 miesięcy, przeszłam rozmowę kwalifikacyjną na stanowisko front-end developera i 1 grudnia 2018 roku zmieniłam piętro, biurko, dział i – co najważniejsze – stanowisko. Jak po raz pierwszy zobaczyłam we wspomnianej wyżej stopce swój nowy zawód, to – bez żadnej romantycznej ściemy – miałam w oczach łzy.

Te łzy, choć już niekoniecznie z tak samo radosnym zabarwieniem, pojawiały się w tych oczach przez najbliższy rok jeszcze nie raz. Nowa praca zawsze jest trudna, ale jeśli z typowo humanistyczno-kreatywnych zadań przechodzi się do konieczności ścisłego myślenia przez 8 godzin na dobę (a w rzeczywistości 24), trzeba być przygotowanym na średnio jedno załamanie psychiczne na tydzień. I dlatego właśnie powstał ten wpis. Zawiera wszystkie rzeczy, które chciałabym wiedzieć jako początkująca programistka, choć z nich wszystkich i tak najważniejszy i zupełnie wystarczający jest punkt pierwszy.

Co bym chciała wiedzieć jako junior front-end developer

1. Proszenie o pomoc jest w porządku

Powtórzmy jeszcze raz dla tych z tyłu:

PROSZENIE. O POMOC. JEST. W PORZĄDKU.

Gdybym wykuła sobie tę jedną myśl na samym początku pracy, oszczędziłoby mi to litrów wypłakanych w biurowej toalecie łez, niedającej spać po nocach frustracji, a przede wszystkim – ciągłego lęku, że teraz to już na pewno mnie zwolnią.

Jako początkując_ programist_, nieważne jak świetnie przygotowan_ do pierwszej pracy, nigdy nie będziesz wiedzieć wszystkiego. Po pierwsze, każda firma ma własne zasady, własne repozytorium kodu, własne „kiedyś się naprawi”, o których wiedzą wszyscy wieloletni pracownicy, ale nie świeża osoba. Po drugie, jako osoba mierząca się z pierwszą pracą na tym stanowisku, siłą rzeczy będziesz napotykać na problemy, których nawet najlepszy research na stackoverflow nie pomoże Ci rozwiązać. I wiesz, że to dobrze? Bo w ten sposób najwięcej się uczysz. Tak, jest to frustrujące i będzie kosztować Cię bardzo dużo zdrowia, ale dzięki temu z każdym tygodniem będziesz lepsz_ w tym, co robisz.

Twoi koledzy i Twoje koleżanki też kiedyś byli i były na tej samej pozycji. I choć nie każdy będzie tak samo entuzjastycznie nastawiony do pomocy, to w stanowisko programisty wpisana jest współpraca z innymi, a to właśnie jest jej część. Nie martw się więc, że komuś zajmujesz czas, że od trzech godzin ma słuchawki na uszach i wygląda, jakby miał Cię zadźgać widłami, jak tylko się do niego zbliżysz (o dziwo tacy ludzie często okazują się najbardziej pomocni), że nie jesteś w pełni samodzieln_. NIE BĘDZIESZ, prawdopodobnie przez kilka dobrych miesięcy. I nie ma w tym nic złego.

Kiedy poszukiwałam jeszcze swojej pierwszej pracy programistycznej i spędzałam dużo czasu na grupach dla juniorów na Facebooku, niejednokrotnie natrafiałam na posty pisane w bardzo nieadekwatnym tonie, że junior to jest dla firmy strata, bo przez pierwsze miesiące nie będzie na siebie zarabiał, a wręcz kosztował jeszcze czas potrzebny na jego przyuczenie. I to wszystko jest prawdą. Ale jeśli każda firma wychodziłaby z takiego założenia, to w pewnym momencie – co chyba logiczne – tych przyuczających midów i seniorów w końcu musiałoby zabraknąć, prawda? A stanowisk w IT nie ubywa, a wciąż przybywa. Nic dziwnego, że potem taki junior ma obawy przed przyznaniem się do tego, że brakuje mu wiedzy do wykonania zadania i coś, co z pomocą drugiej osoby mógłby zrobić w pół dnia, rozwleka do dni trzech, aż w końcu i tak musi zmierzyć się z prawdą i pójść do współpracownika z większym doświadczeniem. A ludzie – tak, nawet programiści – często naprawdę są bardziej chętni do tej pomocy niż nam się wydaje.

Dlatego powtórzę to jeszcze raz i mam nadzieję, że nie będą to puste słowa:

proszenie o pomoc jest w porządku.

2. Żaden programista nie jest samotną wyspą

Co prawda wyrastamy powoli z szastania stereotypami o programistach na prawo i lewo, jednak pewne wyobrażenia o tym zawodzie wciąż mogą sprawiać, że po zetknięciu się z rzeczywistością przeżyjemy lekki szok. I to niekoniecznie pozytywny.

Wyłączając sytuacje, w których będziemy pracować w jednoosobowym dziale IT składającym się z nas i naszego komputera, nasz dzień pracy wcale nie będzie przypominać stereotypowego siedzenia w piwnicy i oglądania ludzi raz na dzień podczas przerwy lunchowej. A to za sprawą jednej rzeczy, na której widok w outlookowym kalendarzu drży każdy, komu właśnie zaczęło dobrze się pisać kod: spotkań.

Ach, spotkania. Te, na których będziemy planować swoją pracę. Te, na których opowiemy, co robiliśmy wczoraj i co będziemy robić dzisiaj. Jutro też o tym opowiemy i pojutrze też. W każdy dzień, uściślając. Te, na których pojawi się – w zależności od wielkości firmy – albo ktoś będący tuż nad naszym przełożonym albo przełożony przełożonego przełożonego, który jednym zdaniem obróci naszą pracę o sto osiemdziesiąt stopni. W końcu będą nasze ulubione spotkania, na których przed całą firmą będziemy chwalić się tym, co udało nam się w ostatnim czasie zrobić – albo kajać, dlaczego się nie udało. Spotkania produktywne i takie, na których nasza obecność nawet nie będzie zauważona. Czasem człowiek będzie wdzięczny, że uda mu się pokodować nieprzerwanie przez godzinę przez cały dzień pracy.

Spotkania to oczywiście niejedyna forma współpracy. Oczywistym jest, że będziemy dużo czasu poświęcać na współpracę z innymi programistami, czasem kodując w parze, a nawet w trójkach. Do tego dochodzą kontakty z naszym przełożonym, z Product Ownerem, Project Managarem czy UX-designerem. No i z ludźmi z innych zespołów.

Oczywiście liczba tych kontaktów zależy od wielkości naszej firmy czy samego działu IT, niemniej na pewno nie grozi nam izolacja.

3. Nikt nie wie wszystkiego

Tak, wiem, jest to największa oczywistość, jaką mogłam napisać. Ale wydaje mi się, że dla juniora będzie bardzo budująca.

Rzeczywistość jest taka: każdy programista korzysta z dokumentacji, forów programistycznych, kursów i tutoriali. Każdy z nas, niezależnie od poziomu zaawansowania, stanie przed zadaniem, które będzie wymagało poszukania rozwiązań poza znanym nam obszarem. Nikt nie pamięta wszystkich metod javascriptowych czy właściwości CSS. Najważniejsze to umieć tę wiedzę szybko znaleźć i tego też nauczysz się w pierwszych miesiącach pracy. A czasem i to zawiedzie i nawet senior zwróci się do innego programisty z prośbą o pomoc.

Na rozmowach rekrutacyjnych w części teoretycznej często wymaga się typowej pamięciówki, którą niestety po prostu trzeba sobie przyswoić. A i tak za parę tygodni w pracy będziesz sprawdzać w internecie, jak pozycjonować elementy wertykalnie za pomocą flexa.

4. Nauka nigdy się nie kończy 

To po części powód, dla którego napisałam o punkcie trzecim. Nauka programowania tak naprawdę nigdy się nie kończy – nie jeśli chcemy się rozwijać, tworzyć coraz lepszy kod i pozostawać atrakcyjnym pracownikiem dla potencjalnych przyszłych pracodawców. Szczególnie tyczy się to front-endu, w którym nie ma w zasadzie tygodnia, w którym nie pojawiłby się nowy framework albo zapowiedź kolejnej aktualizacji. Oczywiście nie da się podążać za wszystkimi nowinkami – nie ma to zresztą sensu, bo często są to tylko kolejne rozwiązania tych samych zagadnień. Nie da się jednak stać w miejscu, chociażby z tego powodu, że niektóre technologie mogą przestać być rozwijane i wspierane albo dotychczasowe zaplecze technologiczne nie będzie odpowiadać nowym wymaganiom biznesowym.

Podczas swojego pierwszego roku pracy poznałam więcej technologii niż przez cały okres swojej nauki. Na bieżąco, wraz z powstawaniem i rozwojem projektu, musiałam uczyć się od zera języka, którego nazwę słyszałam wcześniej parę razy, ale nic więcej o nim nie wiedziałam (GraphQL). Zresztą – cały nasz zespół musiał, dla każdego była to nowość, także dla programistów z wieloletnim doświadczeniem. Taka sytuacja jest zdecydowanie najlepszym środowiskiem do nauki – jest oczywiście stresująca, bo „ci z góry” się niecierpliwią i mało ich obchodzi to, że każdy z nas uczy się na błędach i stawia pierwsze kroki na nowym obszarze. Ale dzięki temu poznajemy od razu technologię na żywym organizmie, a tego nie da nam najbardziej nawet zaawansowany projekt, który będziemy sobie klepać po godzinach na własny użytek. I to właśnie jest największą wartością jak najszybszego rozpoczęcia pracy.

A co dalej?

Jeśli trafimy do firmy mającej dobrze rozwinięty dział IT (nie mówiąc już o firmach w pełni poświęconych technologii), kolejne miesiące od momentu rozpoczęcia pracy będą prawdopodobnie najbardziej intensywnym, ale i przynoszącym najwięcej efektów okresem nauki. Przy dobrym, wymagającym projekcie, ale i przy dużym nakładzie Waszej pracy po roku już nikt nie będzie myślał o Was jak o junior front-end developerze, ale po prostu – jak o programiście. Jeśli przetrwacie ten najtrudniejszy moment i wciąż będziecie otwarci na naukę – może być tylko lepiej.

Oczywiście nie mówię o tych słynnych 15k na rękę po paru miesiącach pracy i ofertach sypiących się z prawej i lewej strony. Wszystko w swoim czasie. Ale będziecie już na dobrej drodze do tego, żeby nie drżeć o stabilność swojego zatrudnienia i być gotowym – czy to z własnej woli, czy ze względu na warunki od Was niezależne – do szukania kolejnego wyzwania w IT. I tego serdecznie Wam życzę.