Pierwszy dzień praktyk - brak zadań, czy to normalne?

Hej, dziś zacząłem praktyki w firmie programistycznej i od razu dostałem dostęp do projektu oraz całego kodu. Przyznano mi też dostęp do Jiry, maila i kilku innych narzędzi, ale poza tym nikt nie przekazał mi konkretnych zadań do wykonania. Przez cały dzień przeglądałem kod, zadałem kilka pytań koledze z zespołu na temat projektu i jego działania. Udało mi się nawet znaleźć i naprawić jeden bug, ale w sumie czuję, że trochę się kręcę w miejscu.

Czy to normalne, że nikt mi nie wyznacza zadań na start? Jakieś rady, jak co robic w takiej sytuacji?

Jak dotrzesz do sytuacji ze będziesz po drugiej stronie to zrozumiesz

W ogarniętej choć trochę organizacji masz opiekuna i on organizuje Ci zajęcia, masz opiekuna ?

Oo, jak kiedyś w pracy dwa tygodnie czekałem na kompa.

@Adin Przebijam. Miesiąc czekania na komputer który dałby radę zrobić coś więcej niż się włączyć i odpalić notatnik (żadnego kompilatora nawet się nie dało wgrać bo sieć nie działała a USB zablokowane).

A na stażu musiałem sobie komputer najpierw skręcić. Ale najpierw skręcić wentylator żeby się nie ugotować przy skręcaniu kompa.

Plus - dostępy od razu pierwszego dnia. Wow ;-P

Mógł wpaść jakiś pilny bug czy projekt i ludzie byli mocno zajęci. Może to się dłużej utrzymywać (kilka dni), nie przeszkadzaj innym w pracy, grzecznie się przypominaj.
Spróbuj coś zoptymalizować, napisać testy.

Stary, jesteś dopiero pierwszy dzień, wrzuć na luz. Niestety, nie obraź się, ale praktykanci są na samym dole listy priorytetów firmy udzielającej praktyki - bo zajmują drogi czas deweloperów, a sami raczej w ten miesiąc (miesiąc? za moich czasów praktyki było 160h) za wiele nie zrobią pożytecznego. Wiem bo sam byłem na takich praktykach, niepłatnych. Jak mnie zatrudnili to następni praktykanci mi truli tyłek xD

Więc raczej - zamiast czekać na zadania, które mam nadzieję jakieś przyjdą - spróbuj wykorzystać jak najsensowniej ten czas. Czytaj kod projektu (dobrze że już zacząłeś), spróbuj zrozumieć jak poszczególne części są połączone. Jeśli projekt używa frameworka (a zwykle tak jest), to bez skrupułów powiedz, że nie znasz frameworka X i potrzebujesz paru dni na obczajenie sobie go. To samo co do bibliotek. Maksymalnie weź ten czas dla siebie. Pij jak najwięcej kawy (kawa kosztuje) i szukaj znajomości.

Aha, i nie daj się wepchnąć w testowanie. Z opowieści często praktykanci "programiści" byli po prostu wciskani do testów manualnych, co było chamskie do kwadratu, bo po prostu wykorzystywali darmową siłę roboczą.

Skoro pierwszego dnia miałeś komplet - stanowisko + dostępy i to jeszcze jako praktykant to trafiłeś bardzo dobrze.

Jak nie wyjdziesz z inicjatywą to dopiero za około tydzień się ktoś zorientuje że jesteś i coś ci wrzuci. Wynika to z tego że nikomu się nie chce wprowadzać nowego w system bo każdy ma swoje rzeczy do roboty i nowa osoba (niezależnie od seniority) jest dodatkowym brzemieniem. Ogólnie pociśnij ich tam żeby ci coś dali do dłubania a jak nie będziesz mógł nic wskórać to zadbaj o to żebyś mógł uruchomić projekt lokalnie/lokalnie z podpięciem do zewnętrznej bazy/lokalnie z podpięciem do zewnętrznych serwisów oraz oprócz tego żebyś mógł wykonać comita na gicie czy svnie. A teraz się nie przejmuj, dupnij sobie monsterka, zjedz kanapkę, obejrzyj YT, poczekaj, na daily powiedz że jesteś zblokowany bo dostępy i potem powtórz wszystkie punkty od dupnij sobie monsterka.

