[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?

[Elbrus]

@Mirste: O czym ty #!$%@? do mnie #!$%@? Jacek?

[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

[D.....a]

@Mirste jeśli tamten nie daje się nauczyć lub źle reaguje na zwracanie uwagi, to jednak bym przełożonemu spróbował na początku zasygnalizować. Nie jechać, tylko jaka uwaga niby mimochodem. Potem jeszcze druga za jakiś czas. Żeby nie było, żeś naopowiadał nie wiadomo co. Jeśli jest więcej osób mających styk z jego kodem, to porozmawiaj z nimi co sądzą i dobrze jakby tak samo postąpili.

Jeśli to nie pomoże i nie przyniesie żadnych rozwiązań,

[yhbgrobdoivbvwamsv]

@Mirste: Brzmi jak słabe coverage testów i polski kult #!$%@?. 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 że

[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?