Должен ли я рассказать покойному сотруднику об их дефекте «sev 1»? [закрыто]

13

Недавно мой сотрудник покинул нашу компанию. Перед уходом он закодировал компонент, у которого была серьезная утечка памяти, которая вызвала сбой в работе ( OutOfMemoryErrorна Java). По сути, проблема заключалась в HashMapтом, что записи росли и никогда не удалялись, и решением было заменить реализацию HashMapна кеш.

С профессиональной точки зрения, я чувствую, что должен сообщить ему о дефекте, чтобы он мог учиться на этой ошибке. С другой стороны, когда люди уходят из компании, они часто не хотят слышать о унаследованных проектах, которые они оставили для больших и лучших вещей.

Каков общий протокол для такой ситуации?

noahz
источник
сделать, вы можете сделать сообщение в блоге об этом, если это достаточно интересно
ratchet урод
14
Я бы сказал, оставь это в покое. Вашему коллеге, скорее всего, все равно, что случилось с тех пор, как он ушел. Вы ничего ему не должны, рассказывая ему по его ошибкам, потому что его ошибки - не ваша проблема.
Ramhound
6
Отправить его на codinghorror.com. Не называйте его, но включите достаточно деталей, чтобы он мог определить его как свою работу, когда он ее читает.
user16764
3
Кто-нибудь еще смотрел профиль ОП, чтобы убедиться, что это не они? Или это был только я ...
Адам V
4
@ user16764 - Думаю, ты имеешь в виду The Daily WTF ?
LeopardSkinPillBoxHat

Ответы:

112

Вы не выслеживаете бывшего коллегу, чтобы сказать ему, что он совершил ошибку. Вы можете сказать своему другу, что он допустил ошибку.

Является ли он другом или бывшим коллегой, зависит от вас.

jmoreno
источник
38
Кроме того , вы можете ребру своего друга несколько раз о своей ошибке - но опять - таки это зависит от того, насколько близко друг он ...
Билл K
Очень глубокий и краткий ответ! Я хотел бы дать вам больше, чем +1!
Математическая атака
+1 Кажется, мы думаем так же. Но ты объяснил это намного лучше.
Фабрицио Араужо
Не только самый популярный ответ, но тот, к которому я склонялся, когда задавал вопрос. Благодарность!
noahz
29

Ничего не делать.

  1. Связаться с кем-то просто, чтобы сказать, что он облажался, но мы исправили это, непрофессионально, и, как бы вы ни старались, вряд ли когда-нибудь получат положительный отклик.
  2. Недостаточно подробно говорить о том, чтобы разговор был полезен удаленно сотрудникам, не являющимся сотрудниками, - это плохо, независимо от потенциальных проблем с NDA.
Ryathal
источник
4

Если вы работаете в соответствии с NDA, говорить о проблемах, связанных с интеллектуальной собственностью, вне зависимости от того, являются ли они бывшими сотрудниками или нет, не стоит.

Если у вас нет NDA, я бы рискнул сказать, что ему / ей все равно.

Кроме этого, этот человек был недоволен? Было ли это что-то, что могло быть преднамеренным?

Демиан Брехт
источник
NDA или нет, я бы рискнул предположить, что если это не какой-то запуск в подвале, есть руководство для сотрудников и где-то там есть что-то о ненадлежащем поведении, таком как проветривание грязного белья компании, которое может привести к дисциплинарным взысканиям и / или увольнению ,
BryanH
1
Я не думаю, что проблема NDA была бы большой проблемой, если бы человек, с которым вы разговариваете, написал код в первую очередь ... единственное, что вы раскрываете, чего он не знал раньше, - это то, что он допустил ошибку. Тем не менее, я бы сказал, что это мой друг, а не случайный коллега, которого я едва знал или, скорее всего, ненавидел.
CaffGeek
1
Не будет ли бывший сотрудник по-прежнему под NDA?
BlueRaja - Дэнни Пфлюгофт
4

С такой простой ошибкой шансы хороши, если это беспокоило коллегу, они, вероятно, поняли проблему пару дней спустя, размышляя об этом. Я знаю, что ушел с работы домой и понял: «… дерьмо, этот алгоритм полностью испорчен, завтра мне придется его переделывать», пока я разворачиваюсь и вспоминаю свой день.

Yamikuronue
источник
1
Я хотел бы отключить мозг при выходе.
CaffGeek
1
@ Если бы не я, я делаю некоторые из моих лучших работ в машине на работу и с работы. Однако, когда я иду спать ...
Дарамарак
1
@daramarak Ты спишь? Я просто вхожу в подсознательное состояние кодирования. ;)
Yamikuronue
@Yamikuronue, хаха, хорошо. Я должен запомнить эту фразу.
CaffGeek
4

Этот сотрудник - ваш ДРУГ, с которым вы продолжаете поддерживать тесные контакты после ухода? Если да, поговорите об этом, если / когда вы принимаете пиво в баре.

Иначе зачем?

PS: Что касается NDA, в чем здесь секрет? В любом случае, г-н X написал код, и, если он уйдет совсем недавно, программное обеспечение останется на том же уровне раскрытия.

Все будет иначе, если этот разговор произойдет через 3 года после отъезда, и вы расскажете вещи, которые он не должен знать, кроме вас ...