Ja w jednej firmie czekałem dwa tygodnie na laptopa, a dwa miesiące na kartę do biura. Dostępów do niektórych systemów np. do rejestrowania czasu pracy nie udało się uzyskać nawet po roku pracy i musiałem latać i prosić na koniec miesiąca kogoś kto miał o pomoc.

Często spotykaną sytuacją jest taka, że otrzymujesz komputer i dostępy w ciągu tygodnia, natomiast np. miesiąc nie ma zadań, ponieważ osoba, która miała ciebie wdrażać ma urlop/chorobowe/audyt/urwanie d&#y itd.

No ja akurat na praktykach i stażach, a zresztą w każdej kolejnej pracy też, dostawałem z grubej rury taskami na twarz, tzw. "rzut na głęboką wodę" (stosowane głównie w budżetówce i małych firmach) i ledwo z tym nadążałem cudem unikając poważniejszych wpadek. Niby można dzięki temu się więcej nauczyć, ale fajnie by było mieć choć trochę czasu na jakieś sensowne przeszkolenie, wdrożenie w obowiązki czy poznanie współpracowników. Natomiast najczęściej jest raczej odwrotnie, tzn. na początku luzik, często nie ma nawet przygotowanego stanowiska pracy dla praktykanta, trzeba załatwiać sobie dostępy, zawsze jest też jakiś obieg dokumentów niezbędnych do rozpoczęcia zadań, no i powinieneś mieć opiekuna praktyk, który temu zawiaduje. Generalnie nie ma co się na zapas przejmować, jak masz wolny czas, to się możesz czegoś sam pouczyć pod projekt. Czasem nawet jest to oczekiwane.

Spytaj swojego line managera / team leada, ew jak masz dostęp do jiry to może macie kanbana i sam sobie możesz wybierać taski z backloga albo może nawet masz już jakieś przypisane tylko nikt nie wspomniał.
Ja w banku przez dwa tygodnie nie miałem nawet dostępu do biura / niczego. Po dwóch tygodniach mogłem wejść do biura i dostałem zdalny dostęp do czystej maszyny, zajęło kolejny miesiąc żeby poinstalować soft, ale już po dwóch tygodniach odezwał się do mnie manager i pytał czemu nie jestem bardziej produktywny więc musiałem zacząć gonić ludzi i popychać tickety na własną rękę i robić taski w notepadzie i załączać jako zip do jiry. True story

WorekNaSmieci napisał(a):

Czy to normalne, że nikt mi nie wyznacza zadań na start?

Jeśli to pierwszy dzień, to luz. Co innego jeśli sytuacja utrzymywałaby się przez np. kilka tygodni. Wtedy świadczyłoby to o tym, że zespół jest słabo zorganizowany i komunikacja w nim szwankuje - jeśli wzięli kogoś na praktyki, a nie wiadomo, co taka osoba miałaby robić.

Jakieś rady, jak co robic w takiej sytuacji?

Możesz się rozejrzeć i zrobić coś pożytecznego np.

• to, co już robisz, czyli przeglądałem kod, zadałem kilka pytań koledze z zespołu na temat projektu i jego działania. Udało mi się nawet znaleźć i naprawić jeden bug
• jeśli w projekcie są jakieś frameworki, biblioteki, których nie znasz, to możesz się ich pouczyć w międzyczasie
• możesz popatrzeć na Jirę, czym się ogólnie zajmuje teraz team, żeby mieć większy kontekst i żeby wiedzieć, o czym inni mówią na spotkaniach.

Moim zdaniem ogólnie wyznaczanie "zadań" per-se jest słabe. Lepiej jest wyznanczyć cel który jest pożądany (ew. z jakimiś kryteriami), a to jak go osiągniesz to już Twoja działka.

Ja jestem na takim etapie życia, że w każdej nowej rzeczy jakiej nie znam to jak się zapytam jakiegoś eksperta oto oto i oto to będę wiedział wszystko.
Niestety nie ma nigdy nikogo kogo o to można zapytać :>

Jako junior gadaj z każdym rób robotę ktoś rozmowny i dzielący się wiedzą ci czasem jakieś hinty poda w pracy, dużo ludzi jest dobrych.

Dla zainteresowanych, już drugiego dnia dostałem ticket i mam co robić. Prawdę mówiąc, praca wygląda inaczej niż programowanie w domu – używają wielu wewnętrznych bibliotek i assetów, co zajęło mi trochę czasu na przyswojenie. Mam wrażenie, że pracuję za wolno i zaczynam odczuwać impostor syndrome. Ticket w Jirze był zaplanowany na 8 godzin, a mi zajął 14, ponieważ na bieżąco zapoznawałem się z całym projektem, bibliotekami itd

