Wdrażanie się do projektów w pierwszej pracy

Jak wyglądało wasze kilka pierwszych tygodni pracy jako Junior Developer? Jak długo się wdrażaliście, aby móc w końcu samodzielnie robić taski? Macie jakieś porady dla zółtodziobów?

Niedawno skończyłem studia i od miesiąca pracuję jako Junior Developer w średniej wielkości software house. Programowaniem interesuję się od dawna, co zresztą widać po dacie założenia tego konta, ale wcześniej wykonywałem tylko niewielkie (w porównaniu do tego co robię teraz) projekty na zlecenia.

Mój zespół pracuje na mikroserwisach, specjalizuje się w cache'owaniu danych i korzysta z innych dość ciekawych technologii - zdecydowanie nie zajmuje się CRUDami. Po dołączeniu do nich zostałem zalany kilkunastoma projektami z kilku różnych domen. Od początku większość czasu poświęcam na wdrażanie się do tych projektów. Większość z nich jest w miarę prosta i do pewnego stopnia podobna, ale niektóre są strasznie pokręcone (np. w jednym projekcie drzewo dziedziczenia przypomina katalog C:\Windows). I tak się zastanawiam: czy to normalne, że jest płacone mi za to, że ~80% czasu przez ostatni miesiąc przeznaczam na nic innego jak tylko uruchamianie nowych projektów i zapoznawanie się z nimi? Mam nadzieję, że nie zwolnią mnie za to, że najpewniej dużo więcej mi płacą niż przynoszę im zysku . Czy u was wyglądało to podobnie?

Jeszcze jedna rzecz nie daje mi spokoju. Jak często powinienem pytać, a jak często powinienem samodzielnie szukać rozwiązania? Przez pierwszy tydzień zadawałem masę pytań, ale potem coraz mniej, bo ileż można. Nie chciałem zanadto zabierać ich cennego czasu, zwłaszcza przez jedno pytanie potrafiła się wywiązać dyskusją na godzinę . To jest raczej pożądane, że junior zadaje wiele pytań, a może lepiej, aby był bardziej samodzielny? Przykładowo, powinienem się wpierw spytać o to, jak mniej więcej działa projekt, czy po prostu mam samodzielnie prześledzić kod i (zazwyczaj dość niekompletną) dokumentację?

W pierwszej pracy miałem mylny pogląd że każdy w zespole powienien znać projekt w 100%, zapoznać się z dokumentacją (myśląc że projekty w firmach są dobrze udokumentowane), jakimiś diagramami, prześledzić wszystkie flowy w aplikacji itp. Chciałem wiedzieć wszystko o każdym fragmencie aplikacji, jednocześnie miałem podobne odczucie jak Ty że powinienem już napisać co najmniej 5 tysięcy linii kodu. Prawda taka że w większości przypadków w ogóle nie musisz nic wiedzieć o projekcie tylko znać ogólny zarys, cel i trochę obsługi od strony usera, w dużym projekcie prawdopodobnie będziesz odpowiedzialny tylko za jego mały element i możesz nawet nie wiedzieć o istnieniu innych, a nikt nawet nie podejrzewa że zrobisz cokolwiek z głową w ciągu pierwszych paru miesięcy (chyba że to januszex i robicie strony wizytówki w wordpresie to wtedy pewnie powinieneś mieć już ich na koncie trzydzieści).
W n-tym projekcie do którego mnie przypisali nie poświęciłem nawet sekundy na zapoznawanie się z nim, po prostu od razu robiłem taski - to najlepszy sposób na zapoznawanie się z projektem. Najlepiej na początku wziąć jakiś prosty task typu literówka, nawet na takim tasku można się dużo dowiedzieć o architekturze, obsłudze wielu języków, sposobie kompilacji, wdrażania i testowania. Przy okazji robienia taska zawsze zahaczy się o jakieś inne elementy projektu i mimowolnie się coś o nim dowie.

