Dwa pierwsze miesiące… czyli nowicjusz na front-endowym pokładzie

nowoczesny-frontend.pl 3 lat temu

Ostatnio nasz zespół się powiększył. Naszym nowym „nabytkiem” został Paweł – do tej pory związany z zupełnie inną dziedziną, a mianowicie politologią. Paweł postanowił jednak jakiś czas temu się przekwalifikować i spróbować swoich sił w IT. W efekcie od 2 miesięcy współpracujemy, a mi udało się go namówić, by w kilku słowach opisał swoje wrażenia. Oddaję mu zatem głos…


Postanowiłem skorzystać z zaproszenia Maćka do napisania kilku słów na jego blogu o swoich wrażeniach i doświadczeniach z pierwszych miesięcy pracy jako front-end developer. A więc do dzieła…

Jak to się w ogóle zaczęło

Jestem przypadkiem programisty z przekwalifikowania. I to całkiem świeżym, zwłaszcza w odniesieniu do pozostałych członków mojego obecnego zespołu. Decyzję by wejść na poważnie w świat IT podjąłem ledwie dwa i pół roku temu, tym samym zaczynając etap wytężonej nauki, różnorodnych kursów, pracy nad sobą, nowych fascynacji, a czasem też porażek oraz wątpliwości czy dam radę, czy się nadaję, itp.

Sam proces przekwalifikowania to jednak materiał na osobny post, pozostanę więc jedynie przy wyjaśnieniu, iż w tym czasie ukończyłem m.in. stacjonarne kursy UX-Designera w InfoShare Academy i JavaScript z Reactem w Code:me.

Jeszcze w trakcie nauki, około dwa lata temu, zacząłem realizować pierwsze projekty na zlecenie. Na początku były proste strony internetowe w formie wizytówek – HTML, CSS, SASS, trochę JS-a i jQuery. Musiałem jednak wykonywać je w całości, to znaczy od projektu ux-wego zaczynając, poprzez layout (wraz z logo), wreszcie kodowanie, a kończąc na zamieszczaniu na serwerze i administrowaniu. Bywało, iż więcej godzin spędzałem w Figmie, Inkscape czy Gimpie, niż w samym IDE.

Zdobyte jednak przy tych pracach doświadczenie przydało się przy realizacji znacznie bardziej złożonego projektu, międzynarodowego (i w pełni online) festiwalu literatury i teatru Kosmopolis 2020. Podobnie jak wcześniej, byłem odpowiedzialny za przygotowanie pełnego projektu i jego wykonanie, w tym także zamieszczanie treści i dostarczenie analiz z Google’a.

A potem był kolejny duży projekt. Można powiedzieć więc, iż wkroczyłem w świat frontendowego freelancingu, gdzie sam byłem sobie „sterem i okrętem”, a przy tym i całą wieloosobową załogą. A to różni się bardzo, ale to bardzo, od pracy w frontendowym zespole.

Na moje szczęście, jakieś dwa lata temu, całkiem przypadkiem, zostałem zaproszony do pewnego wieloosobowego projektu. Grupa początkujących, trójmiejskich (i nie tylko) python developerów (mam nadzieję, iż się nie obrażą za to określenie) rozpoczynała w tym czasie prace nad aplikacją o nazwie Żeton, skierowaną do dzieci z wyzwaniami, m.in. autyzmem, i ich rodziców. Akurat brakowało im frontendowca i tak się dogadaliśmy. Projekt z czasem mocno ewoluował, a ja miałem możliwość doświadczyć w nim nie tylko pracy zespołowej (współpracy we froncie, z backendem, testerami, grafikiem, UX-em, copywriterem, terapeutami), ale także asynchronicznej, gdyż po pierwsze 90% czasu pracowaliśmy zdalnie, a po drugie każdy z nas dysponował wolnym czasem w różnych dniach i godzinach. Równocześnie organizowaliśmy różnorodne warsztaty, m.in. z Sassa, CI/CD, UX, prowadzone zarówno przez nas samych, jak i profesjonalistów, którzy chętnie dzielili się wiedzą. I właśnie to doświadczenie wspólnego projektu najlepiej przygotowało mnie to mojej obecnej pracy.

Przeprogramowanie

Moje pierwsze wrażenie z nowego miejsca pracy, prawdopodobnie jak wielu z Was, nie były związane z kwestiami technologicznymi. Jeszcze podczas rozmów rekrutacyjnych (oczywiście w okresie pandemicznym online) dało się odczuć pozytywną atmosferę, na pewno otwartości, bezpośredniości, dużej naturalności i partnerskich relacji. I rzeczywiście, potwierdziło się to od pierwszego dnia. Była to jednak dopiero pierwsza nowość (wcześniejsze prace w sektorze publicznym przyzwyczaiły mnie do hierarchiczności i sztywności relacji) z całej serii.

