¿Cómo lidiar con un compañero de trabajo senior que escribió su propio lenguaje de programación? [cerrado]

Vamos a darle a su pregunta un poco de contexto.

Su empresa tiene:

• Un producto de 25 años.
• Un desarrollador back-end sénior con considerable conocimiento institucional
• Suposición: varios desarrolladores intermedios/junior
• Un deseo de modernizar el medio ambiente.
• Una capa de traducción

Lista no exhaustiva de requisitos de la capa de traducción:

• Transformación de mensajes
• Validación de mensajes
• Conectividad de base de datos
• Integración de red con sistemas de terceros
• Manejo de datos
• Ejecución condicional compleja

Por lo tanto, esta capa de traducción se puede llamar en su lugar middleware de integración . Maneja la lógica comercial no relacionada con el producto subyacente de 25 años, con (espero) diferentes flujos y paradigmas.

Hay varios aspectos que yo llamaría Bad Ideas™, pero la existencia de un middleware de integración no es uno de ellos. Lo peor, en mi humilde opinión, es la falta de documentación : puede originarse en el hecho de que solo tiene un desarrollador con suficiente experiencia para visualizar todo el proceso. Debe documentar el proceso para que, si lo atropella un autobús, el desarrollo no se detenga en seco. También disminuirá la necesidad del equipo de desarrollo de tareas de soporte de API.

Acerca del servidor Node: me veo obligado a estar de acuerdo, al menos inicialmente, con su arquitecto. Dividir la lógica de negocios en diferentes plataformas/lenguajes sin una fuerte razón arquitectónica puede llamarse Bad Idea™. Dos bases de código para mantener, dos conjuntos de requisitos para nuevos puestos de trabajo. Es posible que se hayan aplicado aquí los principios de KISS para reducir costos.

No digo que no se deba tomar esta decisión, pero se deben tener en cuenta todos los costos (reentrenamiento, mapeo de procesos, validación de flujo, etc.), y su arquitecto probablemente los conozca. El lenguaje utilizado para codificar el producto heredado puede suspenderse, por ejemplo, forzando una migración completa a una plataforma diferente, y se podría elegir una implementación completa de NodeJS como Plan A.

Aún así, creo que el deseo de mejorar la situación actual es admirable y valioso, y en lugar de pelear una batalla cuesta arriba, sugeriría un plan diferente.

El hecho de que el desarrollador senior esté liderando el esfuerzo de middleware sugiere que no es adverso al cambio y que es un profesional capaz. Comparta su punto de vista con él y escuche sus comentarios. Él puede apreciar el hecho, ofrecer su propio punto de vista (lo que le ayudará a comprender la lógica del estado actual) y considerar su deseo de modernizar la solución teniendo en cuenta todo el conocimiento institucional, y llegar a la conclusión de que la idea no es sin mérito. La empresa confía en sus capacidades, y una sugerencia de modernización de su parte puede tener un peso considerable.

Divulgación completa: he sido el tipo senior del que te quejas, en el pasado. He sido, no por elección sino por necesidad, el principal arquitecto y desarrollador de un marco sorprendentemente similar al que estás describiendo.

Déjame decirte que estuve al tanto de todos los problemas técnicos y organizativos durante todo el tiempo . Fue un proceso incremental; nunca hubo ese único punto en el tiempo en el que uno podría haber tomado una sola decisión para detener esto. Casi todos los pasos parecían ser una buena idea en ese momento.

Hay un modo de pensar y algunos otros aspectos (p. ej., la presión del tiempo, la presión percibida , la cultura del equipo, etc.) que llevan a soluciones como esta. No te dice nada sobre la inteligencia, el carácter o cualquier agenda oculta de tu desarrollador.

Acabé con el lío con estas medidas, que literalmente tomaron años:

• Elija un lenguaje de programación completamente nuevo y un marco web más un ecosistema de módulos para reemplazar los lenguajes antiguos y nuestro marco personalizado que teníamos hasta ese momento.
• Evaluar y aprender todo al respecto en mi tiempo libre.
• Implemente un pequeño proyecto de cliente totalmente pagado como prueba de concepto con esa tecnología, asegurándose de usar solo enfoques que sean realmente estándar, formas generalmente aceptadas en ese ecosistema, para asegurarse de que las personas nuevas (que tienen conocimiento previo del idioma) , pero no nuestro dominio) tienen un buen comienzo.
• Encuentre formas de ejecutar la nueva solución aparte de la antigua, sin volver a caer en la trampa del middleware (es decir, acoplada libremente a través de microservicios o indirectamente a través del navegador del cliente).
• Lenta y laboriosamente convenza al equipo muy conservador de que es una buena idea [tm] no hacer nuevos proyectos/características con el antiguo marco, sino dar el paso hacia el nuevo. Esto fue muy agotador emocionalmente.
• Reorientar mi propio rol en la empresa, eventualmente dejar ese equipo y construir uno nuevo con un ángulo diferente, para cortar todos los lazos con el pasado (técnico) (parte del problema era que yo era un solucionador de problemas en ese antiguo equipo, y tuvo que obligarlos a valerse por sí mismos al marcharse).

