Nie, to nie jest normalne. Spotkaliście jednak dość pospolitą bestię, elitarnego programistę z super uprawnieniami. Jest mądrzejszy niż wszyscy inni w swoim umyśle i ma prawo być niegrzeczny z tego samego powodu. Ma topór do ocierania z Morty'm. Unikaj go, jeśli to możliwe, i idź dalej.

Chociaż z pewnością ma on prawo do samodzielnego zbadania problemu, cywilizowana odpowiedź brzmi: „Dzięki za sugestię, przyjrzę się temu”. Może wcześniej istnieć zła krew między nimi lub może być po prostu zdziczały, ale w obu przypadkach, chociaż takie zachowanie nie jest nieznane w technologii, jest nie do przyjęcia lub „zwyczajne”.

Jako programista uważam, że pierwszy raport jest bardzo przydatny. Żadnego długiego wyjaśnienia, żadnego długiego śladu valgrind do przeczytania. Dzięki tej poprawce mogłem od razu zobaczyć, na czym polega problem, a gdybym pracował nad tym kodem niedawno, prawdopodobnie wiedziałbym, czy jest to poprawna poprawka, czy nie, nawet bez sprawdzenia kodu. Więc odpowiadałbym po prostu „Dziękuję za złapanie” lub „Dziękuję, ten wskaźnik nie powinien być udostępniany, ale wiem, jak rozwiązać ten problem teraz, gdy zwróciłeś mi na to uwagę” lub coś w tym rodzaju.

Poza tym nie dostrzegam w wiadomości żadnego poczucia wyższości.

Teraz CC''Każdy może być zły lub nie. Kod może być czymś, o czym wiedzą również inni, więc jeśli lista odbiorców CC jest wystarczająco krótka, to dobrze. Mail jest wystarczająco krótki i każdy może od razu zobaczyć z łatki, czy powinien być zainteresowany, czy nie, marnując tylko trochę czasu. Jednak jeśli są ludzie, którzy nie są zaangażowani w tę bazę kodu źródłowego w CC, to było to niewłaściwe.

Inną kwestią jest to, czy dana osoba powinna spędzać czas na debugowaniu takiego problemu. Jeśli jednak nie osiągają własnych celów, przejęcie odpowiedzialności za całe oprogramowanie, takie jak to, jest na ogół bardzo cenną cechą. Pokazuje entuzjazm i troskę, naprawdę rzadką rzecz. Te rzeczy mogą zajść za daleko, ale o wiele częściej spotyka się kolegów z zespołu, którzy nie mogliby mniej przejmować się błędem w czyimś kodzie, chyba że miał on na nich bezpośredni wpływ.

Aby odpowiedzieć tytułowe pytanie. Ton Morty'ego w przedstawionym tu brzmieniu jest moim zdaniem profesjonalny i normalny. Ton Ricka ... niestety też nie jest taki niezwykły, ale niefortunny. Wszyscy mamy jednak złe dni, więc nie będę dalej analizować ani jednej anonimowej wiadomości. Może to być zły znak (i ​​wygląda na to, TBH) lub może być częścią całkiem przyzwoitej kultury pracy, do której wystarczy się przyzwyczaić.

Wiem, że odpowiedź na to pytanie została już udzielona i zgadzam się z zaakceptowaną odpowiedzią, ale chciałem tylko rozszerzyć to o więcej informacji.

To, co tu widzisz, to potencjał XY problem. Uważam, że problemy XY są czymś, o czym każdy rozwiązujący problemy (nie tylko programiści) powinien wiedzieć i unikać.

Zasada problemu XY jest dość prosta:

• X to problem i należy go naprawić.
• Y jest rozwiązaniem, ale nie najlepszym rozwiązaniem. Niezależnie od tego, jest wybierany (przez lenistwo lub niezrozumienie, że istnieje lepsze rozwiązanie)
• Kiedy pojawia się problem z implementacją Y, ludzie poświęcają czas na próbę uruchomienia Y, zamiast na szukanie tam to rozwiązanie Z, które pasuje lepiej.

