Haga estas preguntas sobre su plomo.
- ¿Están acostumbrados a trabajar solos o con un equipo muy pequeño?
- ¿Se han codificado principalmente en esta tienda?
- ¿Están acostumbrados a tomar las decisiones?
- ¿Están acostumbrados a "simplemente hacerlo"?
- ¿Escribieron la mayor parte del código?
Si las respuestas son "sí", entonces voy a pintar una imagen de un tipo particular de programador principal. Si coincide con lo que has experimentado, tal vez te ayude a entrar en su cabeza. Si no, ignora esta respuesta .
Este es alguien que ha estado allí desde el primer día, ha pasado años en el mismo trabajo trabajando en la misma base de código, está acostumbrado a salirse con la suya y no tiene mucha experiencia con otras formas.
No consideran a otras personas cuando escriben código, ya que todo tiene sentido para ellos. Por supuesto que sí, lo escribieron o han pasado años entendiéndolo.
Consideran que el estilo de codificación es una preferencia personal, no una herramienta para reducir el mantenimiento y los errores. Cuando discutan sobre el estilo de codificación, tendrán dificultades para escuchar sus argumentos porque probablemente nunca hayan pensado mucho sobre por qué hacen las cosas a su manera. Lo que oirán es "Quiero hacerlo a mi manera" o "Quiero hacerlo a la nueva, elegante y moderna moda".
Están establecidos en sus caminos. Debido a que lo han estado haciendo de la misma manera durante tanto tiempo, todas sus herramientas y editores y su cerebro están microconfigurados según su estilo. Cualquier desviación de este estilo entrará en conflicto con esta forma de trabajo cuidadosamente arreglada, pero muy frágil. Los intentos de cambio generarán quejas sobre su editor, herramientas, la forma en que les gusta trabajar o si es "difícil de leer". Rechazan el cambio porque se han enredado tanto en el statu quo que no pueden cambiar.
Este es alguien que nunca ha aprendido correctamente la ingeniería de software y la arquitectura de software. Simplemente golpean juntos lo que funciona.
Tienes un problema de personas, no tecnológico.
Tendrá que volver a capacitar a su líder o tendrá que renunciar.
Ir a la gerencia es el último recurso . Tanto por las razones que señaló @JaredSmith como porque perderás. Este tipo ha pasado años ganando dinero para ellos. Él escribió su compañía. Él se apagó en numerosos incendios. Para ti es un chef vaquero haciendo espagueti. Para ellos es un héroe que construyó y salvó a la compañía.
Para volver a entrenar tendrás que ...
- Gana su confianza.
- Averigua cómo piensa.
- Abordar sus temores sobre el cambio.
- Hacer el cambio más fácil.
- Muestre cómo esto es mejor para él .
Toma en serio su estilo y métete en su cabeza. Pregúntale al respecto. ¿Por qué hace las cosas como lo hace? ¿Qué ve él cuando lo lee? ¿Cómo interactúa con sus herramientas? ¿Cómo se mueve a través del código? Conocer todas estas cosas le permitirá comprender y abordar sus objeciones.
Encuentra la raíz objetiva de sus objeciones subjetivas, hazlas procesables. "Es difícil de leer" es subjetivo y no le brinda información. No puedes hacer nada al respecto. "Soy daltónico y el resaltado de sintaxis no funciona" es objetivo, le brinda información y puede hacer algo al respecto. Recomendaría un libro llamado Getting To Yes para obtener más información al respecto.
Una vez que llegue al problema raíz, el problema real que está experimentando, vea si puede solucionarlo o mitigarlo. Entonces no es un problema. Probablemente todavía tendrán problemas emocionales con el cambio, pero al menos ya no pueden argumentar que es un problema real.
Hazlo un poco a la vez. Es alguien que lo ha estado haciendo de la misma manera durante años. Está acostumbrado a ver ciertos patrones en el código y a usarlos para comprenderlo. Cambiar de repente todos esos patrones será confuso. Tan frustrante como será ponerlos al día lentamente con buenas prácticas conocidas, tienes que guiarlo a través de él.
Aboga por un estilo comunitario estándar. Esto elimina el argumento de que se trata de preferencias personales y ejerce presión sobre ellos para justificar por qué su estilo diferente es mucho mejor. Si planea contratar personal, facilita la integración de nuevos empleados.
Abogar por el estilo de código automatizado. Haga que siguiendo el estilo correcto presione un botón. Use una herramienta que comience con un estilo estándar, le permita configurarla a su gusto y pueda cambiar el estilo del código con solo presionar un botón. Hacer que el estilo sea lo más fácil posible elimina muchos argumentos sobre lo difícil que será seguirlo. Pueden codificar como quieran, y cuando terminan, presionan un botón y sigue un estilo que otros pueden leer.
Dado que esta persona no tiene la mentalidad de pensar en los demás, tendrá que mostrar cómo estos cambios los benefician. Puede ser tan simple como "dado que este es el estándar ahora, no tendrás que volver a luchar con la próxima persona que contrates". O puede ser "si tenemos pruebas, puede ser más agresivo al cambiar el código y preocuparse menos por cambiar las cosas". O "si hay buenos documentos, la gente no tendrá que molestarte con preguntas sobre cómo funciona el código". Para que esto sea efectivo, tendrá que saber lo que quieren: a algunas personas les gusta que las molesten, les hace sentir importantes.
Es un largo, largo camino. Tendrá que decidir si tiene la paciencia para administrar y volver a capacitar a su jefe. Piense en usted más como su maestro que como su subordinado frustrado, y podría sentirse mejor al respecto.