Niedawno mój współpracownik opuścił naszą firmę. Przed odejściem zakodował komponent, który miał poważny wyciek pamięci, który spowodował przestój produkcji ( OutOfMemoryErrorw Javie). Problem polegał na HashMaptym, że narastał i nigdy nie usuwał wpisów, a rozwiązaniem było zastąpienie go HashMapimplementacją pamięci podręcznej.

Z profesjonalnego punktu widzenia uważam, że powinienem poinformować go o usterce, aby mógł uczyć się na błędach. Z drugiej strony, kiedy ludzie opuszczają firmę, często nie chcą słyszeć o starszych projektach, które zostawili za większymi i lepszymi rzeczami.

Jaki jest ogólny protokół dla tego rodzaju sytuacji?

Nie ścigasz byłego kolegi, żeby powiedzieć mu, że popełnił błąd. Możesz powiedzieć swojemu przyjacielowi, że popełnił błąd.

To, czy jest przyjacielem, czy byłym kolegą, zależy od ciebie.

Nic nie robić.

1. Kontaktowanie się z kimś wyłącznie w celu poinformowania go, że coś spieprzyło, ale naprawiliśmy to, jest nieprofesjonalne i bez względu na to, jak bardzo się starasz, prawdopodobnie nigdy nie zostanie pozytywnie odebrany.
2. Mówienie wystarczająco głęboko, aby rozmowa była zdalnie przydatna na temat kodu dla osób niebędących pracownikami, jest zła, niezależnie od potencjalnych problemów NDA.

Jeśli jesteś objęty umową NDA, to jest bardzo nie na temat rozmowy z kimś spoza firmy na temat problemów związanych z własnością intelektualną, bez względu na to, czy są to byli pracownicy, czy nie.

Jeśli nie jesteś objęty umową NDA, zaryzykuję stwierdzenie, że nie będzie go to obchodzić.

Poza tym, czy ta osoba była niezadowolona? Czy było to coś, co mogło być zamierzone?

Z tak prostym błędem szanse są dobre, jeśli przeszkadza to współpracownikowi, prawdopodobnie zdali sobie sprawę z problemu kilka dni później, zastanawiając się nad tym. Wiem, że wróciłem do domu z pracy i zdałem sobie sprawę „… cholera, ten algorytm jest całkowicie wadliwy, będę musiał go powtórzyć jutro”, jednocześnie odpoczywając i wspominając mój dzień.

Ten współpracownik jest Twoim PRZYJACIELEM, z którym nadal masz bliski kontakt po odejściu? Jeśli tak, porozmawiaj o tym, jeśli / kiedy pijesz piwo w barze.

W przeciwnym razie po co zawracać sobie głowę?

PS .: Na czym polega tajemnica NDA? Pan X i tak napisał kod, a jeśli odejście nastąpiło niedawno, oprogramowanie działa na tym samym poziomie ujawnienia.

Sytuacja wyglądałaby inaczej, gdyby ta rozmowa miała miejsce 3 lata po odejściu, a Ty powiedziałeś rzeczy, o których nie musiałby wiedzieć, oprócz Ciebie

To zależy od tego, jak ta osoba opuściła i twojego związku z nią.

A co cię obchodzi? Widzę, że chcesz mu pomóc „uczyć się na błędach”, ale czy naprawdę? Czy pokażesz mu dzienniki * i ślad stosu *? Czy pokażesz mu kroki, które podjąłeś, aby zdiagnozować problem? Czy pokażesz mu źródło *, żeby mógł zobaczyć, gdzie był problem?

Jeśli nie, to prawdopodobnie marnujesz jego czas i swój.

* Czy będziesz miał kłopoty z ujawnieniem aktywów / danych firmy osobom niebędącym pracownikami?

