Jak wygląda początek pracy juniora na okresie próbnym

0

Cześć, załóżmy, że ktoś znajduje pierwszą pracę jako junior. Ta osoba nie jest jeszcze oczywiście w pełni samodzielna, choć ma kilka projektów na stacku ASP.NET Core + Angular. Czy na okresie próbnym taki junior jest już "ciśnięty", by pisać kod, który potem ma iść na produkcję, czy może te pierwsze 3 miesiące, to trening i wdrożenie? Chodzi mi o to, jak to wygląda w jakimś korpo/małym startupie.

Pytam, bo jako frontendowiec na okresie próbnym byłem już ciśnięty i wszystko szło na produkcję, ale w sumie to był januszex, więc to zupełnie inna sprawa. Jestem ciekaw jak to wygląda w normalnej firmie.

3

Jeśli kod przejdzie Code Review to czemu nie?

50

3 miesiące to tak na prawdę czas wdrożenia. Firma firmie nie równa i ten proces wygląda inaczej. IMO jakieś proste taski mogą się już pojawić (oczywiście rozwiązanie skontrolowane przez bardziej doświadczonych kolegów).

2
wearerome napisał(a):

Cześć, załóżmy, że ktoś znajduje pierwszą pracę jako junior. Ta osoba nie jest jeszcze oczywiście w pełni samodzielna,

Nie musi. W pełni samodzielna osoba może dostać co najwyżej łatkę osoby, która nie umie się komunikować i pracować w zespole. Firmy oczekują tylko częściowej samodzielności. To co poniżej (totalna niesamodzielność, gdzie kogoś trzeba niańczyć) albo powyżej (bycie w pełni samodzielnym i robienie po swojemu bez szukania pomocy czy synchronizacji z innymi) jest zwykle widziane negatywnie.

1

Nieważne junior czy senior, każdy pracownik potrzebuje czasu żeby się wdrożyć do projektu i w tym firma powinna zawsze aktywnie pomagać. Jeśli ktoś ma małe doświadczenie, to wdrożenie będzie pewnie trwało dłużej, ale nie widzę przeszkód by jego elementem była realizacja prostszych zadań które po CR pójdą na proda tylko z tym założeniem, że review i kolejne iteracje poprawek powinny być traktowane przez cały zespół jako proces nauki i wdrożenia pracownika.

4

Pierwsze 3 miesiące juniora wyglądają tak że junior ma brązowo w gaciach że go zwolnią i próbuje się wykazać a wszyscy inni mają to w czterech literach, czasami zapominają że istnieje i są zdziwieni jak coś faktycznie zrobi. Ewentualnie podirytowani ciągłymi pytaniami.

0
wearerome napisał(a):

Ta osoba nie jest jeszcze oczywiście w pełni samodzielna,

To nie jest juniorem tylko stażystą jeszcze. Junior jest samodzielny.

48
LitwinWileński napisał(a):
wearerome napisał(a):

Ta osoba nie jest jeszcze oczywiście w pełni samodzielna,

To nie jest juniorem tylko stażystą jeszcze. Junior jest samodzielny.

Przecież napisał w pełni samodzielna i jest to jak najbardziej prawda. Junior ma prawo nie wiedzieć wszystkiego, stąd jest juniorem i nie jest W PEŁNI samodzielny.

0

Nie ma sensu nie puszczać kodu na produkcję, po to jest code review i testy żeby wyłapać błędy i dzielić się wiedzą.

Przy code review nie ma czegoś takiego że "nie przejdzie", poprawki wrzuca się w tylu rundach dokąd nie będzie dobrze. Jest oczekiwane że osoba która nie ma doświadczenia będzie tych rund potrzebowała więcej niż inni, ale to też nie jest tak że jak tech lead puszcza PRa to wszyscy się kłaniają przed majestatem i walą approvy bez myślenia, standard jest podobny. Jeśli kod będzie wystarczająco masakryczny to ktoś pewnie z tobą siądzie i zrobi pair programming. Jedynym oczekiwaniem jest to że wraz z czasem czegoś się nauczysz i ta liczba potrzebnych poprawek spadnie.