Фабрицио Араужо
источник
WRT NDA, был бы секрет. Мог ли Ноах доверять бывшему коллеге, чтобы он не сказал всем, что Ноаз нарушил NDA? Это большой секрет Ноаза .
Эмори
Если это просто коллега, зачем вообще говорить об этом ? Близкий друг, который поменял работу, это другая история.
Фабрицио Араужо
2

Это зависит от того, как этот человек ушел и от ваших отношений с ним.

Кроме того, что вас волнует? Я вижу, что вы хотите помочь ему «учиться на ошибках», но действительно ли вы? Вы собираетесь показать ему логи * и трассировку стека *? Собираетесь ли вы показать ему шаги, которые вы предприняли для диагностики проблемы? Собираетесь ли вы показать ему источник *, чтобы он мог видеть, где была проблема?

Если нет, то вы, вероятно, тратите его и свое время.

* Будете ли вы попасть в беду за раскрытие активов / данных компании не сотруднику?

BryanH
источник
2
В этом случае это так же просто, как «вы назвали Map.put (K, V) и никогда не вызывали Map.remove (K) или Map.clear ()» - и, возможно, последующее обсуждение о том, какой тип реализации / конфигурации кэша для использовать.
noahz
6
@noahz - Это звучит как честная ошибка. Я бы даже не сказал, что стоит говорить об ошибке. Более интересный вопрос - причина, по которой вашему процессу не удалось обнаружить эту ошибку до того, как она была опубликована в производственной среде.
Ramhound
@Ramhound - это совершенно другой вопрос. Т.е. "как вы разрабатываете систему с высокой доступностью и высокой пропускной способностью при ограниченном бюджете?" Вы просто складываете руки и говорите "бизнесу" нет?
noahz
1

Если вы решите сказать ему, будьте уверены, что вы также сообщите всем рецензентам его код! Они одинаково ответственны! Для меня это звучит так, как будто вы не ладили с этим парнем и не хотите его раскопать. Отпусти его, ему вряд ли все равно.

Джеймс
источник
1

Возможно нет

Кажется, в основном бессмысленно для меня, будь то друзья или коллеги. И, в некоторых случаях, возможно, вредно для них, для вас и для ваших отношений с ними.

Мы все время от времени совершаем ошибки.

Фактически, единственный фактор, который может заставить меня захотеть сказать упомянутым коллегам, заключается в следующем: является ли это ошибкой, которую я знаю, что они обычно не делают / ситуация, которую, я знаю, они знают, как справиться?

Если ответ «да», нет необходимости их задавать, поскольку, вероятно, для них нет никакой образовательной ценности , поэтому я не вижу обязанности информировать их. Если вы сталкиваетесь с ними в один прекрасный день или планируете выпить в последний день, и у вас есть хорошие отношения с ними как со сверстниками и коллегами-профессионалами, конечно, вы могли бы упомянуть об этом больше, чтобы накормить какого-нибудь дружелюбного или безобидного подшучивания, чем что-либо еще.

Если ответ «нет», то может возникнуть обязанность (не назову это «профессиональным»), чтобы протянуть руку и помочь им понять свою ошибку.

Держите это Гражданским

Большинство людей не любят критиковать свою работу в целом, разработчики / программисты тем более, а ушедшие программисты, вероятно, будут иметь еще меньшую терпимость. Зачем рисковать их раздражать и создавать впечатление, что они оставляют плохую ноту?

Конечно, если бы они были плохими сотрудниками повсюду, это не относится, но если бы они были достаточно опытными коллегами-программистами, я не понимаю, почему бы изо всех сил подчеркнуть их ошибки, кроме как, если я могу быть уверен, что мы оба могут смеяться над этим Опять же, если предположить, что они не многому научатся на этом и просто будут огорчены тем, что оставили это позади.

Правовой?

С другой стороны, если они покинули компанию, это действительно зависит от вашего контракта и политики безопасности вашей компании. Вам может быть запрещено принимать код (или другие вещи, если на то пошло) бывшим коллегам.

Мыслить позитивно

Наконец, я думаю, что единственные ситуации, когда я обратился к бывшему коллеге, чтобы обсудить кодовую базу, которую они оставили, были:

  • запрашивать подтверждение чего-то сомнительного при исследовании конкретной области кода,
  • чтобы поздравить их с кодом, который я нашел особенно искусным, и это сделало бы мою жизнь хуже, если бы ее там не было,
  • поделиться с ними хорошими новостями об успешном запуске, если они ушли до того, как это произошло (или аналогичными крупными объявлениями, касающимися продукта, над которым они работали).

Учитесь на их ошибках

Что вы можете сделать, так это указать на остальную часть команды, чтобы она не повторилась с остальными участниками. Не нужно указывать на фактическую ошибку в SCM или на автора, это не вина игры.

Это выходит за рамки вопроса, но я все же указал бы на то, что вы должны обязательно исправить ошибку, задокументировать ее происхождение, последствия и решения, а также внедрить тест, чтобы он больше не появлялся, если это возможно.

haylem
источник
0

Это может быть не законно, чтобы сказать кому-то. Если код не с открытым исходным кодом, пусть спящие собаки лгут.

MathAttack
источник