El fundador respondió que están exagerando, y que tiene una confianza absoluta en las habilidades del nuevo líder, basado en su CV y en la entrevista, que es exactamente por lo que le asignó a esta persona el papel de un desarrollador líder en primer lugar.

El jefe ha hablado. No es un gobierno o un partido político. No puedes echar a nadie o liderar una insurrección.

Si no estás dispuesto a lidiar con ello, realmente tienes una opción. Puedes unirte y amenazar con renunciar a menos que algo suceda.

Estoy diciendo que puedes, no debes. Hay una extraordinaria posibilidad de que esto no termine bien. Básicamente intentas ponerte por delante del jefe que ha tomado su decisión y a la gente a cargo no le gusta que los desafíen.

Supongo que lo “correcto” que te digo es que encuentres técnicas para animarlo a ver tu forma de pensar. Pero no voy a hacer eso. Soy un desarrollador senior de 30 años y puedo decirle que me he establecido en gran medida en mis formas fundamentales. No, no soy un ludita como este tipo y sí, acepto sugerencias. Me gusta la nueva tecnología y así sucesivamente. Este tipo está claramente equivocado en muchas cosas. Sin embargo, lo que puedo decir es que cuando estoy decidido a algo y estoy convencido de que estoy tomando la decisión correcta, la mantengo. No me tomo bien las amenazas y la coacción o la manipulación es aún peor.

Mi punto es que está convencido de que es “Jesús programador” (lo cual es una actitud triste y desafortunada) y nunca lo cambiará, no en esta etapa de su carrera. Está convencido de que tiene razón y cree que su experiencia lo respalda. Desafortunadamente, el jefe también lo hace.

Honestamente, probablemente no vale la pena el estrés de usted y su equipo. *Le sugeriría a cada uno de ustedes que empiecen a buscar un nuevo trabajo y se vayan cuando lo hayan encontrado. Cuando una persona se vaya, asegúrense de decirle al jefe por qué. * Eventualmente puede que se haga una idea. Incluso entonces, no hay garantía.

Corre En serio, no sé por qué alguien querría estar allí. Pregúntate, ¿hay algo en lo que nos has dicho que no signifique la perdición final del producto? Estoy seguro de que lo sabes. Cuestiono la inteligencia básica del fundador para el caso. Los desarrolladores suelen ser pésimos administradores de proyectos y programas. Es un conjunto de habilidades separadas y necesitan equilibrarse entre sí. Es como decir “no necesitamos probadores separados, las pruebas de los desarrolladores funcionan muy bien”. Ambas son recetas para el desastre. Buena suerte. Lo digo en serio.

La descripción de la situación por parte de la OP es probablemente unilateral. Está bien.

Soy un desarrollador de envejecimiento (~54 yo) traído a una compañía no para gobernar, sino para proporcionar algo de experiencia. El personal de desarrollo era mucho más hábil, en el balance, que cualquier otro equipo con el que había trabajado anteriormente. Me enseñaron mucho, ¡especialmente sobre la humildad! Pero encontramos lugares donde su magia tecnológica no resolvía los problemas y en algunos casos los ocultaba, empeorándolos en última instancia. Aquí es donde realmente pude contribuir.

Tu protagonista suena severamente autocrático. Suena como si le hubieran dado un mandato del propietario. El dueño está descontento con el personal de desarrollo y ha traído a este tipo “duro y sin tonterías” para mejorar la velocidad de entrega.

Primero, mire a su personal. ¿Tienes debiluchos - desarrolladores que no “ven la Matriz”? Si es así, encuéntreles nuevos puestos dentro de la empresa o déles una buena referencia para un empleador que necesite sus habilidades únicas.

Odia los IDEs

Conozco algunos que sí. Me hace poner los ojos en blanco, pero al final no me importa. Si la gente produce usando vi, entonces está bien. Me encantan mis IDEs.

No refactoriza el código, y no le importa el estilo (que es inconsistente en su propio código)

Bandera roja en la primera parte. ¿Es un copiador? También soy culpable de no preocuparme por el estilo, pero eso es porque utilizo mi IDE para hacer que mi código Python cumpla con PEP8 al instante. Pero él no usa un IDE…

Como nota al margen, el estilo fue previamente comprobado por una construcción nocturna, que comenzó a fallar desde la llegada de la nueva pista.

Rechaza la idea de una construcción nocturna, así como las pruebas automatizadas. Según él, “cualquier desarrollador profesional prueba su código de todos modos a mano, así que no hay razón para perder el tiempo escribiendo pruebas automatizadas”. La construcción nocturna también es una pérdida de tiempo, según él.