Jako jasny przykład:

• X = Chcę posortować dane w Excelu.
• Y = Potrafię napisać aplikację do sortowania danych i zapisywania pliku.
• Z = Powinienem nauczyć się korzystać z funkcji sortowania programu Excel.

Zasadniczo jest to co się stało w e-mailu Morty'ego. Rick nie jest w stanie oznaczyć żądania jako Y lub Z, ponieważ Morty nie wyjaśnia X. Wyjaśnienie X jest ważniejsze niż zaoferowanie rozwiązania Y / Z, ponieważ Rick jest w stanie znaleźć Z, gdy zna X, ale może ” t zgadnij X znikąd.

Oto problem X:

wyciek pamięci w części kodu platformy

Zauważ, że jest to dość niejasne. Jaki był problem? Gdzie to się stało? Kiedy to się stało? Czy to był przypadek skrajny?

Następnie Morty proponuje rozwiązanie Y. Ponieważ nie znamy specyfiki X, nie mamy możliwości sprawdzenia, czy Y jest odpowiednim rozwiązaniem dla X.

Dlatego Rick się temu przeciwstawia. Został poproszony o zmianę czegoś (i efektywne wzięcie odpowiedzialności za zmianę czegoś) bez możliwości wyboru . Morty skutecznie podważył odpowiedzialność Ricka (pisanie dobrego kodu) i zastępuje ją prośbą o ślepe zaufanie, że oferowany kod jest odpowiedni i dobry.

Pomyśl o tym w ten sposób: Jesteś policjant. Podchodzi do ciebie mężczyzna i mówi „Chcę, żebyś aresztował tego człowieka” (Y).

Policjant nie powinien się podporządkować, ponieważ nie jest w stanie osobiście potwierdzić, że aresztowanie mężczyzny jest uzasadnione.

Gdyby jednak mężczyzna powiedział „ten człowiek właśnie zabił kogoś z zimną krwią”, wówczas policjant jest w stanie zrozumieć problem i sam zdecydować o jego rozwiązaniu (aresztowaniu mężczyzny).

Zasadniczo to właśnie Morty zrobił źle. Myślę, że Rick mógłby sformułować to bardziej uprzejmie (gdyby to było Interpersonal.SE Zdecydowanie przeformułowałbym niektóre zdania Ricka), ale jego prośba jest słuszna.

Ignorując, czy istnieje między nimi napięcie, ogólny problem z komunikacją lub standardowy ton w twoim miejscu, skupię się na twoim pytaniu:

Czy ten ton jest niezwykły w technologiczne miejsce pracy?

Nie , ten ton nie jest całkowicie niezwykły.

1. Ludzie w branży są przyzwyczajeni do syntaktycznych języków programowania, a dokładne specyfikacje techniczne często zapominają o tonie w ich komunikacji. Często nie stanowi to problemu, o ile osoby postronne nie są zaangażowane w komunikację. Przyzwyczaj się do wielu prostych wiadomości.

2. To banał, ale tak, są też tacy nerdowie, którzy mają po prostu kiepskie relacje społeczne umiejętności, więc lepiej naucz się radzić sobie z nimi i nie brać tego do siebie.

3. Dla wielu programistów „ich” kod jest ich dzieckiem. Wskazanie na pewne niezaprzeczalne błędy to jedno - majstrowanie przy nim może po prostu uruchomić pewne mechanizmy obronne.

To powiedziawszy, można to zrobić w lepszy sposób. Z reguły, aby uniknąć takich problemów:

• Chwal publicznie, krytykuj prywatnie.
• Jeśli masz z kimś problem, w ogóle nie używaj do tego poczty e-mail!
• Jeśli znajdziesz błąd, zgłoś go za pomocą standardowego mechanizmu akceptowanego przez zespół.
• Nie wykonuj nikogo innego, chyba że zostaniesz o to poproszony.