W większości zespołów w których byłem zakładało się że new joiner, niezależnie od poziomu, przez przynajmniej miesiąc będzie generował negatywne velocity, bo będzie ściągał czas innych osób. U juniorów ten czas jest znacznie dłuższy niż u seniorów, ale bierze się to pod uwagę.

4

Wszystko zależy do jakiej firmy trafisz i jaką mają kulturę pracy i czy pracują w pato-scrumie, gdzie jest pośpiech ciągle, to i nie ma czasu na wdrażanie Juniora.

Podam dwa przykłady z mojego życia i początków kariery, bo myślę że Juniorem się jest tak do 2 lat doświadczenia.

W jednej firmie gdzie byłem Juniorem nie było Scruma, byłem ja jako Junior + 3 Developerów już zatrudnionych. Pracowaliśmy nad utrzymaniem systemu. Wtedy mogę powiedzieć, że był to mój najlepszy okres w ogóle jaki wspominam w pracy zawodowej.

Tamci programiści mieli zawsze czas, ponieważ nie byli poganiani, miałem serio tak, że przez jakieś 2 tygodnie jak rozpocząłem pracę jeden z Developerów siedział ze mną cały czas razem przy biurku i wdrażał do projektu. Potem robiłem zadania sam, jak tylko czegoś nie wiedziałem to podjeżdżał fotelem do mojego biurka i robiliśmy Pair Programming - zawsze miał czas, czy to pod koniec dnia, czy po obiadku. Trwało tak rok czasu. Nigdy nie było żadnej spiny, nerwów i tym podobnych rzeczy, kłótni w PR'ach, toxic środowiska. Jak zrobiłem coś źle podjeżdżał na fotelu i w żartach mi pomagał nawet i nieraz do końca dnia.

Bardzo fajnie tą firmę wspominam i w sumie do tej pory żałuję że się zwolniłem.

W kolejnej firmie w której pracowałem nie była to firma produktowa, tylko był to Software House który wygrywał przetargi na jakieś projekty/aplikacje i miał swoich programistów i oni musieli robić te projekty. Takie firmy radzę unikać. Prawie zawsze jest tam dość spięty budżet i każda godzina, ba Sprint programistów są dla firmy "wydatkiem". Przekłada się to także na nacisk który się wywiera na programistach oraz to że czują presję. W tej firmie jak pracowałem, mogę to powiedzieć z czystym sumieniem w ogóle mnie nie wdrożono do projektu ponieważ w Scrumie w ogóle nie wyznaczono czasu na moje wdrożenie. Więc programiści zasuwali by dowozić zadania, a każda godzina pomocy "mi" była dla nich stratą. Pamiętam sytuację jak jeden Developer gdy się go o coś pytałem, powiedział mi że chętnie by mi pomógł ale musiałbym pogadać z Managerem o tym, ponieważ on ma zadanie które musi skończyć, a ten czas który mi poświęca nie jest wkalkulowany w jego taska XD

Wynikało to po prostu z ciśnienia na dowożenie w Sprincie, a nie uwzględniono w nim czasu na wdrożenie pracownika. Pamiętam wtedy, że doszło do kuriozalnej sytuacji, że po miesiącu bycia w projekcie wciąż nie wiedziałem jak się projekt odpala i debuguje ponieważ nikt nie miał czasu mi tego pokazać, a moja praca opierała się na łataniu prostych bugów i bazowaniu na testach integracyjnych. Jednak po 5-6 miesiącach miarka się przebrała bo poleciały pierwsze uwagi przez Team Leadera w moim kierunku, robiłem tam taska dłużej niż był "wyceniony", coś co miało 2 Story Pointy, robiłem 4 dni, coś takiego. Czyli miał dymy do mnie że wolno robię.
Teraz np. wiem i jestem tego świadom że sytuacja w powyższej firmie była toksyczna, nawet na Linkiedin jak popatrzę na rotację to wynosi tam ~1 rok.

