Me gustaría responder a su pregunta desde el otro lado de la valla.

Empecemos con esto:

... todavía ofrece resultados pero es una manera en la que ninguno de los otros desarrolladores puede contribuir o requiere una gran inversión en aprendizaje.

¿Por qué trabajar en su código requiere una gran inversión en aprendizaje? ¿Puede ser que la "pelusa" que desea que elimine sea en realidad las cosas que está tratando de decirle para que pueda trabajar con su código? Sea honesto, ¿el resto del equipo ha dedicado mucho tiempo y esfuerzo a aprender los conceptos detrás de su código?

Independientemente de si lo ha hecho o no, debe darse cuenta de eso Si tiene un buen conocimiento de cómo escribir un buen código, no es posible escribir código malo que los compañeros de equipo menos capaces puedan entender. Incluso si lo intenta, no podrá adivinar qué prácticas de mierda entenderán / con las que estarán de acuerdo y qué prácticas de mierda también pensarán que son malas. Digo esto por experiencia.

Las posibles soluciones son

• No tener un compañero de equipo más capaz
• El compañero de equipo más capaz tiene la propiedad exclusiva del código
• El resto del equipo necesita mejorar sus habilidades

... él vino de un entorno de administración de sistemas más estructurado y la mayoría de los desarrolladores vienen de donde las cosas deben hacerse rápido en lugar de lento y correcto.

Este es un malentendido de su parte. A menos que el proyecto dure solo unos días (como 2), un buen código siempre prevalecerá sobre el código incorrecto en cuanto a velocidad de desarrollo. Sospecho que su equipo simplemente no le ha dejado tener la cabeza lo suficiente cuando esto es evidente, o no lo está notando intencionalmente (tuve este problema con mi jefe).

MPO es que, dado que él tiene más experiencia que tú, debes darle la vuelta y asegurarte de que estás escuchando completamente lo que tiene que decir. Sé que muchas veces hago recomendaciones basadas en el instinto de muchos años de desarrollo y no siempre puedo articular por qué un enfoque "se siente" como lo correcto y el otro "se siente" como un completo error. Haga preguntas indagatorias y articule esas cosas.

Es posible que esté descartando las opiniones de los demás porque su experiencia les dice que están equivocadas (pero es demasiado educado para decirles o simplemente no ve el punto con personas que no escuchan de todos modos). También es posible que los demás miembros de su equipo no estén articulando sus posiciones propias particularmente bien. Si tiene que elegir entre su propio puesto, que él entiende, y un puesto que no ofrece ventajas claras para él , ¿adivinen qué hará? Sé que estoy más que feliz de doblegarme o comprometerme cuando alguien me da un argumento claro que me muestra dónde estoy equivocado o podría hacerlo mejor, pero "no es así como siempre lo hemos hecho" no llega muy lejos conmigo.

"enviar código a repositorios de código compartido en los que él es el mantenedor"

Debería incorporar de inmediato la propiedad colectiva del código, es una práctica de Extreme Programming, consulte wikipedia. Tener a alguien "dueño" del código nunca es una buena idea, el conocimiento y el sentido de responsabilidad se deben poner en un equipo, no en una persona.

"comienza una perorata sobre la validez de las estimaciones, por qué no pueden funcionar, etc. durante los próximos 10 minutos".

Tiene razón, ya sabes. Las estimaciones son extremadamente difíciles, pero como son necesarias, deberías mirar las estimaciones colectivas jugando al póquer de planificación o algo similar. De esa manera, un grupo trabajará en conjunto para proporcionar una estimación. Suelen ser más precisos y también comparten conocimientos sobre la nueva función.

He pasado por situaciones similares en las que tuve que lidiar con un predicador de código. Esto es lo que sugeriría:

• Hable con su gerente sobre los posibles retrasos causados ​​por la actitud.
• No haga que parezca una queja . En cambio, dígalo de una manera que el gerente entienda que la actitud está causando dificultades a los demás.
• Dado que el colega es un senior en términos de experiencia en programación, no veo cómo puede hablar directamente con el interesado. Por lo tanto, las aprehensiones deben dirigirse a través de los gerentes.
• Además, a veces, en realidad, podría estar agregando mucho valor al equipo al proporcionar aportes, escuche. No descartes todo.

Recuerde que no es su trabajo corregirlo. Solo puedes actuar como mensajero con respecto a los posibles conflictos en el equipo debido al comportamiento.