Cómo ayudar a un desarrollador sénior que está más allá de ayudar

Mi primera idea fue agregar pruebas, verificadas por un sistema de integración continua, para que limitara la cantidad de daño que puede causar a su proyecto, que también es el punto de la respuesta li x.

Luego, está el problema de que este tipo en realidad está ganando dinero para la empresa, de una manera perversa. Al hacer que el cliente pague por las horas empleadas, se convierte en una ventaja monetaria tener a alguien que está deshaciendo el trabajo de otras personas. Sería como ser contratado para construir un muro y tener un albañil haciendo un muro y otro empleado derribándolo.

Sin embargo, a largo plazo, el cliente puede cambiar de opinión (tal vez nunca más usar los servicios de su empresa) si se entera de que usted está haciendo eso (ya sea sin darse cuenta o a propósito), y también podría considerarse negligencia de su parte. .

Sin embargo, es probable que su jefe no tenga esas razones maquiavélicas para no despedirlo. En este punto, tienes a una persona cuyo trabajo no es útil para nada a la empresa. Yo sugeriría cambiarlo a una posición diferente . Usted afirma que es una causa perdida hacer que codifique correctamente Python. Pero tal vez pueda hacer un buen manual de usuario. O pruebe el programa en sus diferentes iteraciones para verificar que las funciones funcionan como se esperaba. Técnicamente, ya no trabajaría como desarrollador . Sin embargo, es algo que a menudo recae en el propio equipo de desarrolladores y, al ser una empresa pequeña, supongo que no tienes un equipo dedicado a eso.

En cualquier caso, un mal probador que solo ocasionalmente encuentra un error será más útil que el anti-desarrollador que parece haber sido cuando trabajaba hasta ahora. Por lo tanto, cualquier tarea que lo mantenga ocupado probablemente sea beneficiosa, incluso con un rendimiento bajo. Y las habilidades del desarrollador, que le permiten leer y comprender el código, son útiles para dirigir los casos de prueba, incluso si no puede escribir el código adecuado (aunque no es tan malo si no puede).

Un problema potencial con este enfoque sería que logró probar el programa demasiado rápido (¿tal vez porque se está saltando la mitad de los requisitos?). El siguiente paso sería codificar pruebas automatizadas para verificar los requisitos del proyecto, de modo que no necesite dedicar tiempo continuamente a realizar las mismas tareas aburridas, y se realicen de manera consistente cada vez. (Obviamente, se necesitarán muchas iteraciones hasta poder tener una cobertura completa de los requisitos)

Tienes una larga lista de cosas en las que es malo.

¿En qué es bueno él?

Descúbrelo y ponlo a trabajar en ese lugar.

Como su gerente, es su trabajo responsabilizarlo por no seguir el procedimiento. Yo iniciaría un proceso documental en este caso ya que este empleado parece no estar dispuesto a modificar sus malos hábitos.

Si el registro en papel no funciona, entonces póngalos en un plan de mejora del desempeño [PIP] formal , trabajando con RRHH, con objetivos claramente definidos , medidas y un marco de tiempo para lograr los objetivos.

Si el desarrollador no cumple con los objetivos, debe estar libre y claro para dejarlos ir, y su mente debe estar libre de culpa. Él también puede irse solo, lo que también resolverá su problema. Esperemos que esto sirva como una llamada de atención y actúen juntos.

"Recientemente me ascendieron como gerente", luego comience a aprender a ser gerente. Te guste o no, por lo que has descrito, ellos están haciendo el trabajo por el que se les paga, pero tú no.

Tiene un empleado al que parece haberse dado por vencido, eso no es una buena gestión. Estás haciendo su trabajo por ellos, eso no es una buena gestión. Estás permitiendo que interrumpan el proyecto, eso no es una buena gestión.

Este empleado está claramente (y posiblemente justificadamente) descontento, pero en lugar de abordar las causas de su queja, las está agravando. No importa si eres un mejor programador o si conoces las sutilezas de Python mejor que él, porque tu rol actual es el de gerente, no el de programador, y el trabajo de un gerente es hacer que otras personas, incluido él, participen. quiere hacer lo que usted quiere que ellos hagan. Quiere que produzca un código que cumpla con las normas de su empresa. Averigüe por qué no quiere y cambie algo para que sí quiera. En el caso extremo, puede obligarlo a elegir entre hacerlo a la manera de la empresa o trabajar para una empresa diferente, pero debe considerar que es un fracaso de su parte sin importar cómo resulte.

Sugerencia

Por mucho que me duela sugerir, ¿ha considerado implementar algo como pruebas TDD o BDD en su tubería? Desde mi experiencia, un conjunto de pruebas bien desarrollado, incluso si no se implementa de manera estricta, puede hacer maravillas para los de bajo rendimiento. Esto no acelerará su desarrollo, pero lo que hará es que los postes de la portería sean más transparentes cuando se trata de lo que necesita hacer para poner sus parches al día. Mejor aún, cosas como la cobertura de código pueden ser una gran herramienta para impulsar la motivación, ya que tendrá una métrica visible asociada a su trabajo junto con los beneficios obvios.

También significa que si no pasa las pruebas, no puede pasar a más destrucción.

Mi opinión

A veces en los equipos hay alguien que simplemente no encaja en el molde y realmente no debería estar sobre tus hombros, pero es así que tendrás que lidiar con eso internamente. En última instancia, como líder, debe tomar las decisiones correctas para el equipo y, si eso significa limitar lo que puede trabajar y hacer, entonces tiene que ser así. Personalmente, aprovecharía todas las oportunidades para dejar en evidencia que si no mejora, no se puede tomar mucho de la mano . Trabaje con la alta gerencia y si todavía no está funcionando, hay un punto en el que debe dejarlo e informar a la gerencia sin rodeos que no está funcionando y que su posición es que necesita irse o pasar a una parte diferente del negocio. Algunas de las cosas que tú

Mi opinión impopular

Eres un gerente y tienes contacto directo con la alta gerencia, podría ser el momento de buscar un reemplazo si su comportamiento continúa.

Se supone que un desarrollador senior no debe ser senior solo por envejecer y estar allí durante mucho tiempo, sino por ser un buen desarrollador. Esta persona no parece un desarrollador senior.

Sugiero una conversación individual en la que expliques la situación, y que su trabajo no es satisfactorio, que en realidad no vale su salario (¿o sí?), y lo que cree que tú y él pueden hacer para cambiar esto. .

Honestamente, creo que la respuesta se encuentra en su título "cómo ayudar a alguien que está más allá de ayudar". Crees que está más allá de ayudar. Creo que parece que está más allá de ayudar. En realidad, podría estar más allá de ayudar.

Si se tratara de un desarrollador junior, aceptaría, como máximo, este tipo de rendimiento durante los primeros meses; después de eso, deben cumplir. Eso es lo máximo, creo que contratar a cualquiera que no pueda producir código el primer día es una contratación arriesgada.

Este tipo lleva el título senior, se supone que debe ser el mentor de los desarrolladores junior o al menos tener un buen desempeño.

Has tratado de persuadirlo para que cambie, y eso no funcionó. El cambio debe ser obligado, lo que requiere una acción disciplinaria o terminación, por lo tanto, la intervención de la gerencia.

Actualmente me resulta más fácil y rápido no darle ninguna tarea, cada vez se acercan más los plazos y es más rápido hacerlo yo mismo. De hecho, estoy considerando cambiar de trabajo por su culpa.

Esto es lo que tu jefe necesita saber. Dependiendo de su relación, tendrá que decidir si concentrarse en los plazos que se avecinan o en su deseo de cambiar de trabajo.

Dado que a su jefe le preocupa perder horas facturables, puede señalar que reemplazar $SeniorDev con un desarrollador efectivo dará como resultado la misma cantidad de horas facturables y mejorará la moral y la capacidad de cumplir con los plazos. Esto funciona mejor para los dos.

Mi experiencia en software es que si un desarrollador no comprende la importancia de probar y verificar el código antes de registrarlo, entonces no tiene sentido tratar de trabajar con él o ella. Lo mejor es seguir adelante y centrar sus esfuerzos en convencer a los demás de la necesidad de hacerlo.

Parece que su trabajo es producir horas facturables, no software, y es bueno en su trabajo. Tu cliente es estúpido, tu jefe no tiene escrúpulos. El empleado está más allá de la ayuda.

Tienes dos opciones: dejar de preocuparte o buscar otro trabajo.

En primer lugar, no ha explicado cuáles son los requisitos y habilidades del puesto de alto nivel en su empresa. Un rol de alto nivel significa que las habilidades, las capacidades y las expectativas difieren drásticamente según la empresa. Él es un senior allí, por lo que primero debe verificar si cumple con los criterios definidos por su empresa.
Con respecto a la situación y los problemas que señala. Creo que estás tratando de abordar demasiadas cosas a la vez.
Comience con lo más importante, que es el hecho de que el código no es funcionalmente lo que necesita el cliente, ya que faltan los requisitos.
Después de abordar eso, puede continuar con la forma en que el código podría ser mejor y, eventualmente, con la forma de codificar correctamente en Python.
Si comienza con tales discusiones, es fácil desviarse porque los desarrolladores suelen tener opiniones variadas y bastante sólidas sobre estos puntos.
Tal vez el chico está abrumado o no le gusta Python y eso afecta su desempeño.

Por la forma en que describiste esto, probablemente colocaría a este desarrollador en el departamento de "no muy bueno" y me preguntaría si los quiero como parte de mi pequeño equipo, donde cada desarrollador tiene un gran impacto en todo lo demás. Los desarrolladores deficientes pueden esconderse en tiendas grandes y trabajar en áreas de código divididas que tienen poco o ningún impacto en el resto, pero las tiendas pequeñas generalmente tienen a todos capaces de tocar y, por lo tanto, romper otras partes del código. Sacar un revelador de este tipo del sistema suele ser un caso de suma por resta . Debes explicarle esto al gran jefe, que preferirías que no codifique en absoluto para que el otro desarrollador y tú hagamos más.

Si el problema tiene que ver con las horas facturables, entonces también puede hablar con el gran jefe sobre cómo reemplazar a esta persona con una persona más joven y más barata puede ser una doble victoria. Obtiene márgenes más altos en las horas facturables y el reemplazo, aunque quizás no pueda abordar los problemas más difíciles, al menos puede ser productivo para avanzar en las partes más fáciles de la solución sin dañar el trabajo de otros.

Así que conviertes esto en un caso de negocios y lo presentas al gran jefe como una forma de mejorar el negocio reemplazando el área problemática. Como gerente, aprenderá que su función se expande desde solo centrarse en la tecnología hasta pensar también como propietario de un negocio y comprender cuáles son los impactos generales.

En cuanto a cómo entrenar realmente a esta persona, lo que generalmente establezco desde el principio en un taller que dirijo es una Definición sólida, bien definida y socializada de Listo . Esta es la línea en la arena que dice que ningún trabajo se puede considerar completado (dependiendo de su configuración que se puede fusionar para dominar, empujar para producir, etc.) hasta que se cumplan todas las cosas en su Departamento de Defensa. Luego lo hace cumplir con TODO el trabajo realizado por el equipo de manera uniforme. Entonces, si dicho desarrollador no completa sus pruebas, el trabajo se detiene en seco con una declaración explícita de "falta de pruebas adecuadas" y el desarrollador tiene que terminar eso antes de poder pasar a la siguiente tarea.

Sí, esto significa que ahora debe usar parte de su tiempo para auditar el trabajo de su taller, pero eso es parte de la administración. También puede usar este u otros tipos de revisión por pares para recorrer los controles propuestos y detectar algunos de esos refactores dañinos que mencionó antes de que afecten el resto del código base. A través de su Departamento de Defensa, establece puertas alrededor de la calidad (es decir, pasa un PR) que evitan comportamientos dañinos.

Si aplica estas puertas y realmente evita que cualquier desarrollador impulse soluciones parciales o mal hechas, entonces será bastante obvio quién hace cuánto y con qué rapidez. Luego puede usar este tipo de seguimiento para cuantificar el valor de cada desarrollador, ayudándolo a presentar el caso al gran jefe del que hablé anteriormente sobre la productividad real y aprovechar el dinero de cada desarrollador en el equipo.