¿Inspirar a un compañero de trabajo a adoptar mejores prácticas de codificación?

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.

El punto de partida es conocer a tu audiencia . Parece que ya entiendes esto porque sabes la diferencia entre ser mentor de un compañero de trabajo junior e influir en un compañero de trabajo senior.

Aún necesita descubrir qué motivará a este individuo en particular. Lo que funciona en un viejo geezer (como yo), podría no funcionar para su viejo geezer.

Si le gusta guiar / enseñar a otros, puede abordar un problema haciendo preguntas como "¿por qué lo hace de esta manera?" Eso puede iniciar un diálogo donde puede pedirle que evalúe enfoques más nuevos y que dé su opinión.

Si eso no funciona, podría señalar errores que pueden evitarse utilizando las prácticas o estilos que le gustaría que adoptara. Esto requiere mucho más trabajo porque tiene que encontrar los errores y mostrar cómo ayudarían los comportamientos que desea fomentar.

Si parece dispuesto a ayudar a otros, puede apelar a su deseo de ayudar a los novatos . Explique que "los niños de hoy" no están acostumbrados a ver su estilo de codificación y es más probable que rompan su código debido a eso.

A veces es posible que tengas que enfrentarte a él y forzar el problema. Debes elegir estas batallas con cuidado. Asegúrese de comenzar con un tema en el que sepa que puede demostrarle que tiene una mejor manera.

Creo que tienes la actitud correcta. Solo asegúrate de decir todas las cosas buenas que ya has dicho: excelentes habilidades para resolver problemas, comprensión del negocio, etc., y solo pídele un poco de su tiempo para mostrarle los estándares actuales del grupo usar y darle la oportunidad de hacer algunas preguntas sobre ellos.

Cuando se reúnan, tráiganle un café o algo, y hágale saber que trabajar de acuerdo con los estándares lo beneficiará al hacer que sea más fácil para él respaldar su código existente y también facilitar que alguien pueda ayudarlo si él queda cubierto en el trabajo (una gran ventaja para alguien que ha estado trabajando de forma aislada), etc.

Asegúrese de que esté comprometido y obtenga buenas explicaciones de por qué hace las cosas que hace y no se concentre en por qué no debe hacer las cosas que estaba haciendo, traiga a otras personas si es necesario y haga que se lo expliquen. Póngase a disposición después si tiene alguna pregunta y seguimiento con algunos lugares a los que puede referirse para obtener ejemplos de sus estándares.

Si no está interesado después de eso, puede referirse a la primera pregunta que vinculó.

Realmente es el trabajo de su gerente

1. Tenga en cuenta que la empresa debe tener un estándar de codificación. Toda empresa algo profesional tiene esto, sin importar el tamaño de la empresa.
2. Haga que todos se sienten juntos y comiencen a elaborar un estándar. De esa manera, todos pueden expresar su opinión, y entonces estarán más motivados para seguir el estándar.

Si su gerente no se da cuenta de esto por su cuenta, no está calificado para su trabajo. Y si es así, debe darles algunos empujones por encima de los dos anteriores. Las ventajas de tener un estándar de codificación son muchas, realmente no hay argumentos en contra de tener uno. (Si algunos programadores sienten que son "artistas" y no deberían estar restringidos por los límites de la profesionalidad, deberían conseguir un trabajo haciendo bellas artes).

El estándar de codificación en sí mismo debe centrarse ante todo en prohibir la práctica peligrosa y las funciones peligrosas de la biblioteca. Trabaje hacia un subconjunto más seguro y puro del idioma que está utilizando. Mantenga el estándar de codificación libre de "estilo de codificación", porque el estilo de codificación es mucho más difícil de acordar y no es tan importante. Es bastante clásico que una empresa decida hacer un estándar de codificación e inmediatamente se quede estancado en una acalorada discusión sin sentido sobre dónde colocar las llaves {}.

Como referencia, consulte cómo se escriben los estándares MISRA-C / C ++ y CERT C / C ++ / Java.

En primer lugar, debe aclarar POR QUÉ desea cambiar la forma de trabajar de esta persona. Si es solo por razones estéticas, creo que debería reconsiderarlo, porque esta persona ha demostrado que su forma de trabajar realmente funciona.

Sin embargo, si hay una razón técnica para ello, entonces debería considerar acercarse a dicha persona con algo como:

Tengo una sugerencia sobre cómo puede ahorrarle tedioso tiempo y dinero a la empresa. ¿Estás interesado?

Tenga en cuenta que esto debería ser frutas bajas porque probablemente requerirán cambiar los hábitos existentes que siempre requieren un esfuerzo adicional.

Incluso si tiene miles de millones de sugerencias, simplemente elija una o dos y demuestre que será un cambio a mejor.

O esto funcionará, y se le preguntará si tiene más sugerencias, o no, y el daño se limita a una o dos sugerencias.

Tenga en cuenta que es muy importante que se convierta en un éxito y que lo haga rápidamente.

También debes tener cuidado. Puede haber muy buenas razones para hacer las cosas de la manera en que se hacen, pero que eres demasiado nuevo para haber visto por qué. Por lo tanto, sea respetuoso con su anciano y pregunte antes de asumir que su sugerencia es mejor. Puedes aprender una o dos cosas.

Me gustaría desalentarlo severamente para que no se enfrente a él, ya que esto podría empeorar la situación muy rápidamente. Me doy cuenta de que se mencionó como un último tipo de medida, pero en mi experiencia, en este punto, el desarrollador funcionalmente ha dejado de participar.

Forzar el problema podría convertir al individuo en un enemigo donde está luchando con cada una de tus acciones. Eso realmente tendría un impacto negativo en el equipo y no termina hasta que alguien renuncie o sea despedido.

Si esta persona realmente tiene el conocimiento de dominio que necesita / desea, haga que documente ese conocimiento.

Comenzando por decírselo suavemente: no sé cuán experimentado y cuán versado estás en dar retroalimentación. Bien podría saber, emplear o incluso haber rechazado lo siguiente, pero aquí va de todos modos. Hay algunas pautas para dar retroalimentación cuando desea cambiar el comportamiento de alguien. La estructura de conversación que he pensado y que todavía trato de emplear en situaciones en las que quiero dar retroalimentación (porque funcionan) son las siguientes:

1. Describe el comportamiento que ves. Esto tiene que ser un comportamiento concreto. Ejemplo: "Veo que está utilizando muchas variables estáticas en su código"
2. Describa cómo eso lo impacta a usted / a su equipo. Ejemplo: "Me resulta difícil mantener dicho código"
3. Ofrecer una solución razonable . (las posibles soluciones se mencionan en otras respuestas, y me ocuparé de algunas más adelante en esta respuesta).
4. Dale la oportunidad de discutir la solución. Pregúntele qué piensa sobre la solución. Tome su respuesta al pie de la letra. Le has dado tu opinión, y él es libre de aceptarla o no. *

Se puede encontrar un recurso rápido sobre comentarios, por ejemplo, en http://managementhelp.org/communicationsskills/feedback.htm (aunque hay una gran cantidad de este tipo de cosas en la web)

Ahora, en la parte de la solución, por lo que estoy leyendo en su respuesta, deduzco que es bastante inteligente y tiene la mentalidad correcta, pero solo está detrás de las buenas prácticas modernas. Esos requieren tiempo y esfuerzo para dominar, aparte del aprendizaje real sobre ellos en primer lugar, por lo que tendrá que brindarle la oportunidad de hacerlo. Eso probablemente significa reunir recursos de aprendizaje (web, revistas, libros, lo que sea) como punto de partida, y proporcionarle tiempo libre para estudiarlos. Me imagino dándole todos los viernes por la tarde para ampliar sus horizontes sobre el estilo de programación, donde puede hacer lo que crea para alcanzar esos objetivos. Las personas quieren heredarse de forma heredada. Proporcione los materiales y el tiempo, y harán un buen uso de ellos.

Posiblemente lo más importante, no espere cambios de la noche a la mañana. Él ha hecho las cosas a su manera durante mucho tiempo, y probablemente se ha vuelto bastante bueno en eso. Tomará algún tiempo volverse tan bueno en una nueva forma de hacer las cosas, y por un tiempo, probablemente no verá mucho valor en nuevas formas, porque al principio, no hay ninguna. Su viejo estilo probablemente será más efectivo por un tiempo.

* Nota: lo divertido de las conversaciones es que son muy difíciles de modelar. Tienen vida propia, por lo que, aunque se ve bien en el papel, tiende a enturbiarse un poco.

Explique cómo quiere que se hagan las cosas y muéstrele cómo funciona con el diseño y las elecciones arquitectónicas que ha realizado para el proyecto al comienzo del proyecto en el que lo hará trabajar. Siéntese uno a uno (y en privado) y explique los problemas que ha visto en su codificación anterior y por qué son un problema para este proyecto. Pregúntele qué necesita para mejorar, pero deje en claro que no mejorar no es una opción.

Luego use la revisión de código como una herramienta para que ajuste sus métodos de trabajo. Planifique un buen tiempo para el primero y realmente hable sobre por qué prefiere esto sobre eso y permítale explicar su razonamiento. Asegúrese de escucharlo realmente, las personas son más sensibles al cambio cuando sienten que sus preocupaciones han sido atendidas. Espere en su planificación (pero no le diga eso) que tenga que volver a trabajar en la primera tarea y no la acepte hasta que cumpla con los estándares de su equipo. Una vez que sepa lo que esperas y que no lo dejes pasar por el interés del tiempo, probablemente se acercará a tu forma de trabajar. Pero es posible que tenga que usar la revisión de código como una herramienta educativa para varias iteraciones. No tiene que ser desagradable al no aceptar el trabajo hasta que cumpla con sus estándares, pero debe ser firme y constante. Don'

La pregunta de $ 64,000 es si está entregando sus proyectos a tiempo y cumpliendo con los requisitos de funcionalidad. Si es así, lo está haciendo bien. No existe un objetivo correcto o incorrecto en el desarrollo de software. En definitiva se trata de resolver problemas. Y si los problemas se resuelven a satisfacción del cliente / cliente, entonces, por definición , el desarrollo de software se realiza correctamente.

Por supuesto, se convierte en un tema completamente diferente si sus proyectos no se están completando. En ese punto, sus supervisores deben hacer cambios, tal vez con su aporte. Pero solo porque esté violando su sentido personal de la estética del código o la sabiduría convencional de hoy en día no significa que lo que está haciendo está "mal". Usted no es el árbitro de la definición de "buen código". Él podría, después de todo, tener una baja opinión de su código.

Entonces ... a menos que haya realmente un problema con su trabajo (que usted no ha indicado), no haga nada. Parte de ser un desarrollador exitoso es aprender a fusionar su código con los estilos de otros desarrolladores.

Después de todo, podría venir aquí y publicar una pregunta similar sobre cómo tratar con un desarrollador menos experimentado que está más preocupado por mantenerse al día con las modas que por terminar los proyectos. Se trata de perspectiva.

Como desarrollador junior que habla con un desarrollador senior, es demasiado arriesgado que intentes acercarte a él con mejores ideas que las suyas.

La mejor manera de lidiar con esto es tratar de convencer a su jefe de una mejor práctica, y ver si hará un decreto de que todo el código debe seguir estándares específicos y hacerse cumplir a esos estándares a través de revisiones de código de pares.

Una parte considerable de las personas son (incluso si están en un nivel subconsciente) vengativas, egoístas y defensivas, incluso si no son completamente conscientes de sus propios motivos subconscientes, se ofenden si intenta cambiarlos o implica que están equivocados. de todas formas.

La Cadena de Comando es la forma más segura de hacerlo porque TIENE que escuchar a su jefe, y tampoco le tiene que gustar. Deje que el jefe sea el malo, para eso está allí.

Si no puede vender al jefe o si él es el jefe, entonces trate con sus errores, pero lidere con el ejemplo en SU ​​código.

No puedes

No puede inspirar a las personas a hacer cosas de las que no son conscientes en el desarrollo de software. Hablo por experiencia, ya que he tratado de hacer esto a menudo en mi carrera, y cada vez que el resultado final es que mi propio estado disminuye a los ojos de la empresa; Incluso me despidieron o renuncié por la frustración después de que no pasó nada, simplemente por tratar de mejorar la cultura de desarrollo que me rodea a las prácticas modernas.

Si su compañero de trabajo no era ignorante, podría mostrárselo. Sin embargo, dado que lo son, no hay nada que pueda hacer, ya que no son capaces o no se preocupan lo suficiente por el software como artesanía para esforzarse por adoptar mejores prácticas de codificación. Lo más probable es que si lo intentas, lo ignorarán o perderán el tiempo sin comprender realmente, lo que por lo que parece es lo que ya están haciendo ("Desarrollo de prueba y error", es decir, simplemente pirateando el código hasta que se detengan los errores) .