A pytać zawsze wtedy kiedy może to oszczędzić kilka godzin lub dni poszukiwań na własną rękę, coś czego nie da się łatwo dowiedzieć samemu ani z internetu, ale też najlepiej tak żeby nie zajmować jednej osobie więcej niż w sumie pół godziny dziennie. Tzn. nikt cię nie ukarze jak będziesz pytał więcej ale będziesz po prostu uciążliwy.

Mój zespół pracuje na mikroserwisach, specjalizuje się w cache'owaniu danych

Jak każdy zespół który ma problem z wydajnością i nie wie jak go rozwiązać.

Ja pracuje z reguły na dość dużych monolitach z wieloma integracjami, bundlami itp. W momencie jak uważam że poznałem projekt w "100%"" to zmieniam projekt. Ogólnie tak jak kolega wyżej napisał, masz znać zarys projektu i umieć się odnaleźć w sekcji w której będziesz coś robił.

Macie jakieś porady dla zółtodziobów?

Nie ciśnieniować się zbytnio. Na starcie jest jakaś taka chęć do "wykazania się", ale naprawdę zrobienie prostego zadania w jeden dzień zamiast dwóch na nikim nie zrobi wrażenia. Po prostu staraj się robić uczciwie swoje.

Czy u was wyglądało to podobnie?

Tak, przez pierwszy miesiąc-dwa nie zrobiłem nic konkretnego.

Jak często powinienem pytać, a jak często powinienem samodzielnie szukać rozwiązania?

Jeśli całkowicie nie wiesz, co robić to znaczy, że powinieneś pytać kogoś o pomoc. Częstym błędem juniorów (i nie tylko) jest to, że się "zamykają" i próbują samodzielnie rozkminić zadanie i po dwóch dniach pracy mają coś, co senior skasuje i pokaże jak to zrobić w pięć minut. Częstotliwością pytań bym się nie przejmował - jeśli nie pytasz kilkukrotnie o to samo to nikt nie będzie miał problemu, żeby ci pomóc. Przynajmniej nie powinien.

Pamiętam że nie byłem tam mile widziany, zespół był toksyczny też wobec siebie, nikt zbytnio nie chciał cokolwiek robić. Musiałem sam się o wszystko wypraszać.
Nie miałem wdrożenia żadnego ale od razu task i jazda.
Bardzo źle wspominam pierwsza pracę.

Pierwszy dzień spędziliśmy głównie na zestawieniu środowiska developerskiego. Drugiego dnia dostałem taska, linki do dokumentacji i elo, jak coś nie wiesz, to pytaj.

Ja jak zaczynałem jako Junior 5 lat temu to miałem Seniora który siedział ze mną codziennie po parę godzin i opowiadał o projekcie i tak dalej. Luźna atmosfera, nie śpieszyło mu się i tak dalej. Fajnie to wspominam.

Teraz to pewnie niemożliwe bo jak to tak, pewnie każdy zajęty realizacją Story Pointów w Sprintach hehe i nie ma czasu dla Ciebie

Ja czekalem 2 dni az sie Gentoo skompiluje i zainstaluje na laptopie + kolejny dzien na KDE. W tym czasie przerobilem cala ksiazke do PHPa :P

Aaa, napisałem że w pierwszej pracy skręcałem komputer i wentylator.
Za to w drugiej pracy czytałem 25 letnie książki do C z nudów (Java here) bo czekałem tydzień na komputer
...
A miesiąc na komputer na którym dało się odpalić Eclipse xD

Jeszcze jedna rzecz nie daje mi spokoju. Jak często powinienem pytać, a jak często powinienem samodzielnie szukać rozwiązania?

Najlepiej próbować dążyć do pewnego balansu. Starać się samemu poradzić sobie, znaleźć odpowiedzi czy zrozumieć jak coś działa. Ale kiedy osiągnie się punkt gdzie ewidentnie ciężko więcej coś osiągnąć samemu, lub zajęło by to bardzo długo, to wtedy najwyższa pora zaczerpnąć pomocy niż marnować czas.

