[Mirste]

Pracuję zdalnie w zagranicznym zespole. Od razu zaznaczam, że nie jestem liderem tego zespołu.

Mamy takiego kolesia, co nie ogarnia kompletnie. Przykładowo: myli mu się koncepcyjnie relacja many-to-one z dziedziczeniem. Albo oddaje commita, który nie działa w ogóle - kod pracuje na tabelkach, które nigdy nie istniały w żadnym świecie, ale testy unitowe przeszły, więc w czym problem? Chce zamknąć taska, a nie stworzyć kod, który będzie działać na produkcji. Code review zajmuje mi kilka razy więcej czasu niż gdybym to miał sam napisać - wraca kilka razy z tym samym błędem.

Pracowałem już w życiu z kilkoma takimi osobnikami i już wiem, że praca z nim to strata czasu. Są ludzie, których można nauczyć i są ludzie, którzy powinni zmienić zawód.

No i teraz pytanie:
Jeśli pracujecie zdalnie, to jak sygnalizujecie taki problem ludziom na górze? Nie mam na tyle autyzmu, żeby pisać maila z donosem na kolegę, ale okazji do porozmawiania przy kawie nie ma.

#programowanie

[Hissis]

@Mirste: aha no widzisz, a ja w ogóle nie pracuje i nie mam problemów żadnych
Można? Można.
Z fartem

[Hektorrr]

@Mirste: Nawet jeżeli nie jesteś liderem to dzielenie się wiedzą w zespole chyba w większości firm jest pożądane.

Próbowałeś z nim rozmawiać, że to co wysyła ma sporo braków i sugerować mu jakieś materiały żeby podciągnął umiejętności?

[Rhodium]

Byłem w sytuacji gdzie awaryjnie dorzucono mnie do zespołu gdzie musiałem ratować projekt bo trzeba było wdrażać a nic nie działało. Warstwa którą miałem się zająć była tworzona głównie przez typa, który miał gdzieś wszystkich - olewał komentarze z code review bo zawsze wiedział lepiej, stosował bardzo złe praktyki bo sobie tak zinterpretował założenia, generalnie bardzo ciężki do współpracy gość. Odbyłem kilka rozmów z zarządem i go przesunęli lub wywalili gdzie indziej

[yhbgrobdoivbvwamsv]

@Mirste: Brzmi jak słabe coverage testów i polski kult z----------a. Niech se chlop dziubie

[Krolik]

@Mirste: każde kolejne review tego samego taska rób mu później. Pierwsze od razu, ale kolejne niech trochę poleży. Exponential backoff. Bądź surowy na review i jak trzeba to odrzucaj nawet 10 razy. Review są publiczne, więc jeśli tylko macie sensownego managera, to sam zauważy że tamten nie dowozi tasków i z nim pogada. A oczywiście na swoim 1:1 z szefem przy okazji możesz wspomnieć, że robisz Nty raz review i

[Mirste]

@Dzyszla: dzięki za odpowiedź. Generalnie tak bym robił w pracy stacjonarnej.

Ja mam tu problem, że praca jest full remote, manager jest nietechniczny i nie przeprowadza 101. Jesteśmy losowo wybraną grupą programistów, którzy mają klepać taski. Ja pracuję tu dopiero 3 miesiące. Wiem, że jako nowy, robienie dymu na starcie to słaby pomysł.

[Krolik]

@Mirste: ale chyba nie trzeba być technicznym managerem aby zrozumieć że kod oddany przez programistę nie działa? I nawet jeśli nie robi 1:1 to chyba jakieś spotkania są czasem? Nie macie żadnego planowania, żadnych podsumowań co zrobiliście? Bo na takim spotkaniu raczej by wyszło jak jedna osoba nie ogarnia i nie dostarcza.

[D.....a]

@Mirste: A, to trochę zmienia postać... Brak bezpośredniego kontaktu i krótki staż zdecydowanie utrudniają. A nie macie jakichś meetingów w realu choć raz na miesiąc?

[Andrijek]

@Mirste: czy macie w zespole Definition of Done? Tam można by zawrzeć element ze zadanie jest ukończone, gdy przejdzie review przez min 2 osoby, lub odpowiednie testy związane ze zmianami.

Dodatkowe pytanie, czy macie retrospektywe w zespole by pogadać o tematach zwiazanych z wasza praca?