Chyba pierwszą i podstawową umiejętnością programisty jest zdolność do programowania samego siebie. Wcześniej działałem na PC, z Windowsem lub Linuksem, tu otrzymałem na wstępie nowiuśkiego Maca. Owszem, słodkie jabłuszko, ale przyzwyczajeniom trzeba było powiedzieć pa pa. A to dopiero początek i pozyskanie dziesiątków wszystkich dostępów okazało się najmniej czasochłonne. Wcześniej komunikację ogarniałem w Slacku, czasem Discordzie i Google Meet, tutaj całość w Teamsach (i niekiedy Zoomie), które okazały się jednym z podstawowych narzędzi. Do zarządzania zespołową pracą wykorzystywałem Asanę lub Trello, tutaj wszystko spina Jira. Zarządzanie projektami – poprzednio oczywiście git i GitHub/GitLab, w tej chwili Sourcetree. Za bardzo przyzwyczaiłem się do VSCode (po Bracketsie całkowicie przestawiłem się na to IDE), no to teraz przyszedł czas się odzwyczaić, bo śmigamy na Webstormie. Code review też nie bezpośrednio w GitHubie czy GitLabie, ale w Crucible. No i najważniejsze, musiałem się przestawić z Reacta i Gatsbyego na kilka znane mi Vue, na którym stoi 90% projektów. Tak więc kiedy dostałem zadanie do wykonania w Figmie, w której już wcześniej pracowałem, odetchnąłem z ulgą.

Tak naprawę to najtrudniejszy był pierwszy miesiąc, w którym to, co chwila pytałem kolegów, jak się robi najprostsze rzeczy. W drugim zacząłem nabierać wprawy o obsłudze tego całego stacka technologicznego. Ponadto przeszedłem od poznawania różnych projektów i drobnych w nich robót, do poprowadzenia niedużego wewnętrznego projektu, oczywiście przy wsparciu kolegi z zespołu jako skrzydłowego.

Zespół przede wszystkim

Całe to opisane przeprogramowywanie dokonywało się przy ogromnym i stałym wsparciu kolegów z mojego zespołu. Wykazali się naprawdę dużym zrozumieniem, nieraz klepiąc mnie po plecach (oczywiście online) i dodając otuchy.

Ze względu na pandemię od początku pracowałem zdalnie. Oprócz lidera zespołu, Maćka, który osobiście przywitał mnie pierwszego dnia w firmie, pozostałych dwóch członków przez pierwszy miesiąc znałem tylko z monitora. Niemniej, komunikacja i czasem wspólna praca, nie stanowiły problemu. Tygodniowy rytm pracy jest ogarniany dwoma półgodzinnymi spotkaniami (poniedziałek i środa, a teraz czwartek), na których opisujemy co zrobiliśmy, jakie napotkaliśmy przeszkody, jakie zadania na nas czekają i kto może je wziąć na warsztat. Poza tym pracujemy asynchronicznie, zdzwaniając się w razie potrzeby, by omówić jakiś problem czy wyjaśniać wątpliwości.

Tych spotkań w tygodniu bywa niekiedy całkiem sporo, choć zdarzały mi się też dni kiedy w całości pracowałem sam. Przez lata współpracy team wypracował wiele optymalnych rozwiązań, których nie da się poznać w kilka dni. Dlatego, jako nowa osoba w zespole, staram się na bieżąco konsultować postęp swoich prac, czego też z resztą pilnują moi koledzy. Druga rzecz to pamiętanie o code review, które pozwala wyłapać błędy, wskazać lepsze rozwiązania, a choćby na ich temat podyskutować, albo po prostu poznać kod i postęp prac kolegów. Zresztą zadania dzielone są na małe taski, co ułatwia ich sprawdzanie, śledzenie postępów pracy, a w razie potrzeby przerzucenie kilku rąk do pomocy (taski można wówczas robić równolegle).

Szybko przekonałem się, iż przyjęte rozwiązania sprawiają, iż praca idzie bez zastojów, taski rytmicznie spadają z kanbana, poszczególne dni i cały tydzień mijają bez ciśnienia, co przekłada się na pozytywny work-life balance. I po raz pierwszy od… nie wiem ilu lat, zacząłem mieć naprawdę wolne weekendy. Z wolną głową.

Podsumowanie

Nie przedłużając, bo i tak się rozpisałem, moje wrażenia i doświadczenia po tych dwóch pierwszych miesiącach są bardzo pozytywne. Znalazłem się w fajnym i zgranym zespole, który ma wypracowane metody działania, ale jest równocześnie otwarty na nowe. I choć na początku cierpiałem od nadmiaru nowych technologii i wdrożonych rozwiązań, to dzięki temu poczułem, iż da się pracować na luzie, czerpiąc z pracy dużo przyjemności. A to już więcej, niż nieraz można sobie wymarzyć.

I tylko dodam, iż cieszę się, iż przede mną kolejne dwa miesiące w tym samym miejscu.

Idź do oryginalnego materiału