¿Cuántos juniors debe tener un mentor senior? [cerrado]

El tamaño de nuestra tienda aumenta dinámicamente, por lo que estamos planeando contratar algunos nuevos desarrolladores junior, pero no nos gustaría abrumar a los seniors con demasiada tutoría y capacitación. ¿Cuántos desarrolladores junior (generalmente recién salidos de la universidad) podrían (y deberían) ser un mentor desarrollador senior mientras el senior todavía puede hacer sus tareas de manera efectiva?

En cualquier lugar de 0 a 5 o 7 (más o menos).

Argumentos para el lado bajo:

• No todo el mundo se propone ser un mentor. He trabajado con algunos desarrolladores que fueron tan brutos que habrían asustado a alguien en una nueva carrera.
• Si espera que los desarrolladores senior mantengan el mismo nivel de producción, mantenga el número bajo.

Argumentos por una cantidad mayor:

• Algunos desarrolladores tienen la capacidad de ser igual de productivos al guiar el trabajo de otros. La programación en pareja sería un ejemplo. Si tienes esos tipos mágicos de desarrolladores senior, entonces adelante y dales más.
• Si está dispuesto a reducir el rendimiento esperado del desarrollador senior, puede asignarles más desarrolladores junior.
• Si tienes un desarrollador que es realmente bueno para enseñarles por qué es de gobernanza, entonces es posible que desees explícitamente tener éxito en la productividad de ese desarrollador senior y darles más desarrolladores junior. La idea aquí es un costo a corto plazo (pérdida de producción) para una ganancia / inversión a largo plazo (mejor conformidad con los estándares de desarrollo del equipo).

Animaría a tener una conversación con los desarrolladores senior y ver con qué se sienten cómodos. No todos quieren ser mentores. También recuerde utilizar la analogía de "estantería llena": sus cargas de trabajo están actualmente llenas. Si va a aumentar su carga de trabajo al tenerlos como mentores, entonces necesita sacar algo más del estante para hacer espacio.

No más de dos por desarrollador senior si está contratando personas directamente de la universidad. Los graduados universitarios recientes con los que tuve que lidiar en el pasado tienen una buena comprensión de los conceptos básicos, pero no tenían idea de cómo era programar en el mundo de los negocios. Tendrás que pasar tiempo enseñándoles cómo programar profesionalmente, es un shock cuando se dan cuenta de que tendrán que soportar el código que escriben mientras estén con la empresa, no más tareas y cambios. Pero también tendrá que pasar tiempo enseñándoles su negocio (y todas sus reglas), enseñándoles cómo codificar su arquitectura, revisando su código, enseñándoles cómo evaluar y respondiendo pregunta tras pregunta tras pregunta.

Si tienes muchos jóvenes entrando, digamos> 30, podría valer la pena dedicar un desarrollador sénior para que los guíe a tiempo completo. En mi primer trabajo contrataron a muchos de nosotros recién salidos de la universidad y tuvimos un miembro del equipo dedicado que nos ayudó a aprender las reglas durante los primeros 6 meses. Hizo la transición mucho más fácil y nos enseñó mucho.

No solo es más eficiente tener una persona encargada del trabajo, sino que puede haber una sola persona en su oficina que sabe que sería un mentor perfecto. Un buen programador no es necesariamente un buen maestro.

Tantos como puedan mientras pueden hacer su propio trabajo a tiempo.

La respuesta, por lo tanto, depende de cuán efectivo sea el senior como desarrollador y como maestro.

No mencionas el tipo de trabajo del proyecto que, en mi experiencia, tiene un GRAN impacto sobre dónde debería estar esa relación.

En una escala de repetición de cortador de cookies que casi podría automatizarse a cosas experimentales, el desarrollador ni siquiera está seguro de que funcionará, debe asegurarse de mantener los desarrolladores jr a la izquierda a menos que esté en una relación realmente baja e incluso más estrictamente a la izquierda si los desarrolladores sr están tratando de hacer algo que consideran para el extremo experimental del espectro porque generalmente no serán tan efectivos montando manada en un equipo de desarrolladores jr si se están esforzando al mismo tiempo .

Depende del trabajo tanto como las personas en mi opinión.

La tutoría es menos formal que la gestión. Los mentores no están directamente involucrados en la contratación, despido, revisión y disciplina. El medio ambiente será un factor importante. Aquí están los factores a considerar:

• calidad de sr. y jr. desarrolladores
• qué tan bien se maneja la compañía / trata a los programadores (esto agravará los otros problemas)
• sr. carga de trabajo actual del desarrollador
• las expectativas de la gerencia sobre qué tan rápido el jr. los desarrolladores necesitan ser productivos
• otros recursos de capacitación (cursos asistidos por instructor, materiales de referencia, requisitos de certificación)
• contratación para adaptarse al equipo. Muchas veces en este sitio, las personas han mencionado la importancia del equipo que se necesita para crecer y poder funcionar juntos. Alguien con un nivel de habilidad más alto puede necesitar más tutoría si no encajan.

La tutoría generalmente implica cierto nivel de vinculación y simplemente no creo que la mayoría de las personas puedan construir ningún tipo de relación interpersonal con más de 3-5 personas en un entorno determinado.

Idealmente, un junior trabaja con un mentor en un proyecto. De esta manera, el senior puede asignar subtareas y trabajar con ellos para completar un proyecto. Mientras más juniors tenga que manejar el Senior, menos trabajo podrá completar el senior. No quisiera que más de 1 o 2 junior trabajen con un senior en cualquier momento. Aunque el senior puede seguir asesorando a otros programadores después de 2 o 3 meses, un programador decente debería necesitar mucho menos tiempo del senior que lo que originalmente necesitaba. Por lo tanto, una persona mayor podría tener 20 o más personas para las que es mentor, pero en realidad solo 2 o 3 que realmente requieren gran parte de su tiempo.