W pierwszej pracy zaczynałem od stanowiska elektronika , ale przesunąłem się w kierunku rozwoju oprogramowania , programy na Clipper i C na mikrokontrolery. Kolega pokazał jak się kompiluje projekt i resztę trzeba było nauczyć się samemu ;)

W drugiej pracy zaczynałem od czytania instrukcji wewnętrznych oraz szukałem dwa dni mojego komputera :)
Trzeciego dnia już wiedziałem że instrukcje sobie a życie sobie.

Jak wracałem do pierwszej pracy to zaczynałem od szukania komputera

ly000 napisał(a):

Jak często powinienem pytać, a jak często powinienem samodzielnie szukać rozwiązania?

"Samodzielnie szukać rozwiązania" warto wtedy, jak masz problemy, na które można znaleźć odpowiedzi w Google w pięć minut.
Jak masz jednak problemy z projektem, to nie znajdziesz tego w Google i najlepszym źródłem informacji jest zwykle inny programista, który zna projekt.

• Nie chciałem zanadto zabierać ich cennego czasu,

To nie jest tak, że programiści mają mało czasu, tylko że czasem potrzebują się skupić. Nie każdy ma zawsze czas, żeby się oderwać od razu. Ale możesz spytać, kiedy ktoś będzie mógł ci pomóc i umówić się na konkretną godzinę (zakładając, że sprawa wymaga przegadania 1:1, bo jak masz drobne problemy, to możesz napisać na firmowym czacie i wtedy ludzie to zobaczą i ktoś odpowie, kto akurat będzie miał czas. Możesz też zgłosić PMowi, że masz z czymś problemy).

To jest raczej pożądane, że junior zadaje wiele pytań, a może lepiej, aby był bardziej samodzielny?

Zadawanie wielu pytań jest okej, ale uważaj, żeby nie pytać w kółko o to samo. Rób notatki, organizuj swoją wiedzę.

czy po prostu mam samodzielnie prześledzić kod i (zazwyczaj dość niekompletną) dokumentację?

Tutaj łatwo można się zaplątać. Szczególnie jak dodasz do tego mglisty zwykle opis taska. Wtedy próbując być samodzielny, możesz stracić wiele godzin na coś, co okaże się niepotrzebne. Prawda jest taka, że jak masz niekompletny zestaw informacji - niekompletny opis taska, niekompletną dokumentację, niekompletną wiedzę, to trochę jakbyś zgadywał. Wtedy będąc samodzielnym, nie będziesz wnosił kompletnie nic do projektu, jeśli się okaże, że nie zrozumiałeś zadania. Dopiero pytając masz szansę coś do projektu wnieść.

Aventus napisał(a):

Jeszcze jedna rzecz nie daje mi spokoju. Jak często powinienem pytać, a jak często powinienem samodzielnie szukać rozwiązania?

Najlepiej próbować dążyć do pewnego balansu. Starać się samemu poradzić sobie, znaleźć odpowiedzi czy zrozumieć jak coś działa. Ale kiedy osiągnie się punkt gdzie ewidentnie ciężko więcej coś osiągnąć samemu, lub zajęło by to bardzo długo, to wtedy najwyższa pora zaczerpnąć pomocy niż marnować czas.

Może tylko dodam że to nie jest rada wyłącznie dla juniorów, ale dla wszystkich.

Przerażenie skalą codebase, strach przed zadawaniem pytań z obawy, że będą głupie, strach przed tykaniem legacy kodu, strach przed tymi wszystkimi procesami okołoprogramistycznymi (Scrum, etc). Ogólnie mnóstwo stresu i strachu, który z biegiem czasu udało mi się trochę zredukować, niemniej jednak gdzieś z tyłu głowy te emocje nadal mi towarzyszą.

rm -rf .
git push -f

I mówisz, że od teraz robimy porządnie

W pierwszej pracy tydzień czekania na kompa a potem ok. 3 miesięcy czytanie dokumentacji i zabawa na lokalnym środowisku.
W obecnej od roku robię taski a znam może 30% całego projektu i wspomagam się wiedzą funkcjonalnych.

