5 rzeczy, których nauczyłam się jako junior software engineer

W wakacje zeszłego roku zaczęłam moją przygodę z Ruby On Rails. To już 8 miesięcy, a mi się wydaje, jakby dopiero wszystko się zaczęło. Minęły 3 miesiące mojego stażu oraz wkrótce mija pół roku odkąd pracuję jako junior software engineer. Czy to dużo? Możliwe, że tak, chociaż z każdym nowym zadaniem wciąż od nowa odkrywam sentencję Sokratesa: „Wiem, że nic nie wiem”.

Uwielbiam swoją pracę i na zmianę ją nienawidzę. Jeśli wyobrażacie sobie programistów jako osoby, którym spod palców wychodzi tylko czysty i działający kod to… macie bujną wyobraźnię 😛 Programowanie to tak naprawdę żmudne zajęcie, a liczba powstających linii kodu bywa odwrotnie proporcjonalna do poświęconego czasu na przemyślenie złożoności danego problemu i znalezienie rozwiązania. Czasem najbardziej efektywny kod jest dwulinijkowy, a zadanie zatytułowane „simple UI changes” okazuje się 8-dniowym zadaniem back-endowym, którego widocznym efektem końcowym jest wyświetlenie dodatkowej kolumny w tabeli (to nie jest hiperbola, a prawdziwy przykład z życia).

Kiedyś programowanie wydawało mi się spokojną, bezstresową, dobrze płatną pracą. Dzisiaj wiem, że tylko ostatnie się zgadza 😉 Może to też kwestia podejścia, ale ja nie znoszę wychodzić z pracy, gdy mój kod nie działa. Ma być 1:0 dla mnie, koniec, kropka. Z drugiej strony mam wsparcie kolegów i koleżanek z pracy. Nie wyjdzie – trudno, QA z radością wybierze guzik „rejected”. Na błędach też się trzeba uczyć i myślę, że nauczyłam się naprawdę dużo. Nabyłam ogrom umiejętności technicznych, odkryłam, że wcale nie wiedziałam co to znaczy „praca w zespole” i dowiedziałam się też nowości trochę o sobie.

Myślę, że mogę podzielić się z wami przemyśleniami z prawie 9 miesięcy przygody jako software engineer.

Wielkość projektu

Na studiach pisałam kilka większych projektów. Oprócz pracy dyplomowej przez te 5 lat studiów napisałam kilka mniej i bardziej złożonych prac zaliczeniowych. Dodatkowo łączyłam studia i pracę jako web developer – głównie przy tworzeniu stron www, sklepów i aplikacji od strony fronendowej, więc pierwsze komercyjne doświadczenie było za mną. Jednak żadna praca z uczelni (czy strona Internetowa) nie pokrywała nawet 1% tego jak wygląda system, który rozwijamy obecnie w pracy. Nad rozwojem jednego produktu pracuje tylko po stronie kodu 59 osób, znajduje się prawie 200 repozytorów. Wycinek projektu (strona administracyjna głównego produktu), nad którym pracuję jest tak ogromny, że przez te 9 miesięcy nie miałam okazji zajrzeć do jego wszystkich plików i funkcjonalności.

Począt­kowo zresztą wię­cej czasu zaj­mo­wało mi zna­le­zie­nie odpo­wied­niego miej­sca kodzie, niż samo napra­wia­nie błędu (buga 🐛). Dopiero od nie­dawna mogę powie­dzieć, że jako tako wiem czego gdzie szu­kać, a prze­cież nowy kod powstaje codzien­nie.

Wniosek: skróty klawiszowe w edytorze, fuzzy search czy wtyczki do narzędzi są absolutnym must-have 😀

Zaczynanie od środka

Zaczynać powinno się od początku. Wie to każdego dziecko już w przedszkolu. Niestety, nie zawsze tak się da.

Zaczynając pracę dołączyłam do firmy, która działa na rynku. Rozwijamy kod powstający już od kilku lat. Dodawane są nowe funkcjonalności, naprawiane są bugi, stary kod wymaga refaktoryzacji, a z innym żegnamy się raz na zawsze.

Jest to zupełnie inne doświadczenie od zaliczeń na studiach, gdzie dostaje się skończony problem, a następnie należy zaprojektować i zaimplementować jego rozwiązanie.

Jest to też zupełnie coś innego w stosunku do pracy agencyjnej, gdzie stronę www czy aplikację robi się pod klienta. Ma się +/- określony budżet, zarys oczekiwanego efektu końcowego oraz ograniczony czas. Kończy się jeden projekt zaczyna drugi i każdy właściwie zaczyna się od początku wybierając narzędzia czy robiąc sobie jakiś plan (przynajmniej po części przypominający to czego uczą na studiach).

Tutaj zaczęłam od środka i cały czas jestem w środku.

Kiedy poprosić o pomoc i jak rozwiązywać problemy?

Nauczenie się kiedy prosić o pomoc jest ważną częścią bycia juniorem. Nigdy nie chciałam być osobą, która nieustannie zadaje głupie pytania. Z drugiej strony nie chciałam siedzieć nad czymś kilka godzin, przeżywając załamanie nerwowe, gdy pomoc bardziej doświadczonego developera może po prostu zaoszczędzić sporo czasu i stresu.

Zaczynając staż usłyszałam, by 20 minut spędzić na szukaniu, a jak nie wie się co i jak – pytać i nie tracić czasu. Gorzej, gdy nawet nie wie się, o co zapytać.