Jego sentyment ma pewną wartość . Wiem wiele razy, kiedy moje przeczucie co do pierwotnej przyczyny doprowadziło kogoś na złą ścieżkę i zmarnowałem jego czas.

W przypadku większości problemów każda osoba ma pewne przeczucia, które po prostu „wyskakują”. Myślę, że warto spróbować wykorzystać tę moc. Kiedy potrzebuję pomocy w sprawie błędu, na którym utknąłem, staram się unikać narzucania im własnych przeczuć, aby być może ich własne były nowatorskie i produktywne.

Ale sposobem, w jaki to wyraził ... . był totalnym dupkiem.

Oczywiście nie wszyscy się z tym zgadzają, ale IMO to normalna odpowiedź, nie bierz tego do siebie .

To łatwy do zrozumienia e-mail, on uzasadnia swoje powody dlaczego woli nie słyszeć twojego rozwiązania (nie dlatego, że jest to twoje rozwiązanie, ale dlatego, że chce na początek pustą kartę).

To nie jest osobiste dla ciebie lub obraźliwe lub w ogóle podważające, to wyjaśnienie. Dla niektórych jest to trochę bezpośrednie, ale często jest to dziwactwo programistów, bycie bezpośrednim i (zbyt) rzeczowym. Można było przeczytać cały ten e-mail normalnym tonem głosu, w którym wyjaśniał swoją metodę, którą preferował. Tylko dlatego, że nie jesteś jego fanem, nie oznacza, że ​​jest to zła praktyka, spotkasz wielu ludzi, którzy będą pracować inaczej niż ty.

Zgadzam się, że może to być trochę sformułowane bardziej uprzejmie, ale znowu, programista często po prostu mówi, co ma na myśli, bez tych wszystkich załadowanych interpretacji (co nie jest wymówką, ale może to być wyjaśnienie).

Jego zadaniem jest naprawianie problemów, a nie Twój. Po prostu spędziłeś czas na czymś, co mogłoby być użyte w inny sposób. Nie zrozum mnie źle, ćwiczenie poprawiania błędów jest ważne! Ale przestudiuj zastosowane rozwiązanie i porównaj je ze swoim. Twoje rozwiązanie może wydawać się w porządku, ale doświadczenie może cię nauczyć inaczej.

Obie strony są tu winne.

Morty nie powinien był dzwonić do wszystkich w pierwszym e-mailu. Robiąc to, zawstydził Ricka, wskazując wszystkim swój błąd. Nie wiem, czy Morty próbował w ten sposób zdobyć punkty, czy też był po prostu głupcem. Jednak wynik był taki sam z punktu widzenia Ricka. Morty'emu byłoby lepiej, gdyby wysłał tę wiadomość e-mail tylko do Ricka, aby mogli rozwiązać problem bez konieczności złego wyglądu.

Rick był zażenowany, że jego błąd został ujawniony publicznie źle. Nie powinien był uśpić Morty'ego. Nie powinien publicznie krytykować Morty'ego za próbę pomocy.

Jeden przykład wymiany e-maili nie mówi nam nic o kulturze firmy. Jeśli jednak wysyłanie publicznych wiadomości e-mail wskazujących na błędy innych osób i wysyłanie wiadomości e-mail z informacją, że nie powinni oferować pomocy, jest powszechne, ponieważ istnieje toksyczna kultura.

Niestety, tego rodzaju toksyczna kultura jest powszechna w oprogramowaniu firm w Stanach Zjednoczonych. Wiele z nich zostało napisanych [1] [2] [3] i mówi o sposobie, w jaki określony typ inżynierów oprogramowania traktuje innych, zwłaszcza tych, którzy - inżynierów oprogramowania i ludzi, którzy nie pasują do ich stereotypu inżyniera oprogramowania.