Esto también activa una bandera roja, pero por razones diferentes a las que podrías esperar. Antes de que este tipo fuera contratado, ¿cuántas veces le dijeron al dueño que no podía hacer X (dar una demostración, usar el sistema, etc.) porque la construcción nocturna fallaba? ¿Qué pasa si el propietario percibe que el problema es la construcción nocturna? ¿Qué crees que le diría al Plomo que hiciera?

Pero me preocupa la actitud del Plomo; las pruebas automatizadas son increíbles. Como antes, el jefe puede no entender el valor de las pruebas, pero seguramente sabe que el Y% de los cheques de pago del personal de desarrollo las pagan. Cuando llegué a mi actual empresa, la “mafia de la cobertura de pruebas al 100%” se había apoderado del personal de desarrollo y elevó los costos. Una manzana podrida más tarde y el personal de desarrollo ronroneaba de nuevo.

Él piensa que el control de versiones es mayormente inútil…

Esta es una bandera roja del más alto nivel. Está tan equivocado como es posible. Está siendo irresponsable con el dinero del dueño.

Exagera la importancia de la optimización del código.

En su día, la optimización del código podía hacer la diferencia. Ahora las máquinas son tan rápidas que es menos importante. En cambio, ahora tenemos que preocuparnos por el rendimiento de la base de datos y el rendimiento de la red. Pero su hábito de “optimización de código” es difícil de romper, créame. Tengo que hacer que no me preoptimice. Al menos su comportamiento en este caso no es destructivo, excepto por el tiempo que lleva. (¿Tiene números para su “mitad de su tiempo” o es una hipérbole? Si está criticando a su supervisor, no se puede permitir ninguna hipérbole. Debe ser patológicamente objetivo.)

Escribe todo el SQL a mano, y rechaza la idea de un ORM.

¡Culpable de los cargos! No entiendo el miedo de la gente a los SQL. No entiendo el enterrar el SQL, que es simple, bajo capas de ORM que se ofuscan. No puedo ayudarlo aquí :-D Pero por favor, vuelque todo su SQL en un lugar - no lo distribuya todo en su código.

y dos de los cinco desarrolladores nunca usaron SQL antes.

Eso es inaceptable. Estamos en el año 2016. Necesitan capacitarse.

Rechaza los frameworks y bibliotecas de terceros, considerando que es mucho más fácil escribir cosas desde cero.

No podría estar más equivocado. Dudo que su compañía sea tan especial que sus utilidades necesiten ser escritas en casa. Teníamos algunos desarrolladores que abrazaban herramientas de terceros - hasta que hacían algo de una manera que no le gustaba al desarrollador. Era una excusa para tirar la herramienta y escribir la suya propia. Esto sólo aumenta la carga de trabajo del equipo de desarrollo, ralentizándolos aún más. Este código inútil es caro de escribir, probar, depurar y mantener. Gastamos tanto dinero para -cero beneficios. Estos desarrolladores se han ido ahora.

Decidió abandonar todas las librerías y frameworks de JavaScript excepto jQuery, afirmando que cuando empezó a programar en JavaScript hace quince años, no había frameworks, y la vida era mucho más fácil.

Este no está tan claro. La razón es que la vida era mucho más fácil hace 15 años es que la pregunta de negocios era mucho más simple. De ahí es de donde viene el problema. La web se inventó como un sistema de lotes (rellenar un formulario, enviarlo, obtener una respuesta, repetir) y ahora estamos tratando de escribir aplicaciones web que se comportan como aplicaciones de escritorio. Su observación es correcta, las cosas son difíciles ahora. Pero no se da cuenta de por qué. La complejidad de la herramienta es en respuesta a una pregunta de negocios más complicada. Por lo tanto, toma malas decisiones.

Estamos usando AngularJS y parece ser decente. Como todas las herramientas poderosas, puede ser usado para el bien o para el mal.

Él piensa que los dispositivos móviles (incluyendo las tabletas) son sólo una exageración, por lo que no hay razón para perder un tiempo precioso para asegurar la compatibilidad del sitio con esos dispositivos y para hacer un diseño receptivo. El producto es una aplicación web pública que no se espera que se use mucho de los dispositivos móviles.

Se equivoca otra vez. No son exageraciones. Están aquí para quedarse porque son útiles. PERO el negocio no lo necesita. No desarrolles cosas que no necesitas. Es caro.