Podsumowując na początek wyglądu pracy Juniora moim zdaniem składa się:

  • kultura pracy firmy
  • czy jest ciśnienie w Scrumie
  • możliwość wygospodarowania czasu na wdrożenie nowego pracownika
  • czy są wyznaczone deadline'y
  • dojrzałość pracownicza pracowników z którymi będziesz pracować (inaczej będzie Cię wdrażał 4 leni Senior, gwiazda konferencji i youtubów, a inaczej 20 letni Senior co niejedno na oczy widział)
  • brak ego pracowników z którymi masz pracować
0

Ja "za juniora" mialem do czynienia z trzema rodzajami podejscia:

  1. Pierwsza i na moje nieszczescie najlepsza z mojej perspektywy sytuacja polegala na tym ze, lead'em w zespole byl czlowiek, ktory mial szlaban na robienie jakiegkolwiek kodu.
    Ogarnial, architekture, CR+MR. Generalnie trzymal reke na pulsie pod kazdym wzgledem. Nie ma ze jestes junior, mid czy senior. Wszystko bylo poukladane, architektura ogarnieta, taski opisane, a lead w razie potrzeby praktycznie na zawolanie. Inormacja byla natychmiastowa, slack, bach, bach, ustalone "jedziem dalej". PM byl PM'em, a nie dozorca poganiajacym programistow - wlasciwie nawet nie wolno mu bylo nam zawracac d...py, jesl mial jakies "wonty" to zalatwial to z lead'em.
    Nie ma, ze robisz sobie swoje, a po dwoch dniach sie pojawiasz z codem, ktory co prawda dziala ale rozwala przyjeta koncepcje. Zadnych korpo meeting'ow, zwiezle dailies, plannings and reviews.
    Zespol z przewaga juniorow, skonczyl w ten sposob projekt 2 miechy przed terminem. Jako junior bardzo duzo sie nauczylem, wchodzac w projekt praktycznie bez wprowadzenia.
  2. Lead programujacy, decydujacy o architekturze, wszyscy robia sobie CR'ke, ale wlascwie trudno bylo sie doczekac na trzy kciuki, bo kazdy mial zlewke na analize cudzego kodu, a nawet jesli miales trzy ok-ejki, ale bez lead'owskiej to konczylo sie na tym ze akceptacja taska trwala w nieskonczonosc, bo lead jak w koncu zrobil CR, to tylko "w wolnej chwili", a potem znowu wpadal na 5min, znajdywal cos innego, potem znowu i znouw i znowu. Masakra, taski mogly tak lezec na border'ze az do konca sprintu, a potem sam lead opier...lal je w 5 min i pchal na testy. Poza tym taski z opisem na zasadzie jednego zdania - czyli rob jak uwazasz, a na koncu zawsze okazywalo sie ze zle. Poza tym nakladanie sie kompetencji PM i lead'a z zakresie zarzadzania projektem. Jako junior bardzo zle wspominam to doswiadczenie.
  3. Lead programujacy, ale projekt jeden z wielu ktore ogarnial, kazdy robi co i jak chce, byle dzialalo, management i tak nie ogarnia jakosci kodu. Zero architektury, CR'ki kaskadowe, taski robione po kilka razy a jakosc kodu to juz nawet nie spaghetti. Pracowalem z ludzmi ktorych tylko widzialem na daily prze 5 min dziennie i to nie zawsze, slack u kazdego nieaktywny, a na odpowiedz lead'a czy innego porgramisty czekales po 2, 3 dni. PM panoszyl sie wszedzie i biegal za kazdym z batem, lead byl wlasciwie lead'em tylko z nazwy, komunikacja byla utrudniona, zeby nie okreslic tego dosadniej. W tym przypadku, to juz byla dla mnie prawdziwa trauma.
1

Ale co to znaczy "cisnąć"? Firma zatrudnia pracownika nie po to, żeby go przez 3 miesiące wdrażać, bo niby z czego? U mnie jest parę dni na rozpędzenie się i wyrobienie dostępów do gita, później oczekuje się, że będzie robił taski. Jak nie będzie wiedział jak zrobić, to zapyta i się dowie. Wiadomo, że nikt nie wymaga od młodego, żeby rzucał się od razu w największe bagno, dostaje jakieś możliwie proste,. albo raczej mało domenowe zadania.

1 użytkowników online, w tym zalogowanych: 0, gości: 1