Ta kultura nie jest właściwym sposobem traktowania ludzi. Dobra firma, menedżerowie i współpracownicy nie tolerują tego rodzaju kultury. Dobrzy pracownicy nie pokazują sobie publicznie błędów, a dobrzy pracownicy nie odrzucają pomocy innych.

Musisz zrozumieć, że takie zachowanie jest akceptowalne w kulturze Twojego działu i firmy. Jeśli myślisz, że jesteś w firmie, która jest akceptowana, musisz zdecydować, czy uważasz, że możesz zmienić kulturę i czy jest to niewystarczające. Ważne jest, aby dowiedzieć się, czy ta kultura pochodzi od przywództwa, czy nie. Jeśli przywództwo daje zły przykład, nic nie możesz zrobić. Jeśli jest to kultura oddolna, masz szansę przekonać ludzi do zmiany. To będzie długa ciężka praca, więc lepiej zdecyduj, czy firmę warto naprawić.

Normalność jest dość subiektywna, zwłaszcza że nie masz pojęcia o historii tego miejsca pracy.

Albo Rick ma okropne umiejętności interpersonalne, albo między tymi dwoma osobami jest coś złego.

Możliwe, że Morty celowo przygotował „rozsądną” wiadomość e-mail, mając nadzieję, że wywoła Ricka.

Ponieważ jesteś nowy, będziesz musiał ocenić, czy to toksyczne zachowanie rozprzestrzeniło się również na innych, czy też jest zamknięta sytuacja.

Cokolwiek się stanie, po prostu nie pozwól, aby rozprzestrzeniło się to na twoją osobowość.

Piszę to z perspektywy menedżera z doświadczeniem obejmującym wiele aspektów tego typu scenariuszy.

Czy to normalne w firmach technologicznych?

Jest to całkowicie normalne dla każdej firmy w praktycznie każdej branży, nie tylko technicznej.

Mówiąc najogólniej, e-mail wysłany do wszystkich członków zespołu programistów, :

• wskazał podejrzewaną usterkę („Myślę, że znalazłem wyciek pamięci ...”)
• stwierdził, że znaleziono rzekome rozwiązanie („ wierzę , że znalazłem źródło i problem ...”)
• przedstawił listę pralni poprawki do zaimplementowania

Uogólniając, dzieje się tutaj to, że Rickowi zostaje przekazana dyrektywa zawierająca uzasadnienie dyrektywy, a następnie wyszczególniająca specyfiki wspomnianej dyrektywy.

To dodatkowo komplikuje sprawę, ponieważ dyrektywa została przekazana w grupie (w kopii zapasowej do wszystkich członków e zespół).

Relacje organizacyjne Ricka i Morty'ego

Nie znamy relacji w odniesieniu do tych dwóch osób. Można to jednak ogólnie podsumować jako jedną z trzech możliwości:

• Rick jest starszy od Morty'ego
• Morty jest starszy od Ricka
• Rick and Morty są równi

Czy Rick ma przyjąć dyrektywę od Morty'ego?

• Nie? W takim razie Rick ma prawo odpychać
• Tak? W takim razie nie ma potrzeby, aby wszyscy byli w posiadaniu CC. Rick ma nadal uzasadnienie, mówiąc Morty'emu, jak najlepiej wykonuje swoją pracę.

Sytuacja nie wyglądałaby inaczej, gdyby była ....

• Medyczne. Dr Oz mówi Dr No, że zdiagnozował pacjenta Dr No i zrobił X, Y i Z bez podawania objawów dr. No.
• Automotive. Inżynier 1 informuje Inżyniera 2, że znaleziono problem w konstrukcji zawieszenia Inżyniera 2, a rozwiązaniem jest przyspawanie wypustki A do szczeliny B bez podawania danych testowych, aby pokazać problem.
• Pomoc techniczna - Tech 1 informuje Tech 2, że wystąpił problem z systemem Tech 2 i rozwiązaniem jest wdrożenie poprawek A, B i C bez dostarczania komunikatów o błędach wskazujących na problem.