El diseño de respuesta, sin embargo, podría ser muy interesante tener para esta aplicación,…

¿Es tan interesante que pagaría por el desarrollo personalmente? Si es una buena idea, deberías poder vender la idea al propietario. Si no, no te gastes ni un céntimo en ello.

Pide al equipo que deje de usar internet (especialmente StackOverflow) y que confíe en sus cerebros, la documentación offline (¡ni siquiera sabía que Microsoft todavía vende CDs de MSDN!) y los libros.

Se equivoca. Internet es genial para esto. Si el personal de desarrollo está copiando y pegando desde Stackoverflow sin entender cómo funciona el código, entonces también se equivocan. ¿Hay tiempo para el entrenamiento y la mejora personal en el programa de desarrollo? Es difícil no copiar-pegar robóticamente cuando siempre estás bajo el arma.

Aunque tengo información limitada, hay muchos problemas aquí. Parece que el dueño no ha conseguido el código que está pagando tan rápido como espera. Suena como si hubiera escuchado muchas excusas sobre cosas que no le importan; está concentrado en el resultado. Si estoy en lo cierto, tiene una herida autoinfligida, y la ha reabierto más de una vez. Esta pista es la solución del propietario al problema que el personal de desarrollo ha planteado, y dada su limitada información, es comprensible.

También apostaría que usted está dirigiendo una tienda no agilizada y tiene una pobre definición de los requisitos que cambia a medida que sopla el viento. No hay una capa de aislamiento entre el personal de desarrollo y el propietario. Excepto por este plomo.

Ahora, ¿qué puedes hacer?

1) Entrenar al plomo en el uso de pruebas automatizadas y manejo de códigos. Puede llevar tiempo ganar credibilidad con él - el dueño probablemente le ha dicho que el personal es defectuoso. Vea si puede evitar que haga mandatos tan amplios como “borrar toda esa basura de pruebas inútiles y reutilizar el servidor SVN”. Esto le dará tiempo para mostrar valor.

2) Continuar usando el manejo de código a nivel personal. Al menos así podrás recuperarte de tus propios errores. No le digas que estás haciendo esto, aunque tampoco le mientas.

3) Continuar con las pruebas automatizadas (pruebas de unidad, si no hay nada más) a nivel personal. Como antes, no lo mencione aunque tampoco lo oculte.

4) Trabaje con el líder para determinar cuáles son los problemas reales percibidos. Tengan una mente abierta; apuesto a que hay problemas reales con el personal. Trabaje con el plomo para abordar los problemas, no los síntomas.

5) Discuta con el plomo varios temas de desarrollo, como los beneficios de la cascada y el ágil. Ninguno de los dos es perfecto. Hágale preguntas como: “¿Bajo qué circunstancias valdría la pena hacer pruebas automatizadas?” Si da una respuesta dudosa, pregúntele cómo empresas exitosas como Google han logrado prosperar a pesar de ello.

Para que vea que estoy a favor de contratar al Lead y ver dónde tiene la cabeza. Construir la confianza. Acordar los problemas frente a los síntomas. Esto no siempre es fácil, especialmente cuando sientes que es como Godzilla y está destrozando tu trabajo.

Hay una posibilidad de que no pueda comprometerse. Aplastará las pruebas automatizadas. El manejo de códigos es para gente descuidada. Mi camino o la autopista.

Si ha llegado a este punto, sin embargo, será hora de que se vaya. Trabajar en un taller sin herramientas, y me refiero a software y herramientas de ingeniería de software - no construye tu currículum. Comenzarás a pudrirte de la misma manera que se ha pudrido el plomo. En ese caso, sigue adelante.

veinticinco años en IT […] cambiar su actitud

No va a funcionar, lo siento.

Su verdadero problema no es el incompetente desarrollador principal. Ese problema es insignificante comparado con el problema real que describes:

Tu fundador confía más en un incompetente extraño que en sus empleados actuales.

Necesitas averiguar cómo el equipo perdió su confianza, y cómo recuperarla. Esto habría sido más fácil si se hubiera hecho antes de que el extraño fuera contratado. Ahora esto es difícil, porque cualquier buen trabajo será atribuido al nuevo líder del equipo, y cualquier mal trabajo será atribuido a todos ustedes - así que no pueden arreglarlo trabajando más duro.

Sólo hay 2 cosas que puedo pensar, para mejorar la situación en este trabajo:

