O IT mówi się różne rzeczy. Głównie w kontekście bardzo wysokich zarobków. Mało kto wie jak wygląda praca w takim środowisku i z jakimi problemami trzeba się mierzyć. Okazuje się, że sytuacja może mocno wymknąć się spod kontroli. Mój znajomy, z którym rozmawiałem w ubiegłym tygodniu został pomówiony o mobbing za code review.
Tak, dobrze czytacie. Mobbing za code review.
Zanim przejdę do konkretnego przypadku znajomego, przybliżę trochę samą ideę code review i z czym to się wiąże. Może to być pomocne, szczególnie osobom nie związanym z branżą IT.
Code review – smutny obowiązek?
Od jakiegoś czasu odnoszę wrażenie, że code review w większej liczbie przypadków, to trochę taki smutny obowiązek. Wiecie, lepiej klepnąć komuś kod aby mu nie podpaść (nie psuć sobie relacji w zespole czy firmie). Bo jak doda się jakieś komentarze (nie ważne jakie), to liczba „uwag” wróci ze zdwojoną siłą. Nie ma większego znaczenia jak bardzo uprzejmi czy merytoryczni będziemy.
W swojej karierze miałem kilka takich przypadków, bo jak mogłem śmieć przyczepić się do kodu principal developera będąc zwykłym, nic nie znaczącym midem.
I mamy mieszankę wybuchową. „Wysokie” stanowisko plus odpowiedni charakter i może być różnie. Albo duże ego i wiara w swoje niezwykłe skille programistyczne.
Prawda jest taka, że code review to jedyna szansa, by sprawdzić kod pod względem jego jakości. Od tej jakości będzie zależało czy:
- kod będzie łatwy w utrzymaniu,
- kod nie będzie generował bugów,
- oraz czy będzie łatwo się go modyfikowało.
To wszystko przekłada się na przyszłe koszta.
Czytaj także: Jak robić dobre code review?
Mobbing za code review
Mój znajomy, to osoba, która przykłada dużą uwagę do jakości kodu. Jeżeli widzi coś, co nie wygląda dobrze, to zwraca na to uwagę. Oczywiście wszystko odbywa się zgodnie ze sztuką. Kulturalnie, na poziomie wraz z linkami do dokumentacji. Co więcej, jest w stanie zrobić szybki call, w którym wyjaśni dokładniej w czym problem.
Podczas cyklicznych spotkań „1 on 1” jego team leader powiedział mu, że jeden członek zespołu nie życzy sobie więcej takich uwag. Jego zachowanie określił mianem mobbingu.
Dlaczego mobbing?
- Uwziął się na niego dodając mnóstwo komentarzy przy każdym pull requeście.
- Kod działał jak należy i spełniał kryteria z ticketa.
Szczególnie ten ostatni argument jest „istotny”, bo „kod działał”.
Nie muszę wspominać, że mój znajomy kompletnie nie wiedział co powiedzieć. Każdego by pewnie zamurowało. Mnie też.
Czym jest mobbing wg polskiego prawa? To działania lub zachowania dotyczące pracownika lub skierowane przeciwko pracownikowi, polegające na uporczywym i długotrwałym nękaniu lub zastraszaniu pracownika, wywołujące u niego zaniżoną ocenę przydatności zawodowej, powodujące lub mające na celu poniżenie lub ośmieszenie pracownika, izolowanie go lub wyeliminowanie z zespołu współpracowników.
Pewnie zastanawiacie się, jak zakończyła się ta historia? Nie było tutaj happy endu. Mój znajomy popracował jeszcze trochę, odpuścił uwagi do kodu, dokończył swoją robotę i jego drogi z tą firmą się rozeszły. Bez żadnych konsekwencji.
Gdyby kogoś interesowało, to był to zagraniczny (europejska firma) kontrakt (B2B), bez pośrednika.
komentarzy 14
Ciekawy przypadek. Ja z niego wyłapałem kilka faktów, które uznałbym za kluczowe – projekt zagraniczny, jeżeli mamy połączenie kilku różnych nacji to mogą zupełnie inaczej podchodzić do wykonywanych obowiązków i mieć inną wrażliwość, więc ktoś faktycznie mógł odebrać to w ten sposób.
Dalej mamy osobę, która kładzie nacisk na „jakość kodu”, bez kontekstu brzmi jakby nie ważne, gdzie ten kod się znajduje, czy to główna logika domenowa czy właśnie piszemy skrypt do zautomatyzowania jakieś procesu, który docelowo nie będzie się zmieniał zbyt często. Ja do jakości kodu podszedłbym z większym pragmatyzmem, jeżeli ROI jest niskie, potencjalnie będzie bardzo mało zmian bądź zmiana jest bardzo prosta to zysk ze zmiany jest niewielki i nie ma sensu marnować na niego czasu. Z opowieści osoba na code review wydaje się być lekkim review nazi, która nie daruje jeżeli kod nie będzie spełniał najwyższych standardów.
To czego zabrakło w mojej opinii to ustalenia standardów kodowania, skoro na code review wpada tyle komentarzy to łatwiej byłoby spisać coding guideline ustawić tool, który by ich pilnował, wtedy nie można powiedzieć, że linter mobbinguje programiste. Do tego dołożyłbym podnoszenie umiejętności miękkich, uwagi można dawać w taki sposób, że mimo iż mamy racje to ta osoba poczuje się, że chodzi nam jedynie o to by jej dowalić. Szkoda, że w tej historii zabrakło happy endu, pokojowego rozwiązania sytuacji, bo mam wrażenie, że programista w niedalekiej przyszłości znowu zderzy się z podobną sytuacją.
Ustawienie lintera to jedno (formatowanie kodu) a co innego używanie SOLID czy innych dobrych praktyk. Linter nie powie, że komponent reactowy dostane za dużo propsów (np. 5 lub 10), że call do backendu powinien być w innej warstwie abstrakcji, a nie w samym komponencie.
Miałem podobny problem gdy pracowałem dla UK. Tam mają trochę wyjebkę na pisanie kodu zgodnie ze sztuką. Nie wiem, może miałem pecha i do złego zespołu trafiłem, ale rozumiem ból tego znajomego autora wpisu.
Jestem wdzięczny każdemu kto napisze rzeczowy komentarz pod moim PR.
Autor porusza duży problem z code review na poziomie relacji między ludzkich. Ciekawym rozwiązaniem tego problemu jest zastosowanie niejawności autora kodu i osoby ten kod recenzującej. Pary zostają wybierane w sposób losowy.
Jednakże ten sposób działa efektywnie w sytuacji gdy mamy kilka zespołów pracujących nad bardzo powiązanymi rzeczami, gdzie każdy programista jest w stanie szybko zrozumieć funkcjonalność nowego kodu.
Natomiast ta „historia znajomego” to bardzo stara plotka, która przewala się po różnych forach. I jest naprawdę stara bo znalazłem wpisy sprzed 3 lat 😉
Nie jestem w stanie w żaden sposób stwierdzić czy się wydarzyła i jak bardzo została zniekształcona przez przekazywanie przez kolejne osoby, ale w obecnej formie jest śmieszna i ciężko uwierzyć w jej prawdziwość.
Mało wiarygodny ten wpis… Czytam go, z wypiekami a tu nagle koniec.
Anyway.. Środowisko SW często składa się z nad wyraz dalikatnych ludzi. Przesrane
A czy pair programming nie pozwala na pominięcie code review?
Dla mnie to jest bardzo smutny przykład niedziałającego zespołu z dość słabym liderem. Po pierwsze nie próbował załagodzić konfliktu, po drugie powinien jasno wytłumaczyć wszystkim po co jest code review i jakiej jakości powinny być komentarze.
Dodatkowo to, że kolega nawet nie próbował rozwiązać problemu, tylko się wycofał i zaraz potem odszedł utwierdza mnie w tym, że to nie był zespół, tylko grupa devów pracująca nad wspólnym kodem. Podejrzewam, że to był tylko jeden z wielu problemów w tym projekcie.
Wydaje mi się, że bez podania przykładowej odpowiedzi, to ciężko będzie stwierdzić kto tu ma racje (a może obydwie osoby mają racje, ale przesadzają na swój sposób?). Bo zarówno ktoś może być przewrażliwiony na punkcie jakiejkolwiek krytyki (nawet tej konstruktywnej), albo reviewerowi tutaj może się wydawać, że odpowiedział właściwie, ale nie ma na tyle umiejętności miękkich by dostrzec, że powiedział coś mocno nie tak
Ja z kolei mam odwrotne doświadczenia. Zamiast merytorycznych odpowiedzi w stylu „Hej, to nie zadziała bo…” albo „Hej, warto by było poprawić to, by cośtam było lepsze” (już nawet nie wymagam linków do docsów czy odpowiedzi na Stacku), często dostawałem zjebkę o to, że nie jest to zrobione wg. uznania principala i że muszę to zmienić.
Osobiście nawet bym nie przekazywał takiego feedbacku bez uprzedniego zbadania sprawy. Istnieje kilka definicji mobbingu i moim zdaniem najbardziej oddająca rzeczywistość jest taka, że: „szukasz na kogoś haków, celem eliminacji go ze środowiska, wszelkimi możliwymi sposobami”. Przykładem takiego działania może być stawianie zadania przed kimś i odbieranie narzędzi do wykonania tego zadania np.: przeciążanie zadaniami i wyciągnie akcji dyscyplinarnych na podst. nie dostarczanych rezultatów.
Potrafię sobie wyobrazić sytuację w której ktoś zgłasza upierdliwe i ciężkie/duże zmiany do pull requestów stosunkowo późno co w posty sposób przekłada się to na opóźnienia. To rzutuje potem na ocenę pracownika, którego kod jest przeglądany. Ewentualnie podczas odczytu ktoś na przykład podnosi ton/krzyczy/żywa epitetów/ stawia kąśliwe uwagi słowne bądź pisemne (paleta
W dobie wszechobecnych snowflake`sów domniemuję, że tutaj zarzut był o nadmierne czepianie się odnośnie jakości kodu. Zacząłbym od tego że celem Code Review (CR) jest właśnie czepianie się. Poza tym to, że ktoś zgłosił uwagi nie oznacza że one musza wejść w życie. Decyzja jest przecież podejmowana gremialnie przez wszystkich uczestników procesu.
Myślę, że najlepszą praktyką jest „most respectful approach” czyli założenie że druga strona (nieważne czy przeglądający czy autor) robią pewne rzeczy w dobrej wierze.
Jako manager nie przekazałbym takiego feedbacku bez dogłębnego zgłębienia sprawy. Samo zgłaszanie uwag do kodu w żaden sposób nie uważam za czepianie się a co za tym idzie formę mobbingu. Pytanie o szczegóły dot. formy przekazywania.
Imho najgorszy scenariusz to stawianie dobrych relacji wewnątrz zespołu i udawanie, że wszystko jest ok kosztem jakości produktu i degradacji kodu. To jest strategia bardzo krótkoterminowa i prędzej czy później wychodzi bokiem co oznacza że trzeba za nią zapłacić najczęściej wysokim attrition w zespole który nie chce marnować czasu na amatorszczyznę 🙂
To jest trochę tak jak z większością Scrum Masterów, którzy po pojawieniu się w zespole pierwsze o co dbają to fajna atmosfera i miło spędzony czas. Z tego jakość produktu nie wyniknie samoistnie. Natomiast z dobrej jakości jak najbardziej wynika poczucie dobrze spełnionego obowiązku, wzrost samooceny, mniejsza ilość czasu spędzonego nad defektami co niemal wprost przekłada się na dobrą atmosferę pracy.
Niech każdy pisze kod jak mu pasuje i tyle. CR to strata czasu.
Lol. No pewnie. Niech każdy jeździ po drodze jak mu się podoba… No i wiadomo, że żaden programista nie popełnia błędów. CR nigdy nie prowadzi do ich wykrycia.
Nie trudno domyślić się jaki światopogląd ma osoba pomawiająca o mobbing. Takie dorosłe dzieci odklejone od rzeczywistości nie nadają się do żadnej pracy.
> Wiecie, lepiej klepnąć komuś kod aby mu nie podpaść (nie psuć sobie relacji w zespole czy firmie)
Jeśli panuje taka kultura pracy, to nie ma w ogóle po co tego review prowadzić, bo faktycznie to strata czasu. Skoro i tak każdy robi co chce. Cały ten akapit opisuje sytuację patologiczną, która powinna zostać rozwiązana na wyższym poziomie.
Robię pewnie kilkanaście, czasem nawet kilkadziesiąt CR tygodniowo. Bycie super-miłym i cackanie się w takim wypadku, to jest strata czasu. Ale nigdy z tego powodu nie doszło do żadnej scysji, bo każda osoba wie, że może ze mną porozmawiać i sprawę wyjaśnić. A co pewnie ważniejsze, ja też potrafię się przyznać do błędu, jeśli czasem sam nie ogarnę. No i nigdy nie idę na noże o styl 🙂
Dla mnie kluczowe w tym artykule jest „Oczywiście wszystko odbywa się zgodnie ze sztuką”. Problem w tym, że nie ma jednych jednoznacznie zdefiniowanych reguł pisania kodu. Są jak to mówią „różne szkoły”. Oczywiście wiem, wiem że jest SOLID, wzorce, itd.
Znam to z autopsji bo ostatnio zdarzyło mi się pracować w kilku zespołach programistów i ten sam kod był dla jednych nie do przyjęcia, dla drugich całkiem czytelne i ok.
Dobrą praktyką w takiej sytuacji było by przy tworzeniu zespołu albo włączaniu do niego nowego pracownika, jasno określić „jak się bawimy” – często już w tym momencie okaże się kto do zespołu pasuje a kto nie.