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ą.