¿Cómo podemos hacer que las mejores prácticas de desarrollo de software sean más interesantes para las personas sin experiencia en software?

Donde trabajo hay algunos desarrolladores de software experimentados con experiencia en software, pero la mayoría de los desarrolladores son físicos o químicos con excelente conocimiento de dominio pero experiencia limitada cuando se trata de desarrollar software de alta calidad y mantenible. Para abordar esto, hemos comenzado a organizar charlas y talleres regulares.

¿Qué temas cree que deberíamos discutir para ayudar a que estas personas sean desarrolladores de software más efectivos?

En particular, estamos luchando por ganar entusiasmo por estas conversaciones, ya que muchos desarrolladores no ven el software como un tema interesante. ¿Cómo podríamos hacer que esto sea más interesante para las personas sin experiencia en software?

Gracias

Creo que va a ser difícil, así que prepárate para una lucha, pero no imposible. Al final del día, la programación (especialmente la codificación no vaquera-hack'n'slash) no va a ser súper emocionante para todos. Esto es especialmente cierto para las personas que ya trabajan en un área que es intelectualmente desafiante y gratificante por derecho propio.

En primer lugar, haga que las charlas y los talleres sean divertidos: comida gratis (¡asegúrese de que sea buena comida!) Y golosinas similares son un buen lugar para comenzar. Trate de inyectar un poco de humor también y, al menos inicialmente, manténgalos lo más breves e informales posible.

En segundo lugar, asegúrese de que las charlas y talleres sean relevantes. Trate de no hacerlos demasiado abstractos (incluso si los conceptos que se están cubriendo son abstractos) y si es posible, asegúrese de que puedan probar lo que se ha cubierto. Incluso mejor verifique lo que han hecho entre sesiones y proporcione comentarios positivos. Si no son relevantes y no están aplicando lo que ha discutido, los verán (correctamente) como una pérdida de tiempo.

Finalmente, intente introducir algunos estándares básicos de codificación, preferiblemente aquellos que no sean demasiado intrusivos en su funcionamiento actual. Si estás en el mundo .net, Resharper es bueno para empezar, ya que te advertirá sobre cosas como las convenciones de nombres. Puede ir más allá con StyleCop (que se puede integrar en Resharper), pero asegúrese de personalizar primero el conjunto de reglas. Si no está en .net, estoy seguro de que existirán herramientas similares en otros lugares. No es mucho, pero es un comienzo.

No espere resultados instantáneos (excepto tal vez cualquier estándar de codificación aplicado automáticamente): he escuchado 6, 9 y 12 meses en el tiempo para introducir las mejores prácticas.

Solo lo he revisado hasta ahora, pero parece que hay un buen consejo relevante en el próximo libro Driving Technical Change .

Si estos químicos y físicos no son principalmente desarrolladores profesionales, y no están destinados a serlo, sugeriría pensar de manera diferente en el problema.

Los desarrolladores "reales" deben proporcionar entornos fáciles para que se desarrollen. Debe proporcionar asesoramiento y debe proporcionar una revisión por pares de su código con fuertes incentivos para que el código sea lo suficientemente bueno como para pasarlo en primer lugar.

En otras palabras, no los trate como iguales, sino que brinde todo lo que pueda para que se destaquen en lo que realmente hacen: su fuerza.

Trabajo con ingenieros de redes muy inteligentes que no son desarrolladores y no quieren serlo. Puedo entender eso porque no quiero ser ingeniero de redes.

Lo que hemos encontrado que funciona bien es que el ingeniero y yo hagamos la programación en equipo. Estamos en sitios separados, así que nos ponemos al teléfono, abrimos una sesión para compartir pantalla, generalmente con el screencomando, y sacamos el código.

Lo hemos hecho muchas veces y sentimos que funcionó muy bien. Entiendo cómo hacen mejor sus cosas, y el ingeniero está aprendiendo cómo escribimos código mantenible y probado.

¿Qué papel tienen en la empresa? Si necesita desarrolladores, déjelos ir si no son buenos desarrolladores y no están interesados ​​en convertirse en buenos desarrolladores. Si se supone que son físicos y químicos, puede organizar talleres, pero no espere que mantengan un alto nivel de interés. Si se supone que son ambos, aumente las expectativas y asegúrese de pagarles lo suficiente como para justificar que asuman el rol de desarrollador de software mientras mantienen conocimientos y habilidades de dominio complejos.

A menos que parte del rol definido de alguien sea ser desarrollador, probablemente nunca estarán tan interesados ​​en desarrollar software de alta calidad. El hecho de que alguien esté creando scripts y hacks rápidos no significa necesariamente que realmente quieran ser un desarrollador de software, es solo un medio para un fin, como un contador que descubre fórmulas complejas de Excel. Si necesita software mantenible de alta calidad, los desarrolladores de software deberían crearlo.

muéstrales los beneficios para ellos . de lo contrario, ¿por qué deberían importarles?