1. Encontrar un mediador. ¿Hay varios fundadores, o algo así como miembros de la junta?
2. Tal vez el tema de la confianza es un tema de visibilidad. En ese caso, cualquier cosa que ayude a la visibilidad te ayuda. Por ejemplo, hacer demostraciones de sprint lo suficientemente emocionantes e interesantes para que el fundador asista y aprenda sobre el estado y el progreso del equipo.

* Aunque la mayoría de los puntos planteados por el OP no necesariamente hacen que el extraño sea incompetente, su enfoque del Control de Versiones y la Integración Continua en un equipo de 5 personas sí lo hace.

Esta respuesta puede ser desfavorable y considerada grosera por algunos, pero…

La primera bandera roja es For a few years, the founder was unhappy about the technical skills of the employees

¿Han intentado los empleados rectificar la infelicidad? La segunda bandera roja es two of the five developers never used SQL before

Es difícil crear un sistema eficiente si los desarrolladores no están familiarizados con las tecnologías centrales y realmente entienden lo que el ORM está enmascarando.

Sin embargo, consideren la primera bandera roja que mencioné y la “infelicidad” con la que el fundador ha tenido que lidiar durante años.

A esto, añado: ¡¿ustedes han sabido de la infelicidad del fundador durante años?!

¿Cómo se les divulgó esta información?

Me inclino a pensar que este tipo está haciendo precisamente lo que le contrataron para hacer; poneros en forma.

Poneros en forma no se refiere a adoptar las malas prácticas del nuevo tipo, sino que implica echaros de vuestra zona de confort para aprender a un nivel más profundo.

Durante unos años, el fundador no estaba contento con las habilidades técnicas de los empleados, y recientemente contrató a un desarrollador senior para el doble papel de jefe técnico y director de proyecto. Fue el único que hizo una entrevista, y el único que decidió contratar a esta persona.

Suena como si el fundador no confiara en ustedes.

El equipo, sin embargo, se volvió mucho menos apreciado por su perfil durante dos meses. Tuve la oportunidad de hablar con tres de los cinco miembros de este equipo, y todos destacaron tres cuestiones:

• Según ellos, el tipo es un idiota, y no tiene respeto hacia los otros miembros del equipo. Una cita reciente en la que habla con un programador junior delante del equipo es muy ilustrativa: “Trabajé durante veinticinco años en esta industria, ¿y tú? ¿Qué has hecho? Has sido un mono de código durante tres años. ¡Así que cállate, tú, imbécil! A nadie le importa tu opinión.”

Suena como si sólo tuvieras un lado de la historia. Puedo imaginarme algunas situaciones en las que podría necesitar abofetear a un joven sabelotodo yo mismo, y lo he hecho. Sólo estoy jugando al abogado del diablo aquí, pero suena como si hubiera sido provocado. ¿Cuál fue la provocación?

• En el pasado, las decisiones eran tomadas por todos los miembros del equipo. Cuando los miembros no se ponían de acuerdo, lo discutían todo juntos y llegaban a un acuerdo, o al menos explicaban el razonamiento a los que no se ponían de acuerdo.

• Aparentemente, las prácticas del pasado no generaban los resultados que el fundador quería.

• Ahora, todas las decisiones importantes son tomadas exclusivamente por el desarrollador principal. Esas decisiones no pueden ser cuestionadas o discutidas, incluso si los cinco miembros del equipo encuentran que una decisión no tiene sentido.

De nuevo, suena como un voto de desconfianza del fundador. Trajo a este tipo de personas por una razón. Suena como que la razón fue para poner en forma al resto del equipo.

1. Odia los IDEs, la autocompletación y las características que pretenden ayudar a los programadores a escribir código más rápido, y afirma que el equipo debería usar Notepad++ para ser productivo. Aunque tiene sentido en diferentes circunstancias, es difícil imaginar que los desarrolladores de C# abandonen repentinamente Visual Studio por Notepad++.

Los IDEs pueden ralentizarte si eres un programador rápido. Notepadd ++ es superior a algunos para la codificación rápida. La idea es que escribas tu código, y luego lo dejes caer en el IDE para una corrección rápida en lugar de interrupciones constantes.

1. No refactoriza el código, y no se preocupa por el estilo (que es inconsistente en todo su propio código), la razón es que “sólo se preocupa por las cosas que realmente importan”. Como nota al margen, el estilo fue previamente comprobado por una construcción nocturna, que comenzó a fallar desde la llegada del nuevo líder.

Los estándares de la tienda son algo que hay que discutir con el fundador, especialmente desde que lo estás ejecutando a través de la construcción nocturna. Pero de nuevo, leyendo entre líneas, parece que el fundador no confía en ti.

