Hace poco, un compañero de trabajo dejó nuestra empresa. Antes de irse, codificó un componente que tenía una pérdida grave de memoria que causó una interrupción de la producción ( OutOfMemoryErroren Java). El problema era esencialmente HashMapque crecía y nunca eliminaba las entradas, y la solución era reemplazarlas HashMapcon una implementación de caché.

Desde un punto de vista profesional, creo que debería informarle sobre el defecto para que pueda aprender del error. Por otro lado, una vez que las personas dejan una empresa, a menudo no quieren escuchar sobre proyectos heredados que han dejado para cosas más grandes y mejores.

¿Cuál es el protocolo general para este tipo de situación?

No cazas a un antiguo colega para decirle que cometió un error. Puede decirle a su amigo que cometió un error.

Si él es un amigo o un ex colega, depende de usted.

Hacer nada.

1. Ponerse en contacto con alguien simplemente para decirles que se equivocaron pero lo arreglamos, no es profesional y no importa cuánto lo intente, es poco probable que lo reciban de manera positiva.
2. Hablar lo suficientemente profundo como para que una conversación sea remotamente útil sobre el código para los no empleados es malo, independientemente de los posibles problemas de NDA.

Si está bajo un NDA, entonces es un gran no-no hablar con alguien fuera de su empresa sobre cualquier problema relacionado con la propiedad intelectual, ya sean ex empleados o no.

Si no está bajo un NDA, me atrevería a decir que no le importará.

Aparte de eso, ¿estaba esa persona disgustada? ¿Fue algo que en realidad podría haber sido intencional?

Con un error así de simple, las probabilidades son buenas si molestaba al compañero de trabajo, probablemente se dieron cuenta del problema un par de días después mientras reflexionaban sobre ello. Sé que me fui a casa del trabajo y me di cuenta "... mierda, ese algoritmo es totalmente defectuoso, tendré que rehacerlo mañana" mientras me relajo y recuerdo mi día.

Este compañero de trabajo es tu AMIGO, ¿con quién sigues teniendo contacto cercano después de la partida? En caso afirmativo, hable sobre eso si / cuando está tomando cervezas en el bar.

De lo contrario, ¿por qué molestarse?

PD .: En cuanto a la NDA, ¿cuál es el secreto aquí? El Sr. X es el que escribió el código de todos modos y si la salida es reciente, el software continuará en el mismo nivel de divulgación.

Las cosas serían diferentes si esta charla ocurre 3 años después de la partida y usted cuenta cosas que él no tendría que saber excepto usted ...

Depende de cómo se fue esta persona y su relación con él / ella.

Además, ¿qué te importa? Veo que quieres ayudarlo a "aprender del error", pero ¿de verdad? ¿Vas a mostrarle los registros * y el rastro de la pila *? ¿Le vas a mostrar los pasos que tomaste para diagnosticar el problema? ¿Le va a mostrar la fuente * para que pueda ver dónde estaba el problema?

Si no, entonces probablemente estés perdiendo su tiempo y el tuyo.

* ¿Te vas a meter en problemas por revelar los activos / datos de la compañía a un no empleado?

Si decides decírselo, ¡asegúrate de contarle a todos los revisores de su código también! ¡Son igualmente responsables! Para mí, parece que no te llevas bien con este chico y quieres cavar en él. Déjalo ir, es poco probable que le importe.

Probablemente no

Me parece sobre todo inútil, ya sean amigos o colegas. Y, en algunas circunstancias, posiblemente perjudicial para ellos, para usted y para su relación con ellos.

Todos cometemos errores ocasionales.

De hecho, el único factor que me haría querer decirles a dichos colegas es este: ¿es un error que sé que normalmente no harían / ​​una situación que sé que sabrían cómo manejar?

Si la respuesta es sí, no hay necesidad de molestarlos, ya que probablemente no haya un valor educativo para ellos, por lo que no veo el deber de informarles. Si los encuentra algún día o planea tomar bebidas en su último día y tiene una buena relación con ellos como compañeros y profesionales, seguramente, podría mencionarlo, más para alimentar algunas bromas amistosas o inofensivas que cualquier otra cosa.

Si la respuesta es no, entonces podría haber una obligación (aunque no la llamaría "profesional") de comunicarse y ayudarlos a comprender su error.

Mantenlo civil

A la mayoría de las personas no les gustan las críticas sobre su trabajo en general, los desarrolladores / programadores aún menos, y los programadores salientes probablemente tendrían incluso una tolerancia más baja. ¿Por qué correr el riesgo de molestarlos y darles la impresión de que se van con una mala nota?

Claro, si fueron malos empleados en todo momento, esto no se aplica, pero si de otro modo fueran compañeros programadores suficientemente hábiles, no veo por qué me esforzaría para enfatizar sus errores, excepto si puedo estar seguro de que ambos pueden reírse. Una vez más, suponiendo que no aprenderían mucho de él y se mortificarían de haber dejado eso atrás.

¿Legal?

Desde un ángulo de enfoque diferente, si han abandonado la empresa, realmente depende de su contrato y de las políticas de seguridad de su empresa. Es posible que no se le permita llevar el código (u otras cosas, para el caso) a antiguos colegas.

Piensa positivo

Finalmente, creo que las únicas situaciones en las que contacté a un ex colega para discutir una base de código que dejaron fueron:

• para solicitar una confirmación sobre algo sospechoso mientras investiga un área particular del código,
• felicitarlos por un poco de código que encontré particularmente magistral y que habría empeorado mi vida si no estuviera allí,
• compartir las buenas noticias de un lanzamiento exitoso con ellos si se fueron antes de que sucediera (o grandes anuncios similares relacionados con un producto en el que solían trabajar).

Aprender de sus errores

Lo que seguramente puede hacer es señalar el error al resto del equipo, para asegurarse de que no vuelva a ocurrir con los miembros restantes. No es necesario señalar el error real en SCM o al autor, no es un juego de culpa.

Está fuera del alcance de la pregunta, pero aún quiero señalar que debe asegurarse de corregir el error, documentar sus orígenes, impactos y resoluciones e implementar una prueba para que no vuelva a aparecer, si es posible.

Puede que no sea legal decirle a alguien. A menos que el código sea de código abierto, deje que los perros duerman.