To sprawiło, że od nowa odkryłam metodę gumowej kaczuszki. Naprawdę! Chociaż uważałam, że cała sprawa z gadaniem do przedmiotu jest jakimś żartem, to sama doświadczyłam, tego, że wyrzucenie z siebie myśli na głos podsuwa rozwiązanie. Bywa też tak, że wprowadzając drugiego developera w zadanie, jesteśmy zmuszeni opowiedzieć mu jeszcze raz wszystko co o już wiemy. Możliwe, że w tym momencie samo nasunie nam się rozwiązanie.

Czasem nie trzeba nawet otwierać ust do drugiej osoby czy kaczuchy. Miałam raz tak, że czekałam, aż senior dev znajdzie dla mnie chwilę. Zastanawiałam się, co jej powiem, gdy przyjdzie, a jednocześnie nie chciałam, by się załamała słuchając mojej nieskładnej wypowiedzi ;D Sam ten fakt, sprawił, że odpowiedziałam na swoje pytanie.

Zapisywanie kroków, czy tworzenie schematów blokowych sposobów jakimi chcę rozwiązać problem może pomóc. To też dobra podstawa do dyskusji z drugim developerem, gdy coś nie wyjdzie. Czasami okazuje się, że brakowało mi jakiejś informacji, do której nigdy bym nie doszła, lub dojście zajęło by mi ogrom czasu, a wystarczyło zapytać.

Staram się zapisywać ciekawe odpowiedzi, które otrzymałam czy interesujące fragmenty kodu. Zbieram wszystkie wskazówki, pro-tipy i przydatne informacje w notatkach. Jeśli znowu napotkam podobny problem, będę mogła do nich wrócić. Ba, gdy ktoś z teamu spotyka podobny problem, mogę zaproponować rozwiązanie.

Uwierzyć w siebie

To co, czego cały czas się uczę i pewnie będę się uczyć jeszcze długo. Spotkałam się niedawno z określeniem „syndrom oszusta”, chociaż bardzo bym sobie schlebiała uznając, że już mnie dotyka 😉

Czułam się (czuję?) niepewnie w Railsach oraz z faktem, że tak naprawdę nie miałam zbyt dużego doświadczenia komercyjnego w programowaniu (umówmy się, że tworzenie stron www to jednak trochę inna specyfika pracy, a akademicka obróbka sekwencjonowania DNA to już w ogóle nie ta bajka), gdy dostałam pracę. Poznałam osoby, których doświadczenie w różnych technologiach starczyłoby na obdarzenie kilku senior developerów. Osoby, przy których miałam poczucie, że ja chyba tak naprawdę nawet nie potrafię poprawnie obsługiwać komputera.

Jest ogrom języków, frameworków, metodologii i niuansów, tak, że jest nie możliwe mieć wiedzę w każdej dziedzinie. Jeśli o czymś słyszysz pierwszy raz w życiu, jest to całkowicie ok. Widzisz pierwszy jakieś raz narzędzia, nie wiesz jak z czegoś korzystać, to naprawdę nic dziwnego.

Studia próbują czasem wmówić, że uczą praktyki…ta, jasne. Najbardziej praktyczne projekty na inżynierii oprogramowania, były tak blisko rzeczywistości jak Need For Speed przybliżyło mnie zdania prawa jazdy (nawet nie podchodziłam).

Spoko wiedzieć, że spoko jest czegoś nie wiedzieć. Ważniejsze niż mieć cały zbiór danych w głowie, jest umieć znaleźć możliwie najoptymalniejsze rozwiązanie. Jeszcze ważniejsze jest to, że nawet jak nie umiem, to się tego po prostu nauczę. Mogę się nauczyć, a fakt, że otaczają mnie osoby z doświadczeniem sprawia, że tylko mam łatwiej. Nie muszę wynajdywać koła od nowa. Transfer wiedzy i dobre praktyki już dostałam (w końcu zaczęłam od środka, a nie od początku projektu), teraz muszę się dalej rozwijać, by jak najwięcej do zespołu dawać też od siebie. A skoro o tym mowa…

Nigdy nie przestaniesz się uczyć

Jeśli czytasz mojego bloga, bo chcesz się przebranżowić, to tylko tego punktu jestem w 100% pewna. Jest tak wiele technologii, które warto poznać, że jako programista nigdy nie skończysz się uczyć.

Nie oznacza to, że trzeba poznać wszystkie języki programowana, jakie wymyśliła ludzkość. Wątpię też, że pewnego pięknego poranka będę w stanie wyrecytować z pamięci wszystkie funkcje wbudowane Js/Pythonie/Ruby czy gdziekolwiek indziej. Za to dobrze poznać różne języki, technologie i narzędzi, by móc w nich wybierać w zależności od potrzeb. Być na bieżąco z tym, co aktualnie w branży jest modne, uważane za przyszłościowe i cały czas szlifować swoje aktualne umiejętności.

Przed rozpoczęciem pracy wydawało mi się, że umiem pisać czysty i logiczny kod, że tworzyłam rozbudowane strony www. Po studiach wydawało mi się, że umiem pisać złożone zapytania w SQL czy że byłabym w stanie zaprojektować ogromną bazę danych – pewnie nadal umiem – na papierze.

Tak czy inaczej, poznajesz coś nowego, zgłębiasz to, a okazuje się, że to dopiero mały wycinek całości.

Już raz to pisałam, ale powtórzę:
W branży IT nie można powiedzieć sobie np. „Okey, nauczę się teraz Railsów i do emerytury będę pisać aplikacje Railsowe”. Tak się po prostu nie da. Rynek IT szybko się zmienia, pojawiają się nowe technologie, trendy, języki programowania – nie ma miejsca na nudę.

Jednocześnie mam wrażenie, że przez ostatnie 8 miesięcy nauczyłam się więcej niż przez ostatnie 3 lata.