TL; DR

Podsumowując, osoba odpowiedzialna za wykonanie właściwej naprawy mówi jej, czego potrzebuje, aby prawidłowo wykonać pracę. Jedyną osobą, która jest potencjalnie „poza linią”, jest Morty ze względu na pasywne agresywne zachowanie polegające na dzwonieniu do wszystkich.

Dzieje się to każdego dnia w każdej branży. To nic nowego ani niezwykłego.

  --- a / spacehip / DoBattle.cpp +++ b / spacehip / DoBattle.cpp vector<part> parts = getSpaceShipParts (); + shared_ptr<SpaceShip> p = nowy SpaceShip (części); -SpaceShip * p = nowy SpaceShip (części); angażować się w bitwę (p, wróg); 

Niestety ta zmiana naprawia błąd (udawanie, że test Valgrind jest adaquote), ale wprowadza coś niepożądanego, walkę z filozofią kodu. Jeśli nie jesteś stałym współpracownikiem, nie wdawaj się w walki z filozofią kodu.

Aby uniknąć walki z filozofią, zamiast tego powinno zostać wysłane. Tak, jest obiektywnie gorszy, ale jest zgodny ze stylem już istniejącego kodu:

  --- a / spacehip / DoBattle.cpp +++ b / spaceShip / DoBattle.cpp SpaceShip * p = nowy statek kosmiczny (części); angażować się w bitwę (p, wróg); + usuń p;  

Ale z tą odpowiedzią dewelopera, zakładam, że on też by się nie spodobał. Słyszę ten ton trochę za dużo, nawet od ludzi, którzy powinni wiedzieć lepiej. To nie jest normalne, ale wystarczy, że często to słyszysz. Jestem rozczarowany.

1) Komunikacja: OP sprawia, że ​​wydaje się, że standardową praktyką jest cc reszty zespołu programistów. Nigdy nie widzę powodu, by nie włączać reszty zespołu programistów do problemu / rozwiązania, które dotyczy wszystkich.

2) Problem / rozwiązanie: Nie widzę tutaj niczego złego. Należy to zrobić za pomocą żądania ściągnięcia, ale zakładając, że nie jest to możliwe, jest w porządku.

3) Odpowiedź: Tak wiele rzeczy jest nie tak, że nawet nie wiem, od czego zacząć.
a ) „Nie czytam sugerowanych poprawek”: To jest absolutnie okropne. Zawsze czytaj proponowany kod. Jest spora szansa, że ​​to lepsze niż cokolwiek, co możesz wymyślić ...
b) „Muszę poczekać kilka dni, zanim znajdę rozwiązanie”: Przetłumaczę to: „Muszę czekać kilka dni, zanim będę mógł całkowicie zignorować wykonaną pracę i odrzucić rozwiązanie. Nie tylko będę tracić czas na wdrożenie rozwiązania, ale także będę tracić więcej czasu na wymyślanie rozwiązania problemu, który został rozwiązany (przez napisany przez Ciebie kod, który odrzucę) "
c) 'zobacz, na czym polega prawdziwy problem i zobacz, jaka powinna być poprawka': przetestuj . Przetestuj, aby zobaczyć, czy jest problem. Następnie przetestuj go, aby zobaczyć, czy problem został rozwiązany. Nic nie zyskujesz, wymyślając własne rozwiązanie, które należy przetestować , zamiast testować proponowane rozwiązanie, aby sprawdzić, czy wszystko naprawia. Jeśli to nie rozwiąże problemu, wtedy możesz spróbować znaleźć poprawkę dla proponowanego rozwiązania lub całkowitą naprawę problemu.

W mojej firmie niezwłocznie i bez komentarza przekazał odpowiedź mojemu przełożonemu. To po prostu niedopuszczalne.