En la pregunta Manejo de mi anticuado compañero de trabajo , varias personas discutieron estrategias para tratar con compañeros de trabajo que no están dispuestos a integrar su flujo de trabajo con el del equipo.
Me gustaría, si es posible, aprender algunas estrategias para "enseñar" a un compañero de trabajo que simplemente ignora las técnicas y herramientas modernas, y posiblemente un poco apático.
Comencé a trabajar con un programador que hasta hace poco había estado trabajando en un relativo aislamiento, en una parte diferente de la empresa. Tiene un amplio conocimiento del dominio y, lo más importante, ha demostrado buenas habilidades para resolver problemas , algo que muchos candidatos parecen carecer.
Sin embargo, el código real (C #) que he visto es un retroceso a los días VB6. Estructura de procedimiento, notación húngara, variables globales (abuso de static), sin interfaces, sin pruebas, no uso de genéricos, lanzamiento System.Exception... se entiende la idea.
Este programador es bastante mayor que yo y, al menos por primera impresión, no busca activamente un cambio positivo. No voy a decir que es resistente al cambio, porque creo que es en gran medida una cuestión de cómo se aborda el tema , y quiero estar preparado.
Los programadores tienden a ser personas obstinadas, y es muy probable que entrar con las armas encendidas e instituir revisiones de códigos de desgarre y políticas estrictamente aplicadas no produzca el resultado final que quiero. Si se tratara de un nuevo empleado, un programador junior, no lo pensaría dos veces antes de tomar una postura de "mentor", pero soy extremadamente cauteloso de tratar a un empleado experimentado como un novato despistado (lo cual no es así, simplemente no lo ha hecho mantuvo el ritmo con ciertos avances en el campo).
¿Cómo podría aumentar el estándar de calidad de código de este desarrollador a la manera de Dale Carnegie, a través de persuasión suave e incentivos no materiales? ¿Cuál sería la mejor estrategia para efectuar cambios sutiles y graduales, sin crear una situación de confrontación?
¿Han estado otras personas, especialmente los desarrolladores principales, antes en este tipo de situación? ¿Qué estrategias fueron exitosas para estimular el interés y crear una dinámica de grupo positiva? ¿Qué estrategias no tuvieron éxito y sería mejor evitarlas?
Aclaraciones:
Realmente siento que varias personas están respondiendo en base a sentimientos personales sin leer realmente todos los detalles de la pregunta. Tenga en cuenta lo siguiente, que debería haber estado implícito, pero ahora estoy haciendo explícito:
Este compañero de trabajo es solo mi "mayor" en virtud de la edad. Nunca dije que su título, esfera de influencia o años en la organización superaran los míos, y de hecho, ninguna de esas cosas es cierta. Es un programador de LOB que ha sido absorbido por la tienda principal de desarrollo. Eso es.
No soy un nuevo empleado, programador junior u otro idiota ingenuo con grandes planes para transformar la empresa de la noche a la mañana. Básicamente estoy a cargo del proceso de software, pero como muchos de los que han trabajado como "leads" sabrán, las responsabilidades no siempre se correlacionan con precisión con el organigrama.
Estoy no pedir a la gente cómo conseguir mi manera, contra viento y agua . Podría hacerlo si quisiera, con el resultado neto de que esta persona se resentiría y / o renunciaría. Intente comprender que estoy buscando un método social y cooperativo para impulsar el cambio.
La mención de "... variables globales ... sin pruebas ... arrojando
System.Exception" tenía la intención de demostrar que los problemas no son solo superficiales o estéticos . Las prácticas que pueden funcionar para aplicaciones CRUD relativamente pequeñas no necesariamente funcionan para aplicaciones de grandes empresas, y de hecho, ninguno de los códigos hasta ahora ha pasado las pruebas de integración.
Por favor, trate de tomar la pregunta al pie de la letra, acepte que realmente sé de lo que estoy hablando y responda la pregunta que realmente hice o continúe.
PD: Mi más sincero agradecimiento a aquellos que ofrecieron consejos constructivos en lugar de discutir con la premisa. Voy a dejar esto abierto por un tiempo más, ya que espero escuchar más sobre las experiencias del mundo real.