Pytanie:
Jak radzić sobie z wysoce produktywnym pracownikiem, który reaguje niezwykle emocjonalnie na recenzje kodu?
Cleatus Contour
2016-12-09 20:32:56 UTC
view on stackexchange narkive permalink

Obecnie pracuję w mniejszym środowisku jako menedżer zespołu. Wszyscy w zespole są bardzo utalentowani i wykonują swoje zadania, ale mamy kogoś, kto jest znacznie lepszy od kogokolwiek, kogo spotkałem w swojej 40-letniej karierze. Jest deszczowcem rozwoju oprogramowania. Zaraz po zatrudnieniu i po dwóch tygodniach rozwidlił nasz kod źródłowy i zdołał ukończyć prawie wszystkie zaległe pozycje, aby dowiedzieć się o aplikacji. Resztę czasu spędził nawet jako mentor dla naszych „starszych” programistów. Przed nim walczyliśmy o przetrwanie i po prostu wiązaliśmy koniec z końcem.

Jednak jest pewien haczyk. Nasze przeglądy kodu wyglądają następująco:

Pracownik A - Dlaczego nazwałeś tę zmienną „tamtą”? Myślę, że powinniśmy spróbować czegoś innego.

Rainman - co ...?

Pracownik B - To jest dla mnie dość zagmatwane. To nie jest kod, ale po prostu ciężko mi to obejść. Czy możesz zamieścić komentarz opisujący, co się ze mną dzieje?

Rainman - (Ciężki oddech ... parskanie)

Pracownik A - Ogólnie myślę, że to dobrze, ale czy mógłbyś upewnić się, że oznaczasz swoje zameldowania X, abyśmy wiedzieli, do kogo należy?

Rainman - (Zaczyna krzyczeć jak a banshee)

Stamtąd musi iść do domu na cały dzień, aż do następnego ranka, kiedy wszystko w porządku. Powrót do domu na cały dzień jest w porządku , biorąc pod uwagę góry pracy, które w jakiś sposób wykonuje podczas tych kilku godzin, w których nie płacze. Dzieje się to kilka razy w tygodniu. Inni pracownicy właśnie to zaakceptowali i już im to nie przeszkadza i odbyłem z nimi wiele spotkań, aby to zapewnić.

Moje pytanie brzmi, jak mój zespół i ja możemy osiągnąć ten sam poziom emocjonalny kogoś, kto jest prawie niezastąpiony i nie mam zamiaru się go pozbyć? Chciałbym uzyskać wskazówki, jak go uspokoić, ponieważ nie mam w tym doświadczenia.