1. Rechaza la idea de una construcción nocturna, así como las pruebas automatizadas. Según él, “cualquier desarrollador profesional prueba su código de todos modos a mano, así que no hay razón para perder el tiempo escribiendo pruebas automatizadas”. La construcción nocturna también es una pérdida de tiempo, según él.

Tiene razón, las pruebas automatizadas no explican la genialidad de un tonto que hace algo que nunca pensó. Personalmente he roto varios programas que pasaron por pruebas automatizadas.

1. Él piensa que el control de versiones es mayormente inútil, y parece malinterpretar cómo usar uno. Esto le lleva a situaciones en las que desarrolla una función solo durante tres o cinco días, y cuando finalmente compromete sus cambios, “toma los míos” para todos los conflictos. Si otros miembros del equipo se quejan de que su código fue borrado, los invita a reescribirlo. En varias ocasiones, otros miembros hicieron lo mismo, borrando el código del desarrollador principal. Parecía sorprendido (parece que no sabe cómo usar svn log o diffs), e hizo sus cambios de nuevo, quejándose de que “se perdieron misteriosamente” y culpando a SVN de haberla fastidiado.

Todo el mundo tiene la culpa aquí. ¿Nadie hace copias de seguridad? Si tiene problemas con el control de versiones, es responsabilidad del equipo trabajar como un equipo y no sólo hacerle pasar un mal rato por ello.

1. Exagera la importancia de la optimización del código. Su enfoque es correcto, es decir, ejecuta un perfil, determina un cuello de botella y lo soluciona; el problema es que no hay requisitos no funcionales de rendimiento, y no hay elementos que indiquen que los usuarios puedan considerar que la aplicación es lenta (y alojada en máquinas virtuales de desarrollo de bajo grado, la aplicación se siente muy receptiva). Él, por otro lado, pasa prácticamente la mitad del tiempo optimizando el código.

No hay forma de exagerar la importancia de la optimización del código. El propósito de la optimización del código no es asegurarse de que funciona correctamente hoy el propósito es optimizarlo para que no estás arreglando algún problema tres años después que podría haberse evitado con la optimización del código.

Si sólo te importa que los usuarios sean felices hoy, vas a tenerlos golpeando tu puerta mañana.

1. Escribe todo el SQL a mano, y rechaza la idea de un ORM. Hay que tener en cuenta que el producto actual se basa en el ORM Entity Framework de Microsoft, y que dos de los cinco desarrolladores nunca han usado SQL antes.

Dos de los cinco desarrolladores deberían ser despedidos entonces. Si se basa en un ORM, nunca podrá meterse bajo el capó y arreglar las cosas manualmente. Empiezo a ver por qué llamó a alguien “mono de código” en su frustración. Los ORM están bien y son buenos, pero necesitas entender el SQL si vas a ir más allá de las limitaciones de un ORM.

1. Rechaza los frameworks y las librerías de terceros, considerando que es mucho más fácil escribir cosas desde cero. Decidió abandonar todas las librerías y frameworks de JavaScript excepto jQuery, afirmando que cuando empezó a programar en JavaScript hace quince años, no había frameworks, y la vida era mucho más fácil.

Tiene razón. Los frameworks y las bibliotecas de terceros tienen limitaciones, y si no entiendes lo suficiente para entrar y arreglarlo tú mismo, no entiendes el código. Un argumento podría ser hecho de cualquier manera. Sin embargo, si nadie en el equipo puede codificar sin usar los frameworks, entonces tienes un equipo muy débil.

1. Piensa que los dispositivos móviles (incluyendo las tabletas) son sólo una exageración, por lo que no hay razón para perder un tiempo precioso para asegurar la compatibilidad del sitio con esos dispositivos y para hacer un diseño sensible. El producto es una aplicación web pública que no se espera que se utilice mucho de los dispositivos móviles. El diseño sensible, sin embargo, podría ser muy interesante para esta aplicación, ya que incluso en los ordenadores de sobremesa, se mostrará tanto en monitores de 19 pulgadas como en los grandes de alta resolución.

Por todo lo que has dicho, parece que lo han traído a casa limpia. Si los dispositivos móviles no son un jugador importante para las aplicaciones, pasar demasiado tiempo es un desperdicio. Mientras que puede ser un “agradable tener” en un escritorio, un “agradable tener” no es una necesidad para el despliegue.