Moim zdaniem ultimate porada przyjadająca się zawsze w nowej pracy - dużo nutuj. Notuj co Ci opowiadają o projekcie, notuj do kogo i w jakiej sprawie piszesz, notuj co się dowiedziałeś, jak testujesz zmianę klikając to zanotuj sobie co i jak sprawdziłeś. Dobre notowanie przydaje się na początku każdej nowej pracy - niezależnie od doświadczenia. Ze stresu zapomnisz do kogo napisałeś i w jakim temacie, kto ci kazał się tam udać.
A po miesiącu zaplusujesz gotową, sprawdzoną instrukcją setapu projektu :)
Od siebie polecam program notion do notowania, ale to nie ma znaczenia tak naprawdę.

Dokładnie, notowanie, ale w taki sposób, żeby tobie było wygodnie.

Niestety praca w zespole ma to do siebie, że jest z tysiąc różnych źródeł prawdy - np. o rzeczy A ktoś ci napisze w mejlu, o rzeczy B ktoś napisze na teamsach, o rzeczy C poczytasz w Confluence, o rzeczy w D na Jirze, o rzeczy E masz napisane w jakimś specjalnym repo na specjalnym branchu (true story) o rzeczy F ktoś ci powiedział ustnie itp. Więc ja robię zwykle tak, że jak wchodzę do projektu, to tworzę sobie zwykły plik tekstowy (albo kilka plików) i tam zapisuję wszystkie informacje, żeby były pod ręką. W jednym miejscu linki do wszystkich potrzebnych stron. Jak napiszę plik w formacie *.html, to będę mógł go otworzyć w przeglądarce nawet i dodać formatowanie

<li><a href="https://example.com">logowanie godzin</a></li>
<li><a href="https://example.com">dokumentacja X</a></li>
<li><a href="https://example.com">dokumentacja Y</a></li>
<li><a href="https://example.com">mejl od X w sprawie Y</a></li>

<h3>jak zrobić X</h3>
<div>lorem ipsum bla, bla, bla, bla</div>

(czyli notowanie dla ubogich, pewnie apka do notowania z formatowaniem byłaby bardziej nowoczesna, no ale cóż. W sumie Notes z macOS jeszcze daje radę).

Poza tym - jak dostajesz firmowego gmaila, to dobrym pomysłem jest zrobienie filtrów po jakichś frazach czy coś. Np. możesz po odbiorcy i mejl od kogoś z działu HR będzie miał etykietę HR na różowo. Mejl ze słowem jira, dostanie etykietkę Jira itp. Tym sposobem patrząc tylko na etykietki i kolory, wiesz, kto do ciebie pisał i po co.

Od siebie polecam program notion do notowania, ale to nie ma znaczenia tak naprawdę.

Tylko, czy uploadowanie poufnych danych o projekcie w chmurę nie łamałoby zasad firmowych w wielu firmach?
No i Notion jakoś ma zamulającą tę apkę.

Notowanie spoko, praktykuję, niemniej wchodząc w projekt w obecnej firmie to 90% wiedzy/założeń było przekazywane werbalnie podczas spotkań na Teams po angielsku z mieszanym niemieckim i japońskim, a było o czym gadać bo architektura IT dla mojej dziedziny biznesowej jest trudna (badania kliniczne) to ponad 100 aplikacji (i nie wiadomo ile skryptów) wymieniających dane i zintegrowanych na wiele sposobów. Część aplikacji w publicznej chmurze AWS/Azure, część on-prem, a jeszcze inne w chmurach vendorów jak Oracle Cloud. Do tego integracje przez bazy danych poprzez "wystawione" widoki (sic). Nawet super dokładna dokumentacja i diagramy reprezentujące zależności pomiędzy systemami zrobione w Sparx EA nie wyczerpywały tematu. Dlatego przez pierwsze 4 miesiące wszystkie calle nagrywałem i słuchałem po kilka razy robiąc notatki.

Jeżeli zatrudnili cię jako juniora, to ich obowiązkiem jest cię wdrożyć w projekt. Pytanie, czy potrafią.