Zakładając, że jest to prawdziwa sytuacja, a nie jakaś fikcja zainspirowana [tym ostatnim pytaniem] (http://workplace.stackexchange.com/questions/81100/), co już zrobiłeś, aby spróbować rozwiązać problem?ten pracownik?
Możesz również rozważyć aspekt [Bus Factor] (https://en.wikipedia.org/wiki/Bus_factor).Jeśli reszta zespołu nie będzie w stanie utrzymać kodu, będziesz w świecie zranienia, jeśli kiedykolwiek odejdzie (np. „Potrącony przez autobus”).
Przejrzyj * kod *, a nie * kodera *;być * bezosobowym * (policz liczbę „Ciebie” i „Twojego” w komentarzach do recenzji pracownika A i B).Nie krytykuj, nie potępiaj ani nie narzekaj.Zobacz [** jak mogę być miłym recenzentem? **] (http://meta.codereview.stackexchange.com/q/2499/23788) w Code Review Meta.
Komentarze nie służą do rozszerzonej dyskusji;ta rozmowa została [przeniesiona do czatu] (http://chat.stackexchange.com/rooms/49921/discussion-on-question-by-cleatus-contour-how-to-handle-a-highly-productive-empl).
Z pewnością miałbyś * jakieś * podejrzenie o tym zachowaniu przed zatrudnieniem go, tj. Podczas procesu rozmowy kwalifikacyjnej.Nie zadawałeś mu wtedy żadnych pytań?
Za krótkie na odpowiedź, ale: (a) zmniejsz liczbę recenzentów, zacznij od jednego do jednego i poprawiaj w razie potrzeby;(b) w twoim scenariuszu nie dałeś mu czasu na odpowiedź na pierwsze pytanie przed kontynuowaniem.Nie rób tego.
Proszę zobaczyć moje komentarze w tej odpowiedzi dotyczące tego, co myślę o recenzjach kodu, takich jak ta, którą opisujesz: http://workplace.stackexchange.com/questions/20778/how-do-i-raise-a-quality-concern-when-there-is-a-contentious-history/20779#20779
Jeśli jest taki dobry, pominęłabym dla niego przegląd kodu.Niech reszta twojego (wyraźnie beznadziejnego) zespołu przejrzy / zmodyfikuje kod po jego popełnieniu, jeśli naprawdę tego chce.
Siedemnaście odpowiedzi:
Wesley Long
2016-12-09 22:18:05 UTC
view on stackexchange narkive permalink

Zacznijmy od zrobienia około dwóch kroków do tyłu:

Jeśli masz zespół, w którym znajduje się tak impas, że jedna osoba może dokonać opisanego postępu, oznacza to, że masz zespół dysfunkcyjny. Nie jest po prostu możliwe, aby jedna osoba była o wiele „lepsza” niż grupa utalentowanych profesjonalistów. Coś tam jest naprawdę nie tak. Albo masz problem organizacyjny, który ogranicza ich umiejętności, albo nie masz talentu na takim poziomie, jaki uważasz, że masz. To jest główny problem, z którym musisz się zmierzyć.

Ale jest też kwestia zarządzania talentem tej osoby. Na wszelki wypadek przyznam, że jest o rząd wielkości bardziej wykwalifikowany i wnikliwy niż ktokolwiek inny w twoim zespole. Jeśli to prawda, musisz wziąć najbardziej uzdolnioną emocjonalnie osobę ze swojego zespołu i wyznaczyć ją, aby „izolowała” tę osobę.

Przede wszystkim przestań nazywać go „Rainmanem” - jeśli odwołują się do filmu Dustina Hoffmana, to odniesienie to wiąże się z dużym bagażem, zarówno pozytywnym, jak i negatywnym. To „zaszufladkuje” go w Twoim umyśle oraz w umyśle Twojego personelu. Ta osoba to osoba, która może mieć problemy ze zdrowiem psychicznym. To nie znaczy, że możesz na niego patrzeć z góry. Nie patrzyłbyś z góry na osobę po amputacji ani na parapalegię, więc okaż tej osobie taki sam szacunek. Jeśli zamierzasz szanować talent, szanuj również osobę.

Po drugie, znajdź sposób, aby go zintegrować. Niech będzie genialny, ale kiedy przyjdzie czas na przegląd kodu, poproś „izolatora” o komentarz i zmień nazwę w razie potrzeby oraz wyjaśnij utalentowanemu pracownikowi: „Twoja praca jest genialna. Jest tylko kilka rygorów, które musimy zrobić aby zintegrować go z naszym procesem, tak aby był dostępny dla naszych młodszych programistów. Steve pomoże to osiągnąć i pomoże Ci w utrzymaniu „bałaganu” spod twoich stóp. " I zanim się zorientujesz, Steve zrozumie znacznie więcej niż ktokolwiek inny i miejmy nadzieję, że podniesie poziom umiejętności całego zespołu.

Wreszcie - kiedy to się rozwija, przyjrzyj się swojemu „staremu” zespołowi długo i krytycznie. Coś tu jest nie tak. Nawet wspaniale utalentowany programista nie powinien mieć aż tyle miejsca na dokonanie tak ogromnej zmiany w Twoim zespole.

Po prostu do Twojej wiadomości, „zaklinacz deszczu” lub „człowiek deszczu” od dawna jest terminem używanym na określenie osoby, która wnosi do firmy wiele spraw, więc pseudonim używany przez OP może równie dobrze nie mieć nic wspólnego z filmem o tej nazwie.(Którego nigdy nie widziałem, przy okazji.)
Komentarze nie służą do rozszerzonej dyskusji;ta rozmowa o programistach 10x została [przeniesiona do czatu] (http://chat.stackexchange.com/rooms/49945/discussion-on-answer-by-wesley-long-how-to-handle-a-highly-productive-pracownik-b).
+1 za „Jeśli chcesz szanować talent, szanuj również tę osobę”
Kate Gregory
2016-12-09 21:01:45 UTC
view on stackexchange narkive permalink

Czy próbowałeś zapytać go, jak uczynić recenzje kodu bardziej znośnymi dla niego? Korzystając z przykładów, które wymieniłeś powyżej, co by było, gdyby poszły bardziej w ten sposób?

  • Pracownik A - ta zmienna X, myślę, że może byłoby to bardziej zrozumiałe dla wszystkich, gdyby była to TotalSalesThisWeek. Czy mogę zmienić jego nazwę?

  • Pracownik B - [zadaje pytania, dopóki nie zrozumie kodu i nie uchwyci brakującej informacji]. Czy mogę dodać komentarz podsumowujący to, dla następnej osoby, która to czyta?

  • Pracownik A - oznaczyłem Twoje miejsca zameldowania znakiem X, abyśmy wiedzieli, gdzie to jest należy. Jeśli pamiętasz, aby oznaczyć go tagiem, nie zobaczysz zmiany po zarejestrowaniu się

Wzorzec, który widzę w tych, jest taki, że wszyscy pytacie go raczej o otwarty koniec " napraw tego rodzaju pytania po skrytykowaniu jego pracy w jakiś sposób. Chociaż nie znam nikogo, kto by płakał z tego powodu, znam ludzi, którzy byliby zirytowani. Na przykład powiedzenie mi, że mój kod jest mylący, zawstydziłoby mnie, a prośba o komentarz w celu wyjaśnienia może być naprawdę śmieszna - jeśli wyjaśnienie jest długie na stronach, nie jest to komentarz, prawda?

Normalnie nalegam, aby osoba, która wykonała pracę w sposób niezgodny ze standardami grupy, była tą, która to naprawiła. Ale w tym przypadku myślę, że poproszenie innych o dokonanie zmiany będzie bardziej praktyczne. Z biegiem czasu może zdecydować się na dostosowanie swojej pracy, aby zapobiec tego rodzaju prośbom, lub nie.

Ale to powiedziawszy, może być tak, że obecny układ w rzeczywistości działa dla wszystkich. Denerwuje się i czasami wraca do domu, ale jeśli zmieni nazwę zmiennej, doda komentarz i oznaczy checkin, kiedy wróci następnego dnia, więc masz czysty kod, a reszta zespołu zaakceptowała jego różnice z wzruszając ramionami, nie masz nic do naprawienia. Jeśli jednak twoja baza kodu nie jest czysta, sugeruję, aby recenzenci kodu zaproponowali poprawkę w przyjemny sposób i sprawdzenie, czy to w ogóle obniży presję emocjonalną.

Naprawdę podoba mi się ta odpowiedź.Inną rzeczą, o której bym pomyślał, jest to, czy problem jest związany z interpersonalnym charakterem tych próśb w czasie rzeczywistym.Niektórzy ludzie naprawdę mają trudności ze zrozumieniem komunikacji werbalnej, języka ciała i innych wskazówek, które mogą powodować, że ich reakcja jest tak nietypowa.Może miałbyś więcej szczęścia w rozwiązywaniu tego rodzaju problemów za pośrednictwem pisemnej komunikacji.Powinno to zminimalizować stres i presję oraz dać mu czas na przemyślenie i przetworzenie pytania / prośby przed udzieleniem odpowiedzi.
Myślę, że to dobra odpowiedź, ale to zachowanie _ biednego syna_ naprawdę mnie boli.Nie mogę powstrzymać się od myślenia, że inni pracownicy są z tym w porządku tylko w tej chwili ib) to stworzy sprawę.A jeśli ktoś inny ma problemy osobiste?Albo inny rodzaj choroby psychicznej (przy okazji nie wiem, czy on jest chory, czy nie)?Moim zdaniem ten problem musi zostać rozwiązany Z nim, chyba że planujesz mieć zespół ludzi (z możliwą dużą rotacją), którzy będą go grawitować WOKÓŁ.
Jeśli tego problemu nie da się rozwiązać w rozsądny sposób (również z szacunkiem dla innych rówieśników), wolałbym go nie zatrudniać (i / lub zatrudniać kogoś innego na tym samym poziomie, ale stabilnego emocjonalnie).Wspomniałbym również, że ** może nie jest powyżej średniej **, może twoje odniesienie jest / było poniżej średniej.Fakt, że mają coś do powiedzenia podczas przeglądu kodu, powinien świadczyć o tym, że nie jest to takie jasne.Czasami dwóch przeciętnych programistów jest lepszych (zarówno pod względem ekonomicznym, jak i jakościowym) niż 1 „ninja” i 2 pomocnicze muły ...
A co by było, gdyby odpowiedź brzmiała „Dlaczego nie nazwałeś swojej zmiennej stStrStApInf zamiast StartStopApplicationInfo?”?Albo inny rodzaj idiotyzmu?W końcu PO powiedział, że ta osoba jest w jakikolwiek sposób ponad innymi.
@BЈовић recenzje kodu to nie tylko dwie osoby.Nie popieram idiotyzmu, ale każdy ma własne zdanie na temat dobrej nazwy zmiennej.Jeśli zespół jako całość preferuje określoną konwencję nazewnictwa, to należy ją zastosować.Widziałem kłótnie UpdateCustomer vs CustomerUpdate i tym podobne - nie ładne i najlepiej rozwiązane za pomocą przewodnika po stylu.Gdy już istnieje, każdy powinien go przestrzegać - to jedna z rzeczy, do których służą przeglądy kodu.
Nie ma mowy, żeby ten układ zadziałał dla wszystkich, jeśli ktoś kończy się łzami.
@2rs2ts to łatwe pierwsze przypuszczenie, ale wszyscy świadkowie płaczu powiedzieli, że nie mają nic przeciwko temu, i chociaż pytający nie mówi tego, krzykacz wydaje się też być w porządku.Możesz nie czuć się dobrze w takim środowisku, ale przynajmniej niektórym to nie przeszkadza.Więcej informacji znajdziesz w odpowiedzi Aymor.
„krzykacz też wydaje się być w porządku” i mam do sprzedania posiadłość na nabrzeżu w Arizonie
@KateGregory Widziałem projekty wstrzymywane od tygodni z powodu nonsensów, takich jak nazwy zmiennych itp., I to jest szalone.OP nazywa pracownika „deszczowcem”, a jeśli osoba jest autystyczna, twoja odpowiedź ma jeszcze więcej sensu.+1
Odp. „Jeśli wyjaśnienie ma strony długie, to nie jest komentarzem, prawda?”, Dlaczego nie, jeśli właśnie tego potrzeba, aby jasno wyjaśnić sprawę?Często pisałem komentarze na pół strony;przez dłuższy czas komentarz odwołuje się do zewnętrznego tekstu / pliku PDF, który może obejmować kilka stron lub nawet określone rozdziały w pracach referencyjnych.
@jamesqf i OP To !, chociaż tak i nie.Ogólnie uważam, że istnieją 2 rodzaje komentarzy.Są komentarze, które mówią ci, CO robi kod, i są komentarze, które mówią ci, DLACZEGO kod to robi.Jeśli masz pół strony tego, CO to robi, to masz źle napisany kod, który powinien być refaktoryzowany, aż stanie się bardziej czytelny / nie wymaga objaśnień!.... cd.
@jamesqf i OP ... cd..... Z drugiej strony, jeśli masz pół strony DLACZEGO to robi.(Podaj dokumentację hacków, które musiałeś zastosować, aby przekazać API trzeciej części, lub teorię algorytmiczną o tym, dlaczego następujące manipulacje matematyczne są odpowiednie / konieczne / wystarczające, lub historię wyborów projektowych i wymagań dotyczących funkcji, które doprowadziły Cię donienaturalny punkt końcowy) ... wtedy ZDECYDOWANIE potrzebujesz gdzieś tego wyjaśnienia.Albo w tekście, albo jako odniesienie zewnętrzne, jak mówi jamesqf.(Preferujemy wewnętrzne linki wiki tam, gdzie jestem)
+1 za spojrzenie z perspektywy „ninja kodu”!Wchodzi do zespołu tak przeciętnego, że może samodzielnie rozwiązać dużą część ich problemów i być tak produktywnym, że nie ma znaczenia, czy wróci do domu wcześniej ... więc wygląda na to, że wnosi znacznie więcej niż resztazespołu, prawda?A jednak próbuje się uzasadnić, dlaczego podjął jakąś marginalną decyzję, a jednocześnie prawdopodobnie zdaje sobie sprawę, że jego koledzy nadal nie rozumieją szerszego obrazu.To musi być niesamowicie frustrujące!Wszystkie strony potrzebują bardziej produktywnego sposobu radzenia sobie z tą frustracją.
Wiele osób „z spektrum” (o których ludzie w tej kwestii zdecydowali, że jest pracownikiem) ma skrajną dosłowność.Jeśli powiesz „komentarz”, masz na myśli „komentarz”, a nie „35 komentarzy z rzędu”, a już na pewno nie „wpis wiki i komentarz zawierający adres URL wpisu wiki”.Niezrozumienie tego i po prostu powiedzenie „komentarza” może sfrustrować osobę, której poproszono o zrobienie czegoś, co jest całkowicie niemożliwe.Jeśli naprawdę chcesz z kimś pracować i akceptować go tam, gdzie jest, powiedzenie „ale nie miałem na myśli tego dosłownie” nie pomoże.
user30031
2016-12-09 23:36:38 UTC
view on stackexchange narkive permalink

Użytkownik Kubek Mata wpadł na krytyczny pomysł w swoim komentarzu:

[...] bądź bezosobowy (policz, ile „i„ twój ”w komentarzach do recenzji pracownika A & B) [...]

To twoja rozmowa o tym, czy jest to warte wysiłku, ale jeśli ta osoba jest naprawdę tak wartościowe, jak się wydają, to myślę, że będzie tego warte. & sprawi, że każdy będzie przyjemniejszy. W ten sposób możesz nawet zyskać dodatkowy produktywny czas od tej osoby.


Przykłady

Przed: Dlaczego nazwałeś tę zmienną „tamtą”?

Po: Dlaczego ta zmienna nosi nazwę „ta”?

Przed: czy możesz zamieścić komentarz opisujący, co się ze mną dzieje?

Po: przydałby się komentarz opisujący, co się dzieje.

WernerCD
2016-12-10 06:39:19 UTC
view on stackexchange narkive permalink

Widziałem (jak w tej odpowiedzi) wspomnianą dynamikę zespołu, jego odpowiedzi, Twoje odpowiedzi i inne dynamiki wspomnień „Ty” i „Rainman” ...

Coś, czego nie mam widziano wspomniano: Firmowe standardy kodowania

Gdzie te pytania / odpowiedzi mieszczą się w zakresie standardu kodowania? Konwencje nazewnictwa, kod komentowania, tagowanie ... wszystko to brzmi jak rzeczy, które powinny być skodyfikowane w ramach standardu.

Jeśli nie ma standardu, wszystko sprowadza się do „On powiedział, Ona powiedziała” i osobistych preferencji . „To powinno mieć tę nazwę… powinno mieć komentarz… To powinno być oznaczone w ten sposób” - wszystkie osobiste preferencje oparte na tym, kto go aktualnie obsługuje.

Jeśli „Rainman” jest dobry programista, założę się, że przestrzega najlepszych praktyk, aktualnych metodologii itp. Częścią „czystego kodowania” jest uczynienie wszystkiego czytelnym, zrozumiałym, samoopisującym itp.

Duży częścią jest konsekwencja.

Zyskujesz to dzięki standardowi, którego powinien przestrzegać cały zespół / firma. Niezależnie od tego, czy obejmuje to tabulatory, spacje, SemVer czy coś innego ... 20 różnych sposobów kontrolowania Konwencje dotyczące wielkich liter.

Myślę, że tworzenie zestawu standardów - lub przyjęcie ustalonego standardu dla twojego stosu, takiego jak C # C # Coding Standards - złagodziłoby większość "Myślę, że powinieneś ..." i przeniesie je do "To nie jest zgodne z naszym udokumentowanym sposobem robienia rzeczy". (nawet jeśli rzeczywistość jest taka, że ​​wszyscy już robią to w ten sam sposób, a „myślę, że powinieneś ...” to tylko percepcja)

To usuwa „My” kontra „Rainmain” i przenosi to do „Ty robią NIESAMOWITE, ale postępuj zgodnie z procedurą ".

Anthony X
2016-12-10 09:28:37 UTC
view on stackexchange narkive permalink

Gdy po raz pierwszy sprawdziłem kod, było to bardzo nieprzyjemne doświadczenie. Byłem częścią „zżelowanego” zespołu - wszyscy dobrze się dogadywaliśmy, szanowaliśmy nawzajem umiejętności i do pewnego stopnia utrzymywaliśmy kontakty towarzyskie. Jednak kiedy sprawdzano mój kod, czułem się, jakbym był atakowany. Szczerze mówiąc, byłem pierwszą „ofiarą” tego procesu dla bardzo młodego zespołu, więc wszyscy musieliśmy zdobywać doświadczenie. Z perspektywy czasu wszystko to było konstruktywne i korzystne; po prostu nie wydawało się to w tej chwili.

Chodzi mi o to, że musisz wykazać się odrobiną empatii, aby naprawdę wiedzieć, w jaki sposób Twoja opinia zostanie odebrana, i mieć to na uwadze podczas dostarczania. W twoim przypadku dana osoba wydaje się być bardziej wrażliwa niż większość, więc musisz po prostu zwrócić większą uwagę na swoją przesyłkę.

Jedną z praktycznych zasad podczas przedstawiania konstruktywnej krytyki jest to, aby nie zapomnieć o skomentuj pozytywne. Nie chcesz też sprawiać wrażenia, że ​​atakujesz tę osobę. Nikt nie lubi, gdy inni wyłapują wszystkie wady czegoś, w tworzenie czego z dumą zainwestowali. Uważaj na użycie słowa „ale” i tego, jak może ono zmienić to, co na początku brzmiało pozytywnie, w krytykę. Dobrym pomysłem jest również zakończenie zawsze pozytywną nutą, a powtórzenie komplementu nigdy nie zaszkodzi.

Jeśli chodzi o wprowadzanie poprawek do pracy, którą przesłał do recenzji, zamiast kazać mu zmienić coś lub nawet spytanie, czy mógłby, być może sformułowanie tego w stylu „być może moglibyśmy ...”, jak w przypadku zespołu - ty, on i wszyscy inni. Wszyscy jesteście w zespole pracującym razem nad wspólnym celem. Być może potrzebuje tylko delikatnego przypomnienia, że ​​chociaż wykonuje zadania indywidualnie, tak jak wszyscy, zespół ponosi odpowiedzialność za wynik wszystkich indywidualnych wysiłków, dlatego każdy jest zainteresowany, aby ostateczny wynik był jak najlepszy be.

Przykład:

„Jak zwykle wykonałeś świetną robotę. Czy możesz pomóc nam lepiej zrozumieć kilka szczegółów? Ta zmienna o nazwie X - reprezentuje (...) prawda? Mając to na uwadze, czy możemy ją nazwać (.. .) zamiast tego? Ta sekcja kodu - pomogłaby nam później, gdybyśmy mieli komentarz wyjaśniający (...). Czy możemy dodać tag do tego zatwierdzenia? Ponownie, to świetna robota. ”

I może ktoś mu wytłumaczy, że chociaż może to być poważny ból przez pierwsze dwa lub trzy razy, po zaskakująco krótkim czasie zmniejszy się prawie do zera.Zespół powinien szybko ustalić normy dotyczące takich rzeczy, jak nazwy zmiennych, komentarze, testy jednostkowe i tak dalej.
user44108
2016-12-09 20:52:51 UTC
view on stackexchange narkive permalink

Przestań go zadręczać

Jeśli ten facet jest jednym z najlepszych facetów, jakich masz, musisz dać mu trochę swobody i pozwolić mu pracować tak, jak chce. Jeśli są rzeczy, które robi, które są sprzeczne z twoimi ramami pracy, zajmij się nimi.

Jest jasne, że ma określoną cechę osobowości, więc musisz pracować z tym, a nie przeciwko temu. Jeśli potrafisz dowiedzieć się, co wywołuje jego wybuchy i zrobić wszystko, co w Twojej mocy, aby uniknąć tych wyzwalaczy, wszystko będzie o wiele lepsze dla wszystkich.

P.S. Nazywanie go „Rainman”, nawet podczas publikowania anonimowego, tak jak teraz (zakładam, że tworzysz nowe konto SE wyłącznie dla tego pytania) jest (moim zdaniem) naprawdę niewłaściwe.

Być może to, czego nie przeczytałeś / nie rozumiesz, Pete, to fakt, że ludzie próbowali zająć się sprawami, które są „sprzeczne z ramami pracy”, a reakcja wciąż polegała na rozpłakaniu się.
Ten pracownik może pracować tak, jak powinien, z powodu odczuwanej presji.Płacz, gdy krytykowany, pokazuje, że nie znajduje się w idealnym środowisku pracy.Nikt nie powinien się tak czuć, kiedy tak naprawdę nie jest krytykowany.
Nie zgadzam się z tą odpowiedzią, nie nazwałbym komentarzy w przeglądzie kodu „badgeringiem”.Niezwykle ważne jest, aby kod był czytelny (zwłaszcza w tym kontekście, ponieważ ten pracownik wydaje się być bardziej wykwalifikowany niż jego współpracownicy) i bynajmniej nie „zadręczać się”, prosząc o wyjaśnienie.Kod może przeżyć tam swój czas, może tam przetrwać wszystkie czasy, więc ważne jest, aby ludzie mogli go w przyszłości utrzymywać.
Nie zgadzam się, że pozwolenie mu się wymknąć jest dobrą opcją - praktyki firmowe zwykle istnieją z jakiegoś powodu, ale myślę, że to trafia w dobry punkt w inny sposób - czy można włożyć więcej wysiłku, aby upewnić się, że ten członek zespołu rozumie, że jego kod jestniekoniecznie „obiektywnie źle”, ale po prostu jest na nieuniknionej krzywej uczenia się, aby w pełni wchłonąć praktyki firmy?Być może ta wiedza złagodzi skutki tego, co wydaje się być postrzegane jako bezpośrednia krytyka jego wysiłków.
To jest całkowicie błędne.Pandering nigdy nie jest rozwiązaniem.Jasne, może ci to ułatwić życie, ponieważ wtedy unikniesz wszelkich konfliktów.Ale to nie twoja praca jako szefa tego gościa.Ani trochę.
Byłem facetem w drużynie, który był o wiele lepszy niż wielu innych w drużynie.Spędziłem jeden dzień z trenerem, który nauczył mnie, jak kodować trochę wolniej, ale tak, aby inni ludzie mogli zrozumieć i utrzymać mój kod.To było jedno z najbardziej przydatnych doświadczeń, jakie kiedykolwiek miałem.Może znajdziesz kogoś, kto nauczy tego faceta, jak podnieść drużynę.(Lub zatrudnij innego programistę / menedżera rockstar, który może naprawić tę dysfunkcję i sprawić, że zespół będzie lepiej pracował jako grupa.)
A.S
2016-12-09 22:05:42 UTC
view on stackexchange narkive permalink

Zastanawiam się, czy na początku jest jakiś problem?

Czasami interpretujemy to, co uważamy za nietypowe zachowanie innych, za problem, który należy naprawić. Niekoniecznie tak jest. Na przykład mój znajomy ma żonę, która płacze dość często (jak na męskie standardy - to może raz lub dwa razy w miesiącu?). Powiedział mi, że za każdym razem, gdy to się dzieje, czuje się nieswojo i próbuje znaleźć sposób, żeby ją uspokoić. Obejmuje to (a) rozrywki; b) prezentowanie szklanki w połowie pełnej; c) upomnienie; (d) przyjęcie winy i ucieczka, z nieuniknionym okresem „złego nastroju” przez ograniczony czas. Po pewnym czasie wszystko to zaczęło irytować jego żonę, a ona w końcu poddała psychoanalizie sytuację i zapytała, czy uważa, że ​​jej płacz jest problemem do rozwiązania.

Dlaczego, rzeczywiście, płacz ludzi jest problemem, prawda? Od dzieciństwa uczymy się, że płacz jest swego rodzaju „ostatecznością” odpowiedzi. Dlatego po osiągnięciu tego progu zakładamy, że coś poszło nie tak do tego stopnia, że ​​nie można go pozostawić bez opieki, i spieszymy się, aby to naprawić.

Teraz kicker: Okazuje się, że niekoniecznie. Dla jego żony płacz był całkowicie zdrową i normalną strategią radzenia sobie z wszelkiego rodzaju bzdurami. Innymi słowy, był to - z jej perspektywy - jej normalny sposób radzenia sobie ze stresem lub smutkiem, który zdarza się od czasu do czasu i jest tylko częścią życia. Wręcz przeciwnie, gdyby trzymała to wszystko w sobie i pozwalała mu się budować, mogłoby to przekształcić się w poważniejsze problemy psychologiczne (takie jak depresja). Zasadniczo całkowicie odwróciła scenariusz na niego. Okazało się, że on zrobił z tego coś ważniejszego niż ona.

Jeśli jesteś zainteresowany, teraz, gdy żona mojego przyjaciela płacze, jego domyślnym ustawieniem jest pozwolić jej na chwilę zająć się tym, zajmując się swoimi sprawami, a następnie (kiedy skończy) zapytaj, czy jest coś, co może zrobić, aby pomóc lub jeśli chce się podzielić, to (jeśli to zrobi) po prostu SŁUCHAJ CHWILĘ, bez udzielania ŻADNEJ rady ani rozwiązywania problemów, chyba że wyraźnie o to poprosi. Zwykle wystarczy 5-minutowa rada, a potem robią plany na weekend lub cokolwiek innego. Uniknięcie kryzysu.

Czy to możliwe, że reakcja emocjonalna jest najlepszą strategią Rainmana na uwolnienie psychologicznej presji, a jeśli tej presji nie wolno uwolnić w najlepszy możliwy sposób, może prowadzą do głębszych problemów w przyszłości?

Morał z tej historii jest taki, że często tworzymy założenia dotyczące innych na podstawie naszego własnego rozumienia świata i działamy zgodnie z tymi założeniami bez uprzedniego sprawdzenia ich pod względem ważności. Czy morał tej historii może mieć zastosowanie w tej sprawie? Ty będziesz sędzią, ale chciałem podzielić się tym jako czymś do przemyślenia w odniesieniu do twojego Rainmana. Być może przerażenie emocjonalne jest właśnie sposobem, w jaki radzi sobie z łagodnymi konstruktywnymi opiniami i nie jest to osądzanie ani ciebie, ani twojego zespołu, ani problem do rozwiązania. Jeśli to może być odległa możliwość, proponuję bardzo krótką, nieformalną rozmowę 1 na 1, aby zapytać go (bardzo grzecznie), że zauważyłeś, że pojawił się nieco w fazie dyskusji na spotkaniach i wydaje się, że potrzebuje czasu, aby dojść do siebie .

Po prostu udostępnij to jako obserwację i zapytaj, czy jest to coś, o co Ty lub zespół powinniście się martwić. Pozwól mu dostosować swoje postrzeganie i zasugeruj strategie deeskalacji takich sytuacji, jeśli rzeczywiście jakakolwiek deeskacja jest konieczna lub pożądana z jego punktu widzenia. Pamiętaj, aby zakończyć tę rozmowę sporą porcją pochwał.

Podejrzewam, że pozwolenie mu na pokierowanie, jak radzimy sobie z takimi sytuacjami, może być najlepszym podejściem, zamiast wychodzić z bramki, że jest to problem do rozwiązania i próbować jednej taktyki po drugiej (prawdopodobnie prowadząc do załamania droga), podczas gdy w rzeczywistości lepiej byłoby zostawić go w spokoju. Czasem porzucenie problemu jest jedynym właściwym sposobem rozwiązania go. W naszej kulturze biznesowej zorientowanej na działanie często nie traktujemy bezczynności jako opcji, ale czasami działa to lepiej niż cokolwiek innego.

Ostatnia myśl. Jeśli 80% zachowań związanych z „reakcją emocjonalną” wiąże się z obecnością Rainmana na spotkaniach przeglądu kodu, czy można by pozwolić mu zdecydować, czy woli w nich uczestniczyć, czy też komunikować się w sprawie kodu w inny sposób? Być może znacznie lepiej radzi sobie z otrzymywaniem informacji zwrotnych przez komunikator internetowy, e-mailem lub podczas indywidualnego spotkania z Tobą, podczas którego dzielisz się wynikami przeglądu kodu, które go dotyczą, niż podczas spotkania w grupie format twarzą w twarz? Niektórzy ludzie mają problemy z określonymi modalnościami komunikacyjnymi, które odpadają i nie stanowią problemu w innych modalnościach (np. Ten twój kumpel, który zawsze woli dzwonić zamiast wysyłać e-maile lub odwrotnie). Może warto spróbować - o ile jest z nim fajnie i nie sprawia, że ​​czuje się wyróżniony lub odizolowany, oczywiście ... znowu, pozwól mu poprowadzić to, a wszystko powinno być w porządku. Powodzenia!

To jest dobra uwaga.Może bardziej niż cokolwiek innego jest to kwestia percepcji.
Chociaż płacz może być dobrą i zdrową rzeczą dla jednostki, w tym przypadku osoba płacze podczas spotkań oraz w bezpośredniej reakcji na komentarze współpracowników.W najlepszym przypadku ** jest to niepokojące dla reszty zespołu i prawdopodobnie wpływa na ich moralność w miejscu pracy (inaczej zakładam, że OP nie czułby potrzeby publikowania tutaj).
Ta odpowiedź jest również bardzo rozwlekła;Myślę, że mogłoby to być znacznie lepiej odebrane z TL; DR.
@DoritoStyle, dziękuję za opinie i wszystkie dobre punkty.Nadal pracuję nad pisaniem skutecznych odpowiedzi.Uważam, że niektórzy PO wolą krótsze odpowiedzi, ale inni doceniają dodatkowy kontekst i uważają takie odpowiedzi za pełniejsze.Chociaż większość respondentów może docenić zwięzłość, moimi głównymi odbiorcami są OP i zwykle błądzę po stronie bardziej kompletnej niż zwięzłej odpowiedzi - ale wezmę pod uwagę twoje komentarze ... gdy tylko skończę płakać?;) Jeśli chodzi o twoją odpowiedź, chociaż prosta parafraza może zadziałać dla 8-latka, nie jestem przekonana, że się sprawdzi.
Poziom szczegółowości zdecydowanie nie jest zły;Myślę, że krótkie podsumowanie z góry spełniłoby obie obawy
spuder
2016-12-10 22:40:03 UTC
view on stackexchange narkive permalink

Zmień sposób przeprowadzania recenzji kodu

Bezpośrednie przeglądy kodu stają się przestarzałą praktyką, gdy zespoły stają się bardziej globalne, a tempo tworzenia oprogramowania rośnie. Zamiast osobiście sprawdzać kod, przeglądaj każdą gałąź w narzędziu po zatwierdzeniu zmian.

1. Użyj narzędzia do przeglądania kodu, które pozwala na komentarze w tekście.

enter image description here

Fizjologicznie to zrobi to, co sugeruje odpowiedź DoritoStyle. Usuwa człowieka z dyskusji. Teraz omawiasz „kod”, a nie to, co „koder zrobił”.

github.com i gitlab mają wbudowane narzędzia do przeglądu kodu.

Jeśli ten programista skończył z narzędziami open source lub szybko rozwijającą się firmą programistyczną, ten przepływ pracy prawdopodobnie będzie im znany.


2. Zwiększ częstotliwość przeglądów kodu

„Kiedy coś jest bolesne, sposobem na zmniejszenie farby jest robienie tego częściej, a nie rzadziej”.

Wygląda na to, że masz duże spotkanie, aby dokonać przeglądu kodu. Przeglądy kodu powinny być małe i wykonywane za każdym razem, gdy gałąź funkcji jest gotowa do scalenia z wzorcem. Jeśli programista jest gotowy do scalenia wielu gałęzi funkcji do gałęzi „głównej” dziennie, oznacza to, że dziennie powinno być wiele małych przeglądów kodu. Można to skalować tylko wtedy, gdy używasz narzędzia do przeglądania kodu.

3. Przejrzyj kod przed połączeniem gałęzi z wzorcem

Nie jest to jasne z opisu, kiedy w potoku odbywa się przegląd kodu.

Celem przeglądu kodu jest zapewnienie jakości zanim zostanie zaakceptowany. Kod, który został już scalony jest psychologicznie „kompletny”, a wszelkie krytyki są za późno.


Jeśli nadal będziesz osobiście sprawdzać kod:

  • usiądź obok siebie, a nie w poprzek stołu
  • tylko 1 osoba recenzująca kodu naraz, przegląd kodu nie jest przeglądem grupowym.
  • nadmiernie komunikować powody, dla których przeprowadza się recenzje kodu
NZKshatriya
2016-12-10 11:54:15 UTC
view on stackexchange narkive permalink

Upewnijmy się, że ten programista został WYRAŹNIE uświadomiony, że pytania o instancje w kodzie nie są atakami na jego inteligencję lub zdolność kodowania.

Wielu genialnych ludzi ma ukryte problemy emocjonalne, a spora część z nich albo nie została zdiagnozowana, albo została zdiagnozowana nieprawidłowo.

Sam mam zespół Aspergersa (DSM-5 Autism Spectrum Disorder ... ugh) (czytaj jako umiejętności interpersonalne nie na najwyższym poziomie, pewne trudności w wychwytywaniu sygnałów społecznych, a także inne rzeczy), więc czasami ja może bardzo źle odczytać sytuację, a moja reakcja będzie ..... zła, w porównaniu z oczekiwaniami innych.

To nie brzmi jak ten przypadek programisty, ale na pewno tak brzmi jest podstawowym problemem, podobnie jak pewna dawka syndromu „każdy wygrywa”. Żartuję.

To nie jest sytuacja, w której trzeba wprowadzić swój zespół na jego poziom emocjonalny, ale brzmi to jak sytuacja, w której po prostu musi być trochę, z braku lepszy termin, „więź zespołowa”. Myślę, że musi wiedzieć, że jest częścią zespołu, a nie tylko potęgą kodowania.

Dla tych, którzy nie czytali mojego profilu: głosy przeciwne bez komentarzy są infantylne
Myślę, że to może być kluczowy punkt tutaj.Ktoś, kto pisze szybko i niewiele komentuje, prawdopodobnie myśli, że kod po prostu wyjaśnia sam siebie i nie ma powodu, aby dodawać więcej opisów.Warto podkreślić, że dodanie tych funkcji nie jest refleksją na temat autora, ale jest korzystne dla każdego, kto będzie musiał przeczytać kod.
gnasher729
2016-12-09 21:11:42 UTC
view on stackexchange narkive permalink

Twoim zadaniem jest maksymalizacja pożytecznej pracy wykonywanej przez Twój zespół, jednocześnie traktując go w taki sposób, aby nie uciekł. A jeśli faktycznie uda ci się stworzyć przyjemne miejsce pracy, nawet lepiej.

Wygląda na to, że wiesz, że w przypadku tego pracownika praca, którą wykonuje, przewyższa wszelkie wady jego osobowości. Przy wszystkich jego problemach wolisz mieć go w swoim zespole niż nie.

Więc po zakończeniu recenzji kodu pozwól zrobić to komuś, kto jest zarówno starszy, jak i dorosły, a gdy wystąpią takie rzeczy, jak za mało komentarzy lub coś niepoprawnie oznaczonego, ta osoba sporządza notatkę i naprawia ją samodzielnie recenzja - aby Twój programista mógł kontynuować i wykonywać więcej pracy.

Ktoś wspomniał o „czynniku autobusowym” - jeśli masz kogoś, kto wykonuje pracę dwóch osób za jedno wynagrodzenie, nie jest to niezastąpiona osoba. Jest bardzo łatwy do zastąpienia, płacąc dwa razy więcej, zatrudniając dwie osoby, aby go zastąpić.

Myślę, że jest tu wiele zalet w jednym punkcie: może być lepszą drogą, jeśli ktoś inny robi „porządki”, jeśli poproszenie „Rainmana” o naprawę samemu stwarza tyle tarcia.
Alan Wolfe
2016-12-11 22:41:34 UTC
view on stackexchange narkive permalink

Kiedy zaczynałem pracę w firmie, w której obecnie jestem, byłem również postrzegany jako ta osoba, ponieważ moja wersja historii została odrzucona z powodu bycia nowym facetem.

Kiedy zaczynałem, pracował z facetem, który był bardzo wybredny w sprawach absurdalnych - głównie gramatyki w komentarzach i drobnych wyborów stylistycznych (które mieściły się w standardach kodowania), a także był przeciwko mnie robienie czegokolwiek inaczej niż on lub używanie rzeczy, których nie widział przed. Problem polegał na tym, że podczas gdy on i ja mieliśmy tyle samo lat doświadczenia (wtedy 11), on zajmował się tym jednym projektem w tej jednej firmie, podczas gdy ja pracowałem w wielu innych firmach na wyższych i głównych rolach, więc był dość osłonięty / tak naprawdę nie widział świata zewnętrznego. Był również niekonsekwentny w tym, czego wymagał podczas każdej CR, więc nawet gdy próbowałem to zrobić po jego myśli, nie można było zadowolić tej osoby.

W każdym razie on i ten drugi koleś naprawdę nie dogadywali cóż (drugi facet powiedział, że starał się unikać pracy z tą osobą), a praca, którą wykonałem, wypełniła lukę między tymi dwoma osobami.

Problem polegał na tym, że ludzie bohatersko żądali, żebym robił rzeczy tak, jak oni chciałem osiągnąć najdrobniejszy poziom szczegółowości, ale nie zgadzali się ze sobą i zamiast pracować nad tym, połączyli siły przeciwko mnie, nawet gdy żądali przeciwnych rzeczy.

Trwało to około 6 miesięcy i wszystkie moje skargi kierowane do kierownictwa tylko źle się odbiły na mnie i nic się nie zmieniło.

Kiedy nasz bezpośredni szef był na wakacjach, ta osoba poszła do naszego szefa i powiedziała, że ​​jestem podwładnym. Nasz szef wrócił i wyjaśnił, że nie pracuję pod tą osobą, więc nie jestem nieposłuszny. To było śmieszne.

Sytuacja w końcu się zmieniła, gdy mogłem dostać się do innego zespołu.

Miałem około 4 lat i wszystko było w porządku.

Nigdy nie byłem tak źle traktowany w środowisku zawodowym i naprawdę nie mogłem się z tym pogodzić, ponieważ było to dla mnie nowe doświadczenie, a kierownictwo nie pomagało.

Może Ty powinien porozmawiać z Twoją osobą i spróbować dowiedzieć się, jaki jest jej punkt widzenia? Może twoi „staruszkowie” są egoistycznymi palantami?

Co jest złego w poprawianiu gramatyki w komentarzach?
Nie ma w tym nic złego.Na pewno może to być dobra rzecz.W moim przypadku uważam, że była to kwestia kontroli i sprawiła, że recenzent kodu poczuł się dobrze ze sobą i być może lepszym.Nie jestem specjalistą zdrowia psychicznego, ale myślę, że coś jest nie tak z tą osobą.W moim przypadku fakt, że była zaangażowana druga osoba, z pewnością pomogłem, sprawił, że zastanowiła się nad mną i być może wzbudza podejrzenia, gdy inni to czytają teraz (być może nawet ty).To była zła sytuacja, ale bardzo się cieszę, że to koniec.Chciałem zwrócić uwagę OP, że może być więcej, to wszystko.
Santiago
2016-12-10 02:40:31 UTC
view on stackexchange narkive permalink

Osoba taka jak Rainman potrzebuje ustrukturyzowanej i zorganizowanej struktury, dlatego ludzie tacy jak on zwykle mają powtarzalne zachowania, a także skrajny porządek. Jeśli jest prawdziwym Rainmanem, zobaczysz, że każdy papier jest zawsze w tym samym miejscu, nawet jeśli jego biurko wygląda okropnie lub jego kod zawsze będzie miał tę samą estetykę.Również ludzie Rainmana są zestresowani, jeśli potrzebują interakcji z innymi ludźmi, szczególnie jeśli rozmowa nie jest dla nich logiczna.

Aby mieć z nim dobre relacje, musisz przestrzegać porządku, przestrzegać jasnych zasad i ograniczać rozmowę do minimum. Nie trać czasu na torturowanie go mówiąc „Dlaczego nazwałeś tę zmienną„ tamto ”?”, Zamiast tego utwórz regułę nadawania nazw zmiennym i daj mu ją mówiąc „to jest reguła nazw”.

-1 tylko po to, aby nie tylko zintegrować nomenklaturę „Rainman”, ale także powtórzyć ją trzykrotnie.Nie fajnie.
Myślę, że Santiago nie mógł dostać referencji ..... gdyby tak i nadal używał Rainmana .......................
Myślę, że w tej odpowiedzi jest wystarczająco dużo wartości, że nie warto jej odrzucać tylko dlatego, że przekaz jest trochę szorstki.W tej sytuacji może naprawdę pomóc zapewnienie jasnej struktury, w ramach której jednostka będzie mogła pracować.
Marv
2016-12-10 09:55:05 UTC
view on stackexchange narkive permalink

Nie jestem pewien, czy masz problem. Twoja gwiazda jest emocjonalna, ale mówisz, że przyjdzie następnego dnia i wszystko w porządku. Wydaje się, że mówi pan, że jego poziom produktywności jest wysoki i, jak rozumiem, nie ma problemów. Mówisz też, że reszta zespołu akceptuje jego zachowanie. Nie mówisz, że na horyzoncie są zagrożenia. Jeśli tak, to zagłosowałbym za „spokojną drogą”. Ludzie się różnią. Niech się zmieniają. Nie ingeruj, chyba że zakłócenia są wyraźnie uzasadnione. Ludzie, którzy zachowują się inaczej, niż się spodziewasz, nie są powodem do ingerencji. Wysoce produktywni ludzie nigdy nie są zwyczajni.

Mam pewne obawy. Jak zdobyłeś tę gwiazdę? Czy wiesz, dlaczego porzucił swoją poprzednią pracę? Jeśli miał tam problemy, może to być wskazówka, jak temu zapobiec. Po drugie, spójrz uważnie na swój zespół. Nowa gwiazda jest zwykle uciążliwa i wymaga wysiłku, aby uspokoić wzburzone ego. Wydaje się, że sugerujesz, że nikt nie czuje urazy do nowego talentu, który naprawił mnóstwo problemów jako efekt uboczny czytania kodu. Gdybym był jednym z waszych długoletnich zespołów, czułbym się ukarany i mógłbym świadomie lub podświadomie próbować worek z piaskiem do nowej gwiazdy. Wybieranie głupich rzeczy w recenzjach kodu może być sposobem na zrobienie tego. Mam nadzieję, że bardzo się starałeś, aby nic z tego się nie działo.

Z mojego doświadczenia wynika, że ​​nowa gwiazda może negatywnie wpłynąć na produktywność zespołu bardziej niż środek dewelopera drogowego. Gwiazdy ogólnie dbają o siebie. To reszta zespołu potrzebuje czułej opieki.

eee
2016-12-12 03:12:21 UTC
view on stackexchange narkive permalink

Myślę, że zalecenie recenzenta kodu powinno być wiążące tylko wtedy, gdy:

  • Wykryto błąd. Błędy mogą przytrafić się każdemu deweloperowi i każdy może podziękować, w tym większości wrażliwych dusz.
  • Programista nie ma ogólnego doświadczenia ani doświadczenia z kodem (pierwszy miesiąc, więcej, jeśli kod jest naprawdę bardzo złożony).
  • Nie masz odpowiedniego dokumentu opisującego, w jaki sposób chcesz napisać kod.

W innych przypadkach lepiej pozostawić opcjonalne zalecenia recenzenta . Dalsze wydarzenia zależą od osobowości dewelopera, ale wielu i tak zastosowałoby rozsądne zalecenia. Jeśli ktoś systematycznie odstępuje od wspomnianego dokumentu z wytycznymi, to takie kwestie należy omówić na spotkaniu (w tym dyskusje o tym, na ile wytyczne są uzasadnione i dlaczego). Jeśli programista nie zastosuje poprawek, recenzent może je zamiast tego zastosować - jest to skuteczny sposób na przekonanie, że wytyczne są łatwe do przestrzegania i należy ich przestrzegać. W niektórych przypadkach recenzent w ten sposób może odkryć powód, dla którego rzeczy są zaimplementowane w inny sposób (obecna wersja wygląda bardziej czytelnie? „Właściwe podejście” skutkuje niemożliwym do przetestowania kodem? Coś jest po prostu niemożliwe?).

wymagające zastosowania wielu zmian, które są bardziej kwestią opinii, również stanowią problem.

W tym miejscu działania byłyby następujące:

  • Ogranicz obowiązkowe poprawki do tylko zgłoszone błędy.

  • Wszystkie inne sugestie niech będą opcjonalne.

  • Napisz dokument, jak ma wyglądać kod polub i upewnij się, że wszyscy wiedzą, gdzie go znaleźć.

Powinno to uczynić życie ludzi, którzy nie lubią recenzji kodu, znacznie łatwiejsze do zniesienia. Przegląd kodu jest znaczącym stresem, którego nie ma w większości zawodów (nauczyciele lub lekarze naprawdę nie lubią, gdy idziesz do nich dwojga tylko po to, by porównać) i ważne jest, aby nie ciągnąć więcej, niż może znieść ludzka natura.

Crowley
2016-12-12 19:10:01 UTC
view on stackexchange narkive permalink

Nie będę się zajmował faktem, że jeden pracownik może zdeklasować cały zespół. Odniosę się tylko do problemu Rainmana (lub dowolnego członka zespołu) wpadającego w wściekłość podczas przeglądu kodu.

Są ludzie, którzy myślą szybciej niż inni. Są sposoby, które bardziej pasują do niektórych ludzi niż do innych. Niektórzy ludzie są bardzo szybcy, gdy podchodzi się do problemu w jeden („ich”) sposób, ale całkowicie gubi się, gdy podejście jest (nieco) inne.

Studiowałem fizykę stosowaną, fizykę plazmy i wzrost cienkich płetw. Obecnie pracuję na Wydziale Mechanicznym. Czasami podejście i nawyki moich współpracowników doprowadzają mnie do szału (zazwyczaj jakich narzędzi używają i jak ich używają); czasami doprowadzam ich do szału (zwykle nie wspominając o kluczowych informacjach, które uważam za oczywiste, lub kłócąc się o coś, dowiadując się, że od samego początku chcemy tego samego). Innymi słowy, czasami wydaje się, że pochodzimy z różnych wszechświatów ...

Czy zapytałeś swojego Rainmana, która część „Dlaczego nazwałeś zmienną that ?” pytanie ich denerwuje? Czy pytanie było zbyt głupie w ich skali głupoty? Czy kpił z ich przepływu pracy? Czy ton pytania sprawił, że poczuli się nieswojo?

Zrób sobie listę zadań:

  1. Zrozum, że jest problem. Sprawdź
  2. Podaj przyczynę problemu. Czekam ...
  3. Znajdź przyczynę problemu.
  4. Dowiedz się, w jaki sposób zapobiec wystąpieniu problemu lub jak zapobiec eskalacji problemu.
  5. Stwórz odpowiednie zasady i trzymaj się ich.
  6. Omów zasady z całym zespołem.

Nie próbuj rozwiązywać bez pytania lub zaangażowania Rainmana w rozwiązanie. Nie ekstrapoluj ich nastroju, reakcji itp. Nie próbuj rozwiązywać tego za ich plecami. Nie próbuj niczego ukrywać pod dywanem.


Być może jest członek zespołu, który jest doprowadzany do szaleństwa pracą i zachowaniem Rainmana i jeszcze nie wybuchł. To, co zostało powiedziane, nie może być niewypowiedziane. Spróbuj znaleźć kompromis między wszystkimi członkami. Może pomogłoby krótkie (anonimowe) pytanie.

  • Pytanie 1: Co jest błędne w naszych sesjach przeglądu kodu?
  • Pytanie 2: Co według Ciebie może ulepszyć kod -sesje przeglądu?
  • Pytanie 3: Co lubisz w sesjach przeglądu kodu?
JohnHC
2016-12-09 20:39:42 UTC
view on stackexchange narkive permalink

Podszedłbym do tego w taki sam sposób, jak do każdego innego problemu z wydajnością. Wyjaśnij, że zauważyłeś zachowanie i zapytaj, jak możesz wesprzeć pracownika.

Spróbuj sformułować to bardziej w kontekście pomocy i pomocy niż dyscypliny.

Wiem, że czasami denerwujesz się w pracy. W czym możemy Ci pomóc? Czy są jakieś procesy lub mechanizmy, które możemy wdrożyć, aby Cię wspierać?

„* Podszedłbym do tego w taki sam sposób, jak podchodziłbym do każdego innego problemu z wydajnością. *” Na przykład: nałożyć konsekwencje, jeśli nie zostanie rozwiązany?Bo to generalnie oznacza.
Sposób, w jaki jest to opisane, nie jest problemem wydajnościowym.200% swojej codziennej pracy wykonuje w 4 godziny, zaczyna płakać i idzie do domu.To nie jest problem z wydajnością.
@gnasher729 Powiedziałbym, że jest to absolutnie kwestia wydajności.Niezależnie od tego, jak szybko i wydajnie pracujesz, brak możliwości komunikowania się ze współpracownikami jest znaczącym problemem
Zwykle byłoby to dobre podejście, ale biorąc pod uwagę, że współpracownicy już wykazali brak umiejętności otrzymania konstruktywnej porady bez brania jej do siebie, nie jestem pewien, czy w tym przypadku jest to dobry pomysł.
Podobają mi się odpowiedzi Wesleya Longa i Kate Gregory, ale ta mówi w zwięzły sposób: Spróbuj zaangażować pracownika w rozwiązanie.Inne odpowiedzi wydają się próbować zamieść problem pod dywan.OP powinien przynajmniej SPRÓBOWAĆ poznać perspektywę pracownika.Może programista nie potrafi wyartykułować, co go niepokoi.Ale nie dowiesz się, dopóki nie spróbujesz.Koder zasługuje na maksymalne zaangażowanie w rozwiązanie problemu.Wydaje mi się, że gnasher729 myli „wydajność” z „produktywnością”.To drugie jest tylko jednym z elementów pierwszego.
Vietnhi Phuvan
2016-12-09 22:14:48 UTC
view on stackexchange narkive permalink

Rainman wykonuje świetną robotę. Jego zachowanie jest co najmniej niekonwencjonalne i cieszę się, że Ty i zespół przeanalizowaliście sytuację i zdecydowaliście się wziąć dobro i zło.

Spraw, aby czuł się bezpiecznie w swoim otoczeniu , dowiedz się, co go nakręca i jeśli czuje się szczęśliwy i komfortowo będąc w firmie, szanse na to, że skoczy na statek są minimalne.

Zakładam, że Ty i zespół rozumiecie jego dziwactwa i macie wziął stosunek do nich na żywo i niech żyje.

Możesz zaproponować mu lepsze sposoby reagowania na to, co go denerwuje, ale to, czy słucha, to inna historia. Zwykle radzę innym, aby nie pozwolili, by sprawy uderzyły im do głowy, zwłaszcza jeśli wiem, że ich głowy to mieszanina emocji, które tylko czekają, aż wyleją się z chwili, gdy odkręcę kran. To niesamowite, jak większość ludzi nie denerwuje się, kiedy mówią sobie „Nie pozwolę, żeby mnie to zdenerwowało, bo nie warto się denerwować”. Zaproponuj mu reakcje na stresory, które mogą działać lepiej dla niego, jednocześnie minimalizując negatywny wpływ na zdrowie psychiczne wszystkich. I niech sugestie będą przyjazne, pomocne i nie narzucające się.

@VietnhiPhuvan Jako osoba z zaburzeniem emocjonalnym / psychicznym, a także z jasnym zestawem tego, co jest etyczne, a co nie ..... Uważam, że nie tylko ponowne użycie Rainmana na początku, a potem Headcase na końcu jest dość odrażające.
„Widzisz obelgi tam, gdzie ich nie widzę”, po pierwsze, wyzwiska nie są profesjonalne. Po drugie, ludzie reagują na nie inaczej, jak na wszystko.Oczywiście moglibyśmy powiedzieć „po prostu to zignoruj”, ale osobiście uważam, że każdy ma prawo nie pozwalać innym nazywać się inaczej (lub po tytule zawodu).W końcu są zakazane przez zasadę Bądź miły, więc nawet jeśli, jestem tego pewien, nie masz na myśli nic złego, naprawdę lepiej w ogóle ich unikać.
Dzięki za edycję!Jednak teraz nie widzę tutaj praktycznej porady.


To pytanie i odpowiedź zostało automatycznie przetłumaczone z języka angielskiego.Oryginalna treść jest dostępna na stackexchange, za co dziękujemy za licencję cc by-sa 3.0, w ramach której jest rozpowszechniana.
Loading...