Jeśli zdecydujesz się mu powiedzieć, upewnij się, że powiesz również wszystkim recenzentom jego kodu! Są równie odpowiedzialni! Dla mnie brzmi to tak, jakbyś nie dogadał się z tym facetem i chcesz go wykopać. Odpuść, raczej nie będzie go to obchodzić.

Prawdopodobnie nie

Wydaje mi się przede wszystkim bezcelowe, czy są to przyjaciele czy koledzy. A w niektórych okolicznościach być może szkodliwe dla nich, dla ciebie i dla twoich relacji z nimi.

Wszyscy popełniamy sporadyczne błędy.

W rzeczywistości jedynym czynnikiem, który zmusiłby mnie do powiedzenia wspomnianym kolegom, jest to: czy to błąd, o którym wiem, że zwykle by tego nie robili / sytuacja, o której wiem, że potrafiliby sobie poradzić?

Jeśli odpowiedź brzmi „tak”, nie ma potrzeby ich poprawiać, ponieważ prawdopodobnie nie ma dla nich żadnej wartości edukacyjnej , więc nie widzę obowiązku informowania ich. W przypadku uruchomienia przez nich jeden dzień lub plan mają napoje na ich ostatniego dnia i masz dobre relacje z nimi jako rówieśnikami i innymi specjalistami, pewien, że mógłby go wymienić, bardziej karmić jakąś przyjazną lub nieszkodliwe żarty niż cokolwiek innego.

Jeśli odpowiedź brzmi „nie”, może istnieć obowiązek (nie nazwałby to „profesjonalnym”), aby wyciągnąć rękę i pomóc im zrozumieć swój błąd.

Zachowaj cywilność

Większość ludzi nie lubi krytyki na temat swojej pracy, programiści / programiści tym bardziej, a odchodzący programiści prawdopodobnie mieliby jeszcze mniejszą tolerancję. Po co ryzykować irytować ich i sprawiać wrażenie, że zostawiają złą notatkę?

Jasne, gdyby byli złymi pracownikami przez cały czas, to nie ma zastosowania, ale jeśli byliby wystarczająco wykwalifikowanymi kolegami programistów, nie rozumiem, dlaczego robiłbym wszystko, aby podkreślać ich błędy, chyba że jestem pewien, że oboje mogą się z tego śmiać. Ponownie, zakładając, że nie wyciągną z tego wiele nauki i będą po prostu zawstydzeni, że zostawili to za sobą.

Prawny?

Z innej perspektywy, jeśli opuścili firmę, tak naprawdę zależy to od umowy i polityki bezpieczeństwa firmy. Może nie być dozwolone przekazywanie kodu (lub innych rzeczy, o to chodzi) byłym kolegom.

Myśl pozytywnie

Wreszcie myślę, że jedyne sytuacje, w których skontaktowałem się z byłym kolegą, aby omówić bazę kodów, którą zostawili, to:

• poprosić o potwierdzenie czegoś podejrzanego podczas badania określonego obszaru kodu,
• pogratulować im odrobiny kodu, który uważałem za szczególnie mistrzowski, co pogorszyłoby moje życie, gdyby go nie było,
• podzielić się z nimi dobrymi wiadomościami o udanym wprowadzeniu na rynek, jeśli odeszli przed nim (lub podobnymi dużymi ogłoszeniami dotyczącymi produktu, nad którym kiedyś pracowali).

Ucz się na błędach

Na pewno możesz wskazać błąd reszcie zespołu, aby upewnić się, że nie powtórzy się on z pozostałymi członkami. Nie trzeba wskazywać na rzeczywisty błąd w SCM ani na autora, to nie jest wina.

To nie wchodzi w zakres pytania, ale nadal zwracam uwagę, że powinieneś upewnić się, aby naprawić błąd, udokumentować jego pochodzenie, wpływ i rozwiązania oraz wdrożyć test, aby nie pojawiał się ponownie, jeśli to możliwe.

Mówienie komuś może być niezgodne z prawem. O ile kod nie jest open source, pozwól śpiącym psom kłamać.