1. Pide al equipo que deje de usar Internet (especialmente StackOverflow) y que confíe en sus cerebros, la documentación offline (¡ni siquiera sabía que Microsoft todavía vende CDs de MSDN!) y los libros.

Bien por él. Parece que quiere saber quién puede hacer sus propios deberes y quién ha estado haciendo trampas.

Los miembros del equipo se quejaron al fundador de la compañía sobre su nueva pista acerca de esos tres temas. El fundador respondió que están exagerando, y que tiene una confianza absoluta en las habilidades del nuevo líder, basándose en su CV y en la entrevista, que es exactamente por lo que le asignó a esta persona el papel de desarrollador líder en primer lugar.

¿Qué debería hacer el equipo para:

• O bien echar al líder del equipo o de la empresa,

• O bien obligarle a cambiar su actitud hacia el equipo?

¿Qué tal trabajar _con él y no sabotear cada uno de sus movimientos?

Con toda honestidad, suena como si lo hubieran traído para limpiar la casa, dado lo que ha publicado, suena más que justificado.

El dueño NO está satisfecho con su desempeño. Le convendría tomar el consejo de este tipo por lo que vale. Las reliquias tenemos un poco de experiencia y sabemos lo que los libros nunca te enseñarán. Sin embargo, en lugar de ver esto como una oportunidad para aprender y crecer, su equipo está teniendo un gran ataque de histeria.

No sé hasta qué punto los miembros de su equipo se han quejado a su jefe sobre el desarrollo de plomo. Pero ¿has tenido una buena conversación con ellos? Explica los problemas que tienes con el líder a tu jefe y déjalo tener su versión de la historia.

Dejar de fumar debe ser el último recurso.

El dueño necesita contratar a un gerente de personal

Otras respuestas han insinuado esto, pero el elefante en la habitación es que el dueño (comprensiblemente) parece tener dificultades para llevar a cabo con éxito las funciones de personal como la contratación, la formación, el despido, etc. Un ejemplo: el dueño provee de personal a un equipo de bajo rendimiento, lo soporta durante años, luego contrata a un veterano de 25 años para arreglar las cosas, y luego contrata a un consultor cuando el veterano de 25 años no puede arreglar las cosas. El dueño no parece saber cómo manejar el lado del personal del negocio. Está bien, hay gente que hace esto para vivir, y por eso la mayoría de las organizaciones tienen gerentes de personal. El propietario necesita contratar a un empleado de inmediato. Esto liberará al propietario para que se concentre en el lado estratégico del negocio, por lo que es una ganancia.

Quizás OP podría ayudar con la entrevista (después de todo, el propietario parece necesitar ayuda en este sentido)?

Una “arruga” que aún no he visto aquí. Es bastante común que la gente con mucha experiencia se ponga a la defensiva por no estar al tanto de los acontecimientos actuales. Solía pasar lo mismo con la gente que hablaba de lo horrible que era VB6 en relación con el maravilloso .Net, cuando esa gente sólo repetía cosas que habían oído sobre VB6 y no sabían realmente mucho sobre él.

Como dices, muchas de las cosas que el líder dice están en su punto. Pero eso no significa que todas lo estén, como dices. Tal vez el Sr. 25 años pueda abrir su mente y sintetizar su enfoque con lo mejor del status quo, pero no si tiene miedo de ser menos que perfecto y en la negación de tener miedo. En lo que a mí respecta, ese es el verdadero problema aquí. Puede que haya otros problemas con los jóvenes (defensivos sobre su falta de experiencia, por ejemplo), pero ese parece ser el problema subyacente aquí.

Si todos se reúnen y abordan sus miedos de una manera abierta y honesta, entonces deberían comenzar a moverse en una dirección más positiva. No puedo decir que suene como una alta probabilidad, pero es lo que hay que hacer.

1. ¿Todo el equipo ha hablado con este desarrollador y ha intentado explicarle los beneficios de cosas como el control de versiones y los IDEs? Una discusión franca en masa puede ayudar

2. Estoy de acuerdo en que insultar a otros desarrolladores es poco profesional y esto debe ser explicado con fuerza. Pregúntele si está contento de que otros adopten el mismo tono… Pregúntele si está sufriendo algún tipo de estrés doméstico o si tiene algún problema de salud como la diabetes que le causa irritabilidad… Pregúntele si está contento de estar envejeciendo y es un viejo gruñón con la mente atrofiada mientras no aprende nada nuevo.

3. Si todo lo demás falla diga que todos sus errores serán documentados para salvar su propio pellejo y las conversaciones con él pueden ser grabadas