Ok @WorekNaSmieci , już wiemy że się nie przelogowales i @MaszynaDoSzycia to twoje multikonto.
Tylko po co?

WorekNaSmieci napisał(a):

Prawdę mówiąc, praca wygląda inaczej niż programowanie w domu – używają wielu wewnętrznych bibliotek i assetów, co zajęło mi trochę czasu na przyswojenie.

Na tym etapie dobrze jest zacząć robić notatki, zapisywać ważne linki itp.

Mam wrażenie, że pracuję za wolno i zaczynam odczuwać impostor syndrome. Ticket w Jirze był zaplanowany na 8 godzin, a mi zajął 14, ponieważ na bieżąco zapoznawałem się z całym projektem, bibliotekami itd

No i w takich sytuacjach nie tylko ważne jest być sprawnym technicznie i dobrze zorganizowanym, ale również trzeba umieć się sprawnie komunikować (choćby to, że jak nie będziesz czegoś wiedział, to warto zapytać o pewne rzeczy, zamiast samemu się zakopać w czymś).

Ticket w Jirze był zaplanowany na 8 godzin, a mi zajął 14

xDDD ja na praktykach miałem zadanie na 4h a zajęło mi 1.5 miesiąca - i jakoś nikt nie narzekał xD

@WorekNaSmieci Tak - niestety - to normalne. I tak jak ktoś już wcześniej napisał: jak będziesz kiedyś po drugiej stronie to zrozumiesz dlaczego tak jest. I wtedy sam potwierdzisz, że tak już musi być.
Poza tym staraj się nie przeszkadzać ale zadawać pytania.
Poznawać projekt, czytać kod itp.

Sprytnie można przeglądać cudze już zrealizowane zgłoszenia i sprawdzać co było w nich stworzone, poprawione, dopisane.
Ew. dokleić się do jakiegoś programisty i gapić się jak on rozwiązuje zgłoszenie. Przy czym oczywiście porozmawiać z nim wcześniej czy nie ma nic przeciwko he he.
Czasami jak będzie rozwiązywał zgłoszenie to może ci trochę opowie jak ten projekt jest zbudowany lub jego fragment.

Twórz sobie notatki, zapisuj pytanie itp. itd.

Tylko nie przeszkadzaj innym nadmiernie. A jak ktoś ci powie, że masz to napisać w taki a nie inny sposób - to tak zrób. Bo bardzo możliwe, że tak właśnie trzeba.
// Poznałem kiedyś w pracy świeżaka, który mając stworzyć w Java funkcjonalność istniejącą w skrypcie PHP - po prostu przepisywał bezmyślnie kod a w locie go tłumacząc na język Javy. Ten zawodnik nie chciał się posłuchać jak ma podejść do problemu, nie zadawał pytań.

A jak ktoś ci powie, że masz to napisać w taki a nie inny sposób - to tak zrób

Tutaj się zgodzę, ale potrzebny jest większy kontekst. Zdecydowanie zrób, na początku, żeby nie gadali - ale jeśli coś ci "śmierdzi" albo wydaje się dziwne, to wróć z tym na forum i zapytaj.

Na moich praktykach trafiłem na mnóstwo gównokodu, często już zaschniętego, w którym trzeba było rzeźbić wykałaczką, żeby się to nie zawaliło. A był to zwykły CRUD - więc gdzie problem? Taki, że główny programista (programiści) powymyślał sobie (pewnie w kiblu) wszelkiego rodzaju patterny i konwencje, których nie wolno było naruszyć w żadnym wypadku, a o których pewnie przeczytał kiedyś na telefonie w kiblu.

Więc nie bierz do siebie zbyt serio, jak ktoś ci mówi, że coś musisz tak zrobić, a nie potrafi ci wyjaśnić, dlaczego tak a nie inaczej. Nawet jak wydaje ci się, że nie rozumiesz a on przecież jest mądrzejszy. Nie zawsze. Często starzy wyjadacze po prostu powielają te same błędy, bo tak się nauczyli i przecież działa. Do dzisiaj pamiętam parę rzeczy, które z perspektywy czasu wydają mi się totalnie absurdalne, może napiszę kiedyś.