Ten wpis opowie moją historię, ale mam nadzieję, że znajdziecie w nim coś dla siebie (i swojego zespołu). W skrócie, Jestem Ania i jakieś 3 lata temu zdecydowałam się zmienić branże i zacząć pracować jako programistka. Zaczęłam się uczyć javy, po 6 miesiącach znalazłam pierwszą pracę. Tak, było to szybkie, a moja nauka była mocno nastawniona na praktyczne umiejętności, a mniej na teorię czy inne technologie.
W rezultacie byłam bardzo mocno nastawniona na backend, a właściwie, na Javę ze Springiem. Moja pierwsza styczność z front-endem to JSP, którego używałam do swojej pierwszej aplikacji (tak, bardzo prosty HTML i CSS, które to wtedy traktowałam jako zło konieczne, byleby skończyć aplikacje i móc ją jako tako pokazać). Czas mijał, ja zdobywałam kolejne doświadczenia, zmieniałam pracodawców, nawet robiłam trochę we frontendzie (o czym będzie za chwilę) jednak nigdy przenigdy nie myślałam o sobie jako o full-stack developerze. Front-end to było coś, co czasem po prostu trzeba było zrobić, gdzie back-end interesował mnie na tyle, by uczyć się go po godzinach, pisać wpisy na bloga i nie narzekać, ile to pracy z nim związanej mam w pracy.
Ostatnio, jak pewnie część z Was wie zmieniłam ponownie pracodawcę i tak się złożyło, że ta zmiana dała mi możliwość spróbowania swoich sił ponownie we frontendzie. Wyszło na to, że nie jest to takie złe, ba, nawet całkiem mi się to podoba. Co wpłynęło na tą zmianę? Albo, jak otoczenie pomogło mi polubić front-end? O tym właśnie postaram się napisać w tym wpisie.
Pozwól się uczyć (naprawdę uczyć!)
Powiem szczerze, gdy przygotowywałam swój pierwszy javascriptowy/reactowy kod do review byłam trochę przestraszona i trochę zestresowana. Niby prosty modal, ale dla mnie to był pierwszy w życiu komercyjny (i raczej jeden z niewielu) fragment kodu w javascripcie, a do tego react, i redux, których to zaczęłam uczyć się dosłownie w poprzednim tygodniu. Tak, review było pełne komentarzy, jestem raczej pewna, że dostała je niemal każda linijka mojego kodu. Czy było to deprymujące? Wręcz przeciwnie, a to dlatego, że:
- komentarze, które dostałam były nie tylko grzeczne, ale też tłumaczące mi moje błędy — nie czułam się więc z nimi, źle, wręcz przeciwnie, dostałam kopa, że zespoł dba o mój rozwój i chce mi pomóc w jak najlepszej nauce,
- duża ich część była na temat lintingu i zasad, jakie stosujemy wewnątrz firmy, których jeszcze nie miałam okazji poznać. A uwierzcie mi, przesiadka z formatowania kodu w Javie w formatowanie javascriptu nie jest taka oczywista — niemniej, łatwo było mi nanieść te poprawki,
- ilość komentarzy odnośnie logiki, była raczej znikoma, a wynikało to z faktu, że podczas tworzenia tego kodu prosiłam o pomoc. Dodatkowo, podczas mojego onboardingu, jedną z jego części było napisanie małej frontendowej aplikacji, przez co podstawy podstaw były już przeze mnie opanowane.
- Na koniec, każda z osób przeglądających mój kod zostawiła naprawdę miły komentarz, na temat tego jak fajnie poszedł mi mój pierwszy frontendowy PR, nawet jeśli był pełen drobnych błędów. To podniosło moją motywację, ale też ponownie, pokazało mi, że mój zespoł kibicuje mojej nauce.
Oczywiście, ten PR nie zamienił mnie w guru front-endu, a kolejne również pokazały ile jeszcze nauki mnie czeka. Niemniej, jako samo doświadczenie uczenia się i wymiany wiedzy, to było (i jest) naprawdę super!
By dać ci trochę punktu odniesienia, w poprzedniej firmie, owszem pracowałam trochę z Angularem 2 i Typescript, jednak w składzie mojego zespołu nie było nikogo, kto mógłby pomóc mi z nauką czy poprawą jakości kodu. Wszyscy dopiero się uczyliśmy tych technologii, a źródłem wiedzy był internet. Nie brzmi to tak źle, niemniej nie pomagało w poczuciu pewności, czy podejmowaniu decyzji. Tak, zdarzało mi się komentować kod innych słowami: “To nie wygląda dobrze, ale nie mam pojęcia jak to poprawić”.
Przygotuj zasoby
Wspomniałam już o tutorialu, jaki robiłam w ramach wdrożenia. Wspomniałam o pomocnym i przyjacielskim zespole. Ale to nie koniec. W obecnej pracy mamy wiele bibliotek, tutoriali i najlepszych praktyk, z których korzystamy. Rozwijana jest własna biblioteka UI komponetów jak i design system. Na slacku mamy kanały dedykowane technologiom, gdzie naprawdę wystarczy wysłać swoje pytanie i niemal natychmiast, ktoś Ci z nim pomoże, do tego jest również własny wewnętrzny StackOverflow, czy łatwe wyszukiwanie kodu w ramach wszystkich projektów. Te wszystkie zasoby, nie tylko ułatwiają naukę, czy pracę, ale też budują poczucie pewności. Nie czuję się zostawiona sama ze swoim zadaniem.
Pokaż Ważność
We wszystkich moich poprzednich pracach, gdy dochodziło do tego, że dostawałam jakieś zadanie front-endowe, mój tech lead czy manager bagatelizował je. Nigdy nie słyszałam, że jest ono ważne. Że jestem odpowiedzialna za projekt. Wręcz przeciwnie, słuszałam, że to “nic takiego, tylko na chwilę, ktoś to musi zrobić, nie musi być to mega poprawne”. Mam się nie przejmować, i jak szybko to będzie możliwe wrócę do backendu (choć czasem zadań front-endowych było na kilka tygodni). No to się nie przejmowałam (a właściwie, przejmowałam i byłam jeszcze bardziej sfrustrowana, że to tylko mnie to obchodzi). Niemniej, nawet jeśli nauczyłam się jak coś zrobić lepiej i chciałam przepisać kod, albo gdy chciałam poświęcić więcej czasu, nie było warto, bo przecież to tylko mały bug, tymczasowe zadania. Nie miałam możliwości współpracować z designerem czy wysłuchać feedbacku użytkownika. Dostawałam zadanie, często sprowadzone do dodaj pole formularza X, albo gdy A to B, bez odniesienia do użycia… Bardzo łatwo było poczuć, że robi się rzeczy, na których chyba nikomu nie zależy bardziej, niż na poziomie: “zamknij tego ticketa, niedługo może dostaniesz jakiś backend.”
Obecnie, jest zupełnie inaczej. Wiem, co implementuje i jak ważne jest to dla użytkownika. Mam kontakt z designerem, Właściciel Produktu i mogę nie tylko dobrze zrozumieć co robię, ale też podzielić się feedbackiem czy nowymi pomysłami ;) Nie mam więc poczucia, że marnuje swój czas, co więcej, odkryłam, że moja motywacja może być stymulowana rozwojem produktu, więc front-endowe zadania są całkiem fajnym źródłem satysfakcji.
Nie stopuj rozwoju
Być może odniosłeś wrażenie, że w poprzednich pracach, gdy tworzyłam front-end, kod był bardzo, bardzo zły, a mi zupełnie nie zależało. To nie tak, ale muszę się przyznać, że uczyłam się i pracowałam znacznie wolniej. Jeśli chodzi o jakość, jestem raczej z tych, co lubią jej pilnować, poprawiać i uczyć się, jak to robić. Było więc tak, że gdy poznałam lepszy sposób na daną implementacje, starałam się użyć tego w praktyce. Niemniej, w większości przypadku byłam stopowana przez Managera czy Właściciela Produktu, którzy pokazywali tykający zegar. Nie było czasu. I jasne, rozumiem, że nie wolno poprawiać swojego kodu w nieskończoność, a działające, jest zawsze lepsze niż idealne, ale nie gotowe, jednak nie rozumiałam, jak mogliśmy nie planować tych zmian na później. Jak z pełną świadomością długu technologicznego można było po prostu przejść do następnego kwartału, zostawiając projekt taki, jakim jest.
Znacznie lepiej pracuje mi się w otoczeniu, gdzie każdy pomysł na poprawę jest brany pod uwagę, nikt nie boi się zmieniać i ulepszać rozwiązań, nawet jeśli czasem oznacza to dodatkowe godziny pracy, czy lekkie opóźnienie w zaplanowanym harmonogramie.
Daj wybór
Śmieszne jest, że gdy aplikowałam do swojej obecnej firmy, więcej niż raz zakomunikowałam, że chce się głównie rozwijać w back-endzie. Mój pierwszy tydzien był więc dość szokujący, ale zakomunikowano mi dwie rzeczy:
- wierzymy, że doświadczenie full-stack pozwoli Ci lepiej rozumieć pracę dewelopera, więc chcemy byś na początku była zaangażowana w obie te działki,
- jeśli uznasz, że font-end jest zupełnie nie dla Ciebie, albo, że faktycznie chcesz się skupić tylko na backendzie, umożliwimy Ci to.
Póki co jestem zadowolona z mojej przygody jako full-stack, bo backendowe zadania również się pojawiają. Co wiecej, front-end został dla mnie odczarowany i nie mam nic przeciwko takim zadaniom. W dłuższej perspektywie ciągnie mnie bardziej do backendu, ale zadania związane z warstą wizualną też są ok. I chyba właśnie back-end z front-endem od czasu do czasu, brzmi jak plan na moją zrównoważoną karierę ;)
Wierzę też, że dzięki temu doświadczeniu nauczyłam się dużo jako deweloper. Cieszy mnie to, że ważne jest dla mnie przede wszystkim zaspokojenie potrzeb użytkownika, nie ważne czy przyczyniam się do tego Javą czy JavaScriptem :). Bazując na moim dotychczasowym back-endowym doświadczeniu jest mi też znacznie łatwiej uczyć się rozwiązywać problemy, co samo w sobie jest świetnym doświadczeniem.
Czy każdy programista back-end może pokochać front-end? Prawdopodobnie nie. Jednak, jeśli jest potrzeba, by trochę w nim popracował, ułatwij mu pozostanie szcześliwym i zmotywowanym programistą. Twórz zespoł czy organizację, która wspiera uczenienie, ale też pozwala popełniać błedy i wyciągać z nich wnioski. Takie środowisko, które docenia pracę i pokazuje jej sens. A, gdy po czasie, deweloper stwierdzi, że to nie dla niego, zaakceptuj to.
Myślę, że podobne porady można odnieść w drugą stronę i zastosować przy zamianie front-endu na back-end. A jeśli to właśnie Ty zmieniasz swoją dziedzinę, daj sobie szansę. Nawet jeśli to chwilowe, to może dać Ci zupełnie inne zrozumienie naszego zawodu.