Fue un viaje divertido y, en retrospectiva, muy exitoso. El equipo ahora está en camino de dejar atrás esa era. Pero el enfoque tampoco era trivial. Tal vez te dé algunas ideas, y me atrevo a decir que necesitarás el apoyo incondicional de tu desarrollador sénior o lo quitarás de esa posición (de cualquier manera que esté disponible para ti). Siéntese y tenga una larga conversación con él, si está en posición de hacerlo, el tipo de conversación "dónde queremos estar en 5 años"...

Una nota, que no se puede enfatizar lo suficiente: el sistema existente puede ser excelente (en realidad, probablemente lo fue, para poder sobrevivir tanto tiempo), pero habrá problemas organizativos en torno al enfoque. Hay un gran problema con la documentación, la distribución general de conocimientos, el factor camión y tener una fase de aprendizaje muy larga para los nuevos colegas. Además, muchos, especialmente los desarrolladores más jóvenes, no tienen mucho interés en invertir mucho aprendizaje en un contexto de aplicación muy específico que no les ayudará en absoluto con proyectos futuros. Razones como esta fueron (en mi caso) las que llevaron al cambio descrito, y hablar abiertamente sobre ellas quita el aguijón personal del problema.

Lectura adicional: según los comentarios, parece que no soy yo quien inventó este proceso. :-) Consulte el patrón StranglerApplication para obtener más información sobre el tema.

Parece que ese desarrollador acaparó un mercado. Buena herramienta de negociación para las negociaciones salariales de revisión de fin de año.

En mi humilde opinión, la lógica comercial no pertenece al traductor. Puede sugerir una división de ese traductor en capas, separando una lógica comercial de los métodos de traducción simples.

Prepárate para que ese desarrollador esté en contra;)

Además, la gerencia puede ponerse del lado de él, indicando el esfuerzo/costo adicional que supondría.

Puede ser una batalla larga, y al final podrías ser tú quien haga la separación ;)

¿Cómo puedo convencer a este desarrollador (y al resto de mi equipo, que son bastante pasivos con este tipo de problemas) de que es una mala idea?

No es su tarea "convencer" al desarrollador.

Básicamente, la pregunta principal aquí es sobre su posición:

• si solo es un colega del mismo nivel o inferior, puede señalar los riesgos a la gerencia. Mientras hace eso, concéntrese en los problemas que pueden surgir del sistema actual. Entonces es su decisión y no tu problema;
• si usted es el jefe , póngase de acuerdo con otros gerentes sobre la necesidad de cambiar el sistema de programación y luego comunique la decisión a los programadores. La decisión debe estar justificada y comunicada correctamente (google "gestión del cambio) y debe organizarse una transición, pero luego debe esperar que sus subordinados se adapten a ella. Puede ofrecer algunos compromisos al programador senior para que se quede con la empresa, por ejemplo, un aumento de sueldo, más días libres y algo de satisfacción de su ego.

Cuando se trabaja para una empresa, es importante desarrollar también la capacidad de despegarse y no preocuparse. ¡En un sentido positivo! Si está tratando de cambiar algo que nadie más quiere cambiar, terminará odiado por los colegas y la gerencia.

Así que concéntrate en cuál es tu tarea. Señale e informe, pero deje que las tomen las personas que de hecho son responsables de tomar decisiones. No importa si tienes razón, conozco a muchas personas, incluido yo mismo, que terminaron despedidas a pesar de tener razón, o por tener razón.

Editar: no renuncies a tu trabajo; tuve una idea equivocada

Wow, al leer originalmente la publicación, la solución técnica sonaba como una capa de traducción que realizaba tareas no relacionadas innecesariamente. Sonaba muy contrario al "principio de responsabilidad única" / filosofía UNIX, no muy cohesivo o bien estructurado.

Creo que el detalle clave que me perdí fue que se trata de un sistema back-end arcaico que ejecuta la lógica comercial central, y creo que está implícito que el negocio está atascado por alguna razón comprensible. Gracias a los comentarios y votos negativos por empujarme a reconocer eso.

Dado que es antiguo, la empresa probablemente no quiera tocarlo. O bien, es posible que la lógica comercial implementada en la capa de traducción no tenga ninguna relación con el propósito de este back-end central.

Otros comentarios tienen razón; la documentacion esta en orden

La decisión de escribir una capa de traducción suena razonable ahora que siento que tengo una imagen más precisa de la realidad en mi cabeza.

Lo que está describiendo no suena tanto como un nuevo lenguaje de programación como quizás un nuevo marco, escrito específicamente para este caso de uso. Suena como ingeniería bastante estándar en lo que ahora entiendo que es el escenario.

Debe familiarizarse con el código, y usted y sus compañeros necesitan capacitación y documentación para comprender el sistema. Sería eficiente escribir documentación sobre las cosas a medida que las aprende.