Upierdliwy współpracownik w firmie

Mała przestroga, obsługa juniora nie powinna polegać na dawaniu odpowiedzi. Tu wiele osób przepala czas, bo w pewnym sensie próbuje wyręczyć juniora, poprzez ograniczenie pola pracy do wykonania. Taka inicjatywa wydaje się dobra, ale to bardziej upośledza i narzuca płytkie powierzchowne myślenie, które doprowadza do rozwiązywania problemów w niedbały sposób. Przyjmowanie schematów tak po prostu bez większej refleksji ogłupia, prowadzi do nadmiaru, przerostu formy nad treścią. Więc z tygodnia na tydzień obsługa juniora coraz bardziej mija się z celem.

Zależy o co junior pyta, jeśli o domenę bo nie ogarnia zbyt płytkiego opisu logiki biznesowej w user story to jak najbardziej danie opodwiedzi ewentualnie call i wytłumaczenie mu części domenty związanej z jego story jest jak najbardziej na miejscu, jeśli pytanie dotyczy jak zrobić component, który jest generykiem i nie będę duplikował kodu bezsensu to rzeczywiście tracenie czasu bo takie rzeczy ewentualnie dostanie na PR jako feedback.

Wracając do pytań o domenę/logikę biznesową to część porządnego i dobrego onboardingu i prowadzenia dobrej dokumentacji, brak tych dwóch potem powoduje, że ludzie sporo pytają albo po roku nie rozumieją połowy domeny i rozkładają się na na przykład prostym bug incident ze źle działającą logiką biznesową, gdzie nie wiedzą od czego zacząć ani dlaczego często ta logika jest błędna, bardzo pięknie wtedy widać, że ktoś goły jest z domeny.

U mnie w projekcie wbił pół roku temu senior, który jak dostał taska z właśnie bug report incident, który obejmował źle działającą logikę biznesową, która wymuszała na użyciu traceId i przeleceniu po 5 mikroserwisach i analizowaniu co wpada do Kawki do z prawie płaczem na koniec sprintu stwierdził, że nikt go nie wdrożył i nie za bardzo zna domenę i nie wie jak rozwiązać problem :)

takie pytania są ok?
pytanie się o to w jakiej klasie znaleźć metodę
nie rozumie opisu zadania, nie wie jak zacząć
nie umie znaleźć elementu na stronie
nie zna jednego frameworka którego używamy i mówi żeby wytłumaczyć mu kod
nie wie w którym miejscu utworzyć klasę
nie wie której metody użyć lub czy w ogóle może użyć takiej metody
nie wie na którym poziomie i w którym miejscu dodać kod

No to są pytania, które mógłby nawet zadać senior żeby nie wprowadzać spaghetti

nie rozumie opisu zadania, nie wie jak zacząć

Powiem tak nie wiem jak na frontendach ale na backendach często ze świeca szukać dobrze napisanych opisów tasków. Generalnie jak wpada bug/feature nie raz dopytuję testera/architekta co mieli na myśli w tikect. O ile jeszcze featuery trochę tekstu mają i to raczej szczegóły to bugi dramat. Jedna linia która nic nie wyjaśnia, albo czasami dużo lini będących już wstępną analizą ale nie zawsze jasno opisane co tak naprawdę nie działa w jakich warunkach. Ja jak coś czasami jak sam odkopię X letni bug to klasyka krótki opis + expected result i current, DoD itp. przy grubych featurach nawet pisze test case dla platform których nie mam w domu żeby potestować(pisał bym najchętniej wszędzie ale czas....), confluance z opisem.

Ale nie wiem jak wy macie ale tu przytaczam co spotkałem już nie raz. Weźcie chłopaka na retro, pogadaj z nim przed spotkaniem że ma powiedzieć co nie gra i szukacie rozwiązania. Jak przez 3 miesiące będzie zamiast się poprawiać to będzie olewał to sajonara i tyle.

edit:
nie wiem też jak skomplikowana jest domena, przy olbrzymich systemach które są zaplątane to autorzy się potrafią gubić.

Dodam jeszcze że podczas CR gdy ma zakomentowany kod który ma zmienić to pyta się jak ma poprawić bo nie rozumie i zdarza się że w końcu robi nie tak jak potrzeba

Dr4g0n99 napisał(a):

takie pytania są ok?
pytanie się o to w jakiej klasie znaleźć metodę
nie rozumie opisu zadania, nie wie jak zacząć
nie umie znaleźć elementu na stronie
nie zna jednego frameworka którego używamy i mówi żeby wytłumaczyć mu kod
nie wie w którym miejscu utworzyć klasę
nie wie której metody użyć lub czy w ogóle może użyć takiej metody
nie wie na którym poziomie i w którym miejscu dodać kod

IMO sensowne pytania (większość) - Jeśli miał kiepskie wdrożenie (o ile jakiekolwiek).

Dr4g0n99 napisał(a):

takie pytania są ok?
pytanie się o to w jakiej klasie znaleźć metodę
nie rozumie opisu zadania, nie wie jak zacząć
nie umie znaleźć elementu na stronie
nie zna jednego frameworka którego używamy i mówi żeby wytłumaczyć mu kod
nie wie w którym miejscu utworzyć klasę
nie wie której metody użyć lub czy w ogóle może użyć takiej metody
nie wie na którym poziomie i w którym miejscu dodać kod

Przyznam, ze raz bylem w projekcie tak zaprojektowanym przez 3 letniego architekta samozwańca, że i ja nie wiedziałem za bardzo odp na te pytania ale poszedłem ścieżka bardziej mi lubianą, zrobię w założeniu podobnie co już mają a jak będą jakieś problemy na PR to ewentualnie jakaś może fajna dyskusja i burza mózgów się zrobi i wszyscy na tym skorzystamy i ja tez się nauczę ich projektu i podejścia.

No niestety "architekt" nie był skory do konstruktywnej dyskusji ani połowa teamu, z którym robiłem, w zasadzie to wyczuwałem jakąś niechęć i zagrożenie które czuli wobec mnie jako jedynego zewnętrznego kontraktora.

Wkrótce po tym jakieś 3 miechy nie chciało mi się z nimi użerać i poprosiłem o zmianę projektu i obecnie jest dużo lepiej :)

Dr4g0n99 napisał(a):

Zawsze kiedy dostaje zadanie robię z nim calla i tłumaczę mu co ma zrobić. Średnio dzwoni 2-3 razy dzienne do mnie bo chce się o coś zapytać.

Wygląda na to, że chu.owo tłumaczysz :-D

Za pracę z juniorami, którzy pytają o wszystko powinien być dodatek finansowy.
Nope, tu poland, tu ma być tanio i bylejako, byleby tanio.

[quote=Dr4g0n99]Średnio dzwoni 2-3 razy dzienne do mnie bo chce się o coś zapytać.[/quote]

Pracownik ma obowiązek wykonywać pracę tak jak mu zleci pracodawca. Pracownik wyszedł z założenia że chce pracę zrobić dobrze i dlatego dzwoni 2-3x dziennie (czyli średnio co 2.6 do 4 godzin). Sama na początku kariery jako C++ Embedded Developer też chodziłam do kierownika nawet 4x dziennie i jakoś cenili sobie potem ze mną pracę przez 11 lat ponieważ byli zadowoleni z produktu.

Gorzej gdyby pracownik zatajał, że czegoś nie wie lub nie umie - potem zysk z niego żaden mimi, że rzyć nie była zatruta. Rozważ więc nie tylko wygodnictwo (nikt nie dzwoni), ale także to, że pracownik ma być potem wydajny, znać produkty firmy, znać używane frameworki i biblioteki i wiedzieć jak ma wykonywać pracę.

Co wolisz takiego, co będzie pytał CzatGPT?

Proponuję jednak przejście z komunikacji ściśle synchronicznej (telefon) na asynchroniczną. Czyli pracownik podchodzi do Ciebie i zgłasza że ma problem, a ty podchodzisz do niego gdy skończysz aktualne zadania albo też zada pytania mailem, a ty mu na nie odpowiesz lub przyjdziesz poinstruować. To jest normalne, że juniorzy pytają...

Ciesz się, że nie zaprasza Cię za każdym razem na kamerki (MS Teams, Google Meat) - niezmiernie wk...jące. Nie wiem skąd to uzależnienie od pobierania danych biometrycznych wśród rekruterów - ale takim dziękuję od razu.