¿Cómo debería pedirle a un ingeniero que deje de usar lenguajes de programación y marcos donde otros desarrolladores no tienen experiencia?

Supongo que estás razonablemente a cargo. Si no estás a cargo, habla con tu jefe.

Recuerde que todavía no estamos programando todo en FORTRAN IV y COBOL. En algún momento, la actualización del lenguaje y el marco es algo bueno. Toda su tienda podría beneficiarse más si su molesto ingeniero recibe entrenamiento para ser un líder de pensamiento en lugar de aceptar “hagámoslo como ya lo sabemos”

Pero debes estar todos en la misma página.

Reúna todo el barco para establecer estándares. Hable al respecto. Tal vez al resto del equipo le gustaría adoptar algunos de estos marcos y aprenderlos. Deje que todos presenten sus mejores ideas. El líder tecnológico elige a los ganadores.

Una vez que tenga un conjunto estándar, incluidos los lenguajes y marcos permitidos y prohibidos, inclúyalo en la revisión de código.

El código que falla en las revisiones se rechaza, punto. Si no ha realizado el trabajo de conformidad con el estándar, no lo ha hecho. Período. Si no tiene revisión de código y estándares, lo está haciendo mal. Muy. Mal. Incorrecto.

Luego, su desarrollador evalúa su rendimiento en parte en la entrega oportuna de código y si no cumple con el estándar la primera vez, le llevará más tiempo.

Revise el estándar cada pocos meses. Esté atento a las tendencias emergentes, pague deudas técnicas y avance hacia el futuro (pero solo con versiones maduras)

Esto depende de qué idiomas y marcos esté usando. Si está utilizando un lenguaje desactualizado u obsceno que rara vez se usa hoy en día y no tiene ningún beneficio funcional sobre los frameworks o lenguajes comúnmente utilizados, entonces debe ser notificado de que el resto de los desarrolladores no pueden mantener sus aplicaciones y se convierte en un riesgo para la compañia.

Si está utilizando frameworks de uso común como .NET o el lenguaje de programación R para análisis de datos de gran tamaño, entonces recomendaría algún tipo de capacitación progresiva para los otros desarrolladores para que también puedan utilizar el software.

Todos los talleres de desarrollo deben tener un conjunto definido de tecnologías preferidas derivadas de las habilidades del personal y la capacidad de capacitación de la organización.

Esto no impide la incorporación de nuevas tecnologías, define cómo deben pasar por una introducción administrada. En general, lo que se requiere es una política de no proliferación tecnológica. Esto determinará cómo se debe justificar e introducir una nueva tecnología. Un ingeniero que introdujo nueva tecnología porque la novela es un ingeniero muy pobre. Las nuevas tecnologías deben introducirse solo cuando muestran una clara ventaja sobre una tecnología existente y esto requiere una adopción y migración gestionadas.

Hay varios factores a tener en cuenta:

  1. ¿Es posible adoptar nuevas tecnologías?
  2. ¿Adoptar nuevas tecnologías hará que el equipo sea más productivo?
  3. ¿El aumento de la productividad justificará el esfuerzo dedicado al aprendizaje, la actualización de la cadena de herramientas, etc.?
  4. ¿Es posible usar nuevas tecnologías localmente o requieren la adopción de todo el equipo?
  5. ¿Es ese ingeniero capaz y dispuesto a ser el campeón de ese cambio?

Si tiene un “no” para el # 1, ese es prácticamente el final de la historia. Cortésmente pero con firmeza explíqueles las razones por las cuales no y siga adelante.

Si tiene un “sí” para el n. ° 1, deje que ese ingeniero haga el argumento de venta del resto. Si no se convence, entonces sus preocupaciones son las razones por las que no, explíquelas y continúe.

Si te convences, entonces quizás deberías optar por este cambio.

Según tengo entendido, tienes un desarrollador que tiene más experiencia que el resto.

Entonces, lo que se puede hacer es esto. Hable con el desarrollador y pregúntele por qué usa esta tecnología. Discuta con él si es importante que otros desarrolladores también conozcan esta tecnología.

Decide si vale la pena usar la tecnología. Si no, deje en claro cuál es su decisión, por qué y qué debe hacer.

Si vale la pena planificar cómo actualizar otros desarrolladores para que puedan beneficiarse de la tecnología y la experiencia de su desarrollador principal. Explique que es necesario que todos lo entiendan y que el desarrollador puede proceder solo cuando se cumpla esta condición.

Voto a favor. Gracias.

No tengo respuesta para ti, solo una anécdota muy reciente, y ten en cuenta que este podría ser tu equipo / compañía …

Tuvimos un desarrollador que insistió en probar y usar los frameworks y herramientas más exóticos, la mitad de los cuales realmente no entendía en primer lugar, al menos no tanto como nos hubiera gustado al resto de nosotros.

Bueno, se fue, con poca antelación. Estoy atascado con proyectos a medio terminar realizados en marcos que son difíciles de poner en producción, que yo y el equipo no vamos a seguir adelante, tratando de recuperar y estimar lo que nos costará ponerlo en forma para que podamos póngalo en producción, para apoyarlo y vivir con él durante bastante tiempo.

¿Cómo es tu postura sobre el tipo que usa cosas que nadie más usa ahora?

No estoy seguro de quién eres dentro de la imagen de las cosas, pero si eres el propietario y el líder del equipo respectivo, entonces debes sentar a esa persona. Dígales que el ingeniero se encargará personalmente del mantenimiento de ese sistema si continúan trabajando de esa manera. Espero que no le guste mantener el código solo, pero de lo contrario, es posible que deba eliminarlos del proyecto si no usan el marco preferido de su equipo.

Una de las bases de un buen código es mantener la capacidad.

Debería decirle a su ingeniero que él no es el único que trabaja en el código y, en caso de que tenga un permiso prolongado por alguna razón, alguien más debe continuar donde lo dejó.

Por esa razón y algunas otras que podría pensar, el código no debe restringirse a una persona y debe ser compatible con otras.

Ojalá lo consiga.

Si usted es el jefe, simplemente pregúntele a la persona y explique su razonamiento.

Aunque, espere la respuesta “¿Cómo obtendrán experiencia si no la usan?”

Tenga una respuesta lista …

Puede ser mejor preguntar por qué la persona está haciendo esto, y seguir desde allí.

Algunos programadores e ingenieros simplemente no son personas, explican las cosas en sus términos y si no lo entiendes, es tu culpa.

No hay nada que puedas hacer con alguien así. Es el lugar de su supervisor para decirle que salga o salga bien.