Introducir nuevos temas a los compañeros de trabajo.

He estado tratando de presentar temas como pruebas unitarias, inyección de dependencia, inversión de control, etc. a compañeros de trabajo. He dado mini conferencias, demostraciones, y he sugerido estos temas durante el almuerzo y aprende. La recepción en general ha sido positiva y la gente ve valor en tales temas.

Aunque parecen atraídos por estos temas, la adopción ha sido muy baja. Cuando les hablo al respecto, la respuesta generalmente es similar a:

Lo intentaré la próxima vez. Solo quiero sacar este proyecto por la puerta.

Tengo la sensación de que es porque la mayoría de lo que han visto son solo demostraciones de conferencias y no tienen ninguna experiencia práctica. ¿Qué puedo hacer para ayudar a empujarlos? No quiero "obligarlos" a escribir código si no lo desean, porque puede parecer "tarea" y puede dejarlos con una mala impresión.

Nuestros proyectos generalmente no dejan tiempo para la experimentación, por lo que las personas tienden a rehuir las nuevas tecnologías. Esto no deja espacio para que los desarrolladores intenten incorporar cosas nuevas durante la fase de desarrollo.

¿Hay algún ejercicio divertido o interesante (solo o en equipo) que les permita tener más experiencia práctica con estos temas? Espero encontrar algo que genere suficiente interés para que estén dispuestos a programar una hora de su día para trabajar en algo ordenado, o un interés suficiente para que investiguen a su propio ritmo.

Para "probar" y, por lo tanto, realmente implantar una idea en la cabeza de alguien, la teoría (hablar) nunca es suficiente.

Debe usar esas prácticas en su propio código y hacer que "descubran" que resolvió los problemas de una manera agradable.

Eso implica que sus prácticas deben ser efectivas y que debe ser obvio.

De esa manera, leer su código los inspirará, ya que "lo verán en acción".

No asuma que solo contar cómo funciona será suficiente.

Hablando por experiencia, si no están dispuestos a aplicar lo que intentas enseñarles, significa que no les importa. Probablemente se esté perdiendo el tiempo tratando de introducir los temas a ellos, porque si entendían los beneficios reales de esos temas que les quieren aplicarlas, no dar excusas de por qué no pueden hacerlo.

Es como tratar de introducir algo mejor que lo que se está utilizando actualmente y obtener miradas en blanco o respuestas inmediatas por qué no es posible hacerlo; es indicativo de que la otra persona realmente no lo ve como un beneficio (porque si fueran capaces de ver el beneficio, no estarían dando una excusa).

Triste pero cierto. Tal vez su situación es diferente, pero me he encontrado con esto un par de veces en el pasado y al final fue dolorosamente obvio que nadie más que yo estaba interesado en esos temas; Finalmente tomé la decisión de irme e intentar encontrar compañeros de trabajo que se preocuparan; el tipo de personas que no necesitan que yo les presente los temas (porque ya los conocen / usan) o que saltan a aceptarlos, en lugar de decir cómo no pueden hacerlo.

He visto caer en desgracia muchas de las "mejores prácticas" y nunca más volver a acostumbrarme. Hay muchos tipos de proyectos y tales técnicas no son adecuadas para todos los proyectos. Asegúrate de que las cosas que vendes realmente te ayuden.

Si comienzas a hacerlo y la gente puede ver que estás siendo más productivo o que estás produciendo un código de mejor calidad, tendrán otro aspecto más adelante. Sin embargo, piense detenidamente, ¿toda la sobrecarga adicional realmente ayudará a su proyecto? No todas las aplicaciones lo necesitan.

Si puede motivar a sus colegas para que participen, podría organizar Coding Dojos . Estos son desafíos de programación en los que los participantes se centran deliberadamente en mejorar la práctica. Quizás participar en un dojo basado en pruebas, por ejemplo, lleve a sus colegas a ver los beneficios en TDD.

Alternativamente, a veces estas cosas necesitan ser impuestas por la cultura. Me parece que la cultura de su empresa no es necesitarlos.

Si se convierten en un requisito de cierre del proyecto (probablemente una decisión de gestión), verá que se aglutinan, pero al menos entonces alguna aplicación de dichas herramientas y la cultura comenzarán a cambiar.

La mejor práctica es en el código de producción real. Los katas son una buena introducción, pero en mi experiencia, no tienen el mismo "Eureka!" Momentos como verlo hecho de verdad .

Sin embargo, usted señaló que las líneas de tiempo "no permiten la experimentación". Es una solución simple realmente. Ya estás haciendo estas cosas que estás tratando de enseñar, así que deja una invitación abierta para emparejarte mientras implementas una nueva característica increíble X. Deja que se sienten en el teclado y escriban mientras estás " conducción del asiento trasero ". Esto les permitirá desarrollar algo de memoria muscular y confianza.

Buena suerte en tus esfuerzos.