¿Tiene tacto ponerse en contacto con un desarrollador anterior?

¿Por qué no hablas de esto con tus superiores?

En circunstancias normales, consideraría brindar apoyo de emergencia para proyectos en los que trabajaron con empleadores anteriores como algo estándar, pero dado que no conoce las circunstancias, no asumiría nada: si se separaron en términos amistosos, no tendrá un problema, y ​​si no lo hicieran, tendrás que morder la bala, pero al menos no te crearás ningún problema de esa manera.

Si me pidieras que te ayudara con el código que había escrito hace más de 6 meses, no estoy seguro de que sería de mucha ayuda. Lo mismo puede ocurrir cuando se le pregunta a otra persona sobre el código que escribió hace años.

Sin embargo, digamos que recuerdo haber escrito el código en cuestión. Si puede hacerme algunas preguntas que no me llevarán más de 15 a 20 minutos responder de inmediato, entonces estaré feliz de ayudarlo, pero cualquier cantidad de esfuerzo más allá de eso, solo respondería si Me pagaron por mi tiempo.

Entonces, suponiendo que la persona a la que le preguntes recuerde el código y esté dispuesta a ayudar, haz todo lo posible para hacer las preguntas de tal manera que sean fáciles de responder en un tiempo muy limitado.

¿Es apropiado ponerse en contacto con este desarrollador anterior para obtener información sobre el código...

Por supuesto. Entiende que estás haciendo una solicitud personal. Comprenda también que el desarrollador anterior puede no recordar por qué las cosas se codificaron de cierta manera.

y si es así, ¿cuál sería una manera discreta de hacerlo?

Invítalo a cenar o algo equivalente que demuestre que aprecias su tiempo. Después del hecho, envíele una tarjeta de regalo con una nota de agradecimiento.

¿ Tiene tacto ponerse en contacto con un desarrollador anterior?

Sí, siempre que cuente con el apoyo de sus superiores.

¿Es prudente ponerse en contacto con un desarrollador anterior?

Depende completamente.

La mayor parte del código no tiene comentarios y ciertas partes no están documentadas en absoluto. El desarrollador en cuestión mantiene una presencia bastante considerable en las redes sociales y todavía está involucrado con la ingeniería de software en otras empresas.

Claramente, tiene motivos suficientes para ponerse en contacto con el desarrollador anterior. Pero todavía es útil preguntarse: "¿Qué esperamos obtener de este reencuentro?"

Esto es lo que quiero decir:

• Es probable que su reencuentro sea breve (a menos que esté tratando de persuadir al desarrollador anterior para que se reincorpore a su empresa).
• Teniendo en cuenta su brevedad, ciertamente necesita maximizar el uso del tiempo.

Invítalo a cenar o algo equivalente que demuestre que aprecias su tiempo. Después del hecho, envíele una tarjeta de regalo con una nota de agradecimiento. [De la respuesta de @Gilbert LeBlanc]

En la mayoría de los casos, desaconsejaría esta táctica.

¿Por qué?

Porque esto es un reencuentro profesional ; no es una llamada social. No está tratando de beber y cenar este desarrollador anterior; está tratando de obtener información importante y de misión crítica sobre su aplicación de software (que desafortunadamente no se documentó durante demasiado tiempo).

Dicho esto, debe pagarle a este desarrollador anterior una tarifa por hora por su tiempo . De esa forma, puede ser completamente pragmático y exigir valor por el tiempo de este desarrollador. Esto mantiene las cosas en el mismo nivel y evita cualquier malentendido sobre el propósito de este reencuentro. Para maximizar el uso de su tiempo, haga su debida diligencia antes de la reunión para que pueda hacer preguntas específicas y específicas sobre la parte de la aplicación de software que no comprende.

Con una compensación monetaria adecuada por la consulta sobre el sistema, la persona en cuestión está obligada a complacer su deseo insaciable de desentrañar los secretos casi olvidados de un código de una era más civilizada.

Si es apropiado o no depende de

• Cómo dejaron la empresa (despedidos/renunciar/todavía juegan al golf con el CEO)
• El dominio en el que se encuentra, dado que se trata de redes sociales, probablemente no sea una misión crítica para la empresa, pero si lo es, entonces tiene motivos para hacerlo.

Al final del día, depende del propio desarrollador decidir si le responde o no: no tiene ninguna obligación con la empresa en la que ya no trabaja y es posible que solo pueda responder uno o dos correos electrónicos dado que probablemente se han mudado a otra cosa.

Mi consejo es tratar esto realmente como último recurso.

Aparte, he respondido consultas sobre mi código después de que dejé una empresa, pero como era parte de una empresa de consultoría en ese momento, todavía tenía la obligación de ayudar, ya que todavía tenía otros miembros de mi empresa allí, no lo hago. sepa si esto se aplica a usted, pero si es así, es otra ruta que puede probar.

No, casi nunca es apropiado que te comuniques con alguien que ahora trabaja en otro lugar para que te ayude. De hecho, les estaría pidiendo que hagan más trabajo para su empleador anterior (su empleador actual) de forma gratuita, mientras trabajan también en su nuevo trabajo.

Esta documentación que tanto necesita ahora debería haberse hecho mientras aún estaban presentes. La gerencia debería haberse asegurado de que así fuera.

Ahora, puede ser apropiado que sus superiores que han trabajado con esta persona les pidan algún tipo de transferencia de conocimiento, y solo ellos pueden juzgar si es una buena idea o no, o en qué términos sucedería. .

Aquí hay una historia para poner las cosas en perspectiva:

Esta vez yo era un contratista en un proyecto que estaba retrasado, con recursos insuficientes, pero aún muy requerido por el negocio. En algún momento, levanté las manos y dije: "Chicos, esperen. Lo que estamos haciendo es inmantenible. Realmente deberíamos esforzarnos para asegurarnos de que este proyecto pueda sobrevivir si todos somos atropellados por un autobús mientras compartimos el almuerzo". ." Y la respuesta que recibí de la gerencia fue: "No nos importa, solo tíralo por la puerta lo antes posible y asegúrate de que funcione". - Así que eso es lo que hicimos. Una vez que estuvo en producción, todos los contratistas costosos fueron despedidos antes de que terminaran los términos del contrato. En términos generales, este era un caso de tratar con jefes de pelo puntiagudo que claramente estaban tratando de exprimir cada dólar del presupuesto. Ahora, ¿me siento mal por el pobre hombre que mantiene ese desastre? Claro que si. ¿Le voy a dar una hora extra a la empresa en cuestión? De ninguna manera, incluso si lo piden amablemente.

Entonces... ¿cómo sabes que no eres ese pobre hombre que mantiene ese proyecto? Nunca puedes estar seguro de cuáles fueron las circunstancias cuando alguien se fue, así que lo que hay que hacer es no hacer suposiciones.