Co zrobić jeśli nie jestem w stanie rozwiązać taska lub znaleźć źródła buga a seniorzy są zawaleni robotą?
Zawalić ich swoją robotą. Chyba, ze ci seniorzy, to takie same nooby jak ty, jedynie o oczko wyżej i z twojej perspektywy wydają się jakimiś pół-bogami.
Jakie powinienem mieć nastawienie i postrzeganie jeśli takie sytuacje się zdarzają, pracuję dużo na bardzo starym kodzie, wiecznie trzaskam nadgodziny i mało z tego wynika, stawkę mam tak niską, że zaraz skończą mi się oszczędności a jednak chciałbym zrobić jeszcze kilka miesięcy w tym piekle?
Nauczyć się przyzwoitego stopnia wywalenia. Skąd niby wiesz ile coś ci powinno zająć? Skąd wiesz ile zajęłoby któremuś z tych seniorów? Skąd wiesz, że zajmuje ci za długo?
Czasem wydaje mi się, że jestem za słaby a czasami mam wrażenie, że jestem w cyrku.
Pewnie jedno i drugie po trochu. Jeżeli to twoja pierwsza praca, to jesteś "słaby", jak nie ma planu, żeby cię wdrożyć, to jesteś w cyrku.
Aktualnie przygotowuję się do zmiany pracy, dokształcam się po godzinach, ale pewnie jeszcze z pół roku mi to zajmie, chciałbym wyciągnąć mimo wszystko jak najwięcej. Nie wiem jak mam podchodzić do tej pracy i co jeszcze mogę zrobić, by to jakoś szło, czasem uda się zrobić coś bez problemu, zazwyczaj nie mam problemu ze znalezieniem buga, czasem jest trudno. Myślę, że osoby, które przydzielają taski (chyba SM) nie mają za bardzo pojęcia o IT i nie poziomują zadań, co mają to wrzucają stażystom. To tak powinno wyglądać?
W ideale - SM nie istnieje. W pół-ideale, gdzieś tam sobie jest, robi jakieś swoje rzeczy, nie oglądasz go za często. Taski dostaje zespół, i zespół rozdziela je między siebie. Z jakości tego co zostało zrobione też jest rozliczany zespół. Może się zdarzyć, że wykopie jakiegoś łosia, bo uzna go za materiał niereformowalny, ale są to raczej skrajne przypadki. No i jeżeli zespół jest rozliczany, to na ogół znajduje też sposób, żeby juniora podciągnąć, dając mu odpowiednie taski (takie, żeby wniósł jak najwięcej, marnując jak najmniej czasu seniorom). Nie patrz zbyt krytycznie na swoją pracę. Ktoś tego bug'a napisał, ktoś go wpuścił na produkcję, pewnie ci seniorzy...
SM denerwuje, zdecydowana większość pracy w firmie to bugi. Gdybym nie stracił prawie całych oszczędności na przebranżowienie + pracę tutaj, to by mnie już chyba nie było :D
Się denerwuje (trudno)? Czy ciebie denerwuje (gorzej)? Zauważasz jakikolwiek progres? Czy twoja wartość rynkowa rośnie, czy stoi w miejscu?
A tak w ramach poradnika, na podstawie obserwacji i doświadczenia:
- Musisz rozumieć na czym polega błąd. Jak nie rozumiesz, to op....asz tego kto tego buga napisał, każesz mu napisać steps to reproduce, result i expected result. Takie absolutne minimum.
- Musisz się nauczyć podchodzić "naukowo" do bugów. Częstym błędem (nie tylko) początkujących jest grzebanie po całym kodzie, zapuszczanie debugera, zmiany po omacku "bo to może być to". Tutaj trzeba nauczyć się systematycznego podejścia:
Dostajesz bug'a typu "obiekt wysłany na enpoint post /blabla nie jest widoczny na endpoincie get /blabla". Rozpisujesz sobie na kartce, że masz endpoint, który wchodzi, bazę danych, odczyt z bazy danych. Rozbijasz to na robocze hipotezy:
- obiekty nie zostają zapisane w bazie danych
- obiekty nie są odczytywane z bazy danych
Weryfikujesz obie hipotezy, któraś pewnie będzie prawdziwa, wchodzisz głębiej i sprawdzasz powody.
Oczywiście to jedynie jakiś przykład z czapy, ale usystematyzowane myślenie, to bardzo pomocna, a wcale nie tak częsta umiejętność.
Jak wyglądała Wasza pierwsza praca?
Januszsoft, taki, że gdybym podał nazwę, to @Crowstorm by tam CV złożył. Walenie na nadgodzinach, opóźnione pensje, atmosfera w pracy na poziomie zera absolutnego (seniorzy - buce). Wywalili mnie po roku, "bo na programistę się nie nadaję". Jeszcze na okresie wypowiedzenia znalazłem nową pracę za 2x więcej i z pensją na czas. Co by nie być niesprawiedliwym, naprawdę dużo się tam nauczyłem, właśnie przez bycie pozostawianym sam na sam z problemem.