¿Deberían exigirse a los programadores senior que asuman y asesoren a un desarrollador junior? [cerrado]

En una tienda que pretende ser unida y solidaria, ¿debería ser parte de la cultura que los desarrolladores senior estén emparejados con desarrolladores junior como mentores? ¿O esta tutoría debería ser algo más orgánico y espontáneo, es decir, no requerido, pero permitido desarrollar sin estímulo artificial?

Creo que debería ser alentado pero no requerido; los adultos mayores no deberían ser asignados a jóvenes ni nada por el estilo, de lo contrario terminarás en Dilbert-land. La relación "mentor-mentoreado" requiere un cierto nivel de amistad en su núcleo, así como una buena dosis de respeto mutuo. No obtienes eso simplemente diciéndole a la gente que se vaya y "mente".

¿Debería ser parte de la cultura que los desarrolladores senior estén emparejados con desarrolladores junior como mentores?

Sí.

orgánico y espontáneo, es decir, no es obligatorio, pero se permite que se desarrolle sin estímulo artificial

No sucederá con la frecuencia suficiente para ayudar a alguien.

Las personas con relaciones existentes en las organizaciones serán percibidas como camarillas o elitistas por personas nuevas. Las camarillas normalmente no se descomponen. Nos quedamos con personas que conocemos: es un elemento esencial de la naturaleza humana.

Como consultor durante más de 30 años (cientos de compromisos con clientes) puedo afirmar que las personas nuevas siempre son ajenas. No es una característica de la "cultura" o "atmósfera". Es una característica esencial de cómo trabaja la gente. Los consultores forman su propia camarilla porque el personal establecido no tiende a incluirlos en nada.

La única forma de establecer la tutoría es insertar nuevas personas en las camarillas.

El significado tradicional de "mentor" desafía de alguna manera las tareas. También podrías tratar de asignar amigos.

Está bien, en mi experiencia, asignar un nuevo miembro del equipo para usar un miembro del equipo establecido como su contacto principal para preguntas durante la primera semana, mes, más o menos.

¿Se debe exigir a los desarrolladores senior que guíen a los desarrolladores junior?

Absolutamente no. Algunos buenos desarrolladores senior van a ser mentores horribles y el emparejamiento de personalidades es imprescindible para una mentora exitosa. Sin embargo, creo que se debe exigir a los desarrolladores senior que mejoren algo sobre el equipo de desarrollo. Eso podría ser la creación de prototipos de algo, mejorar un proceso o práctica, ser pionero en nuevas herramientas, presentar material técnico al grupo, liderar un equipo u otra cosa. En otras palabras, deberían tener la responsabilidad de algo que sea más grande que el trabajo compartido individual.

¿O esta tutoría debería ser algo más orgánico y espontáneo, es decir, no requerido, pero permitido desarrollar sin estímulo artificial?

No, tampoco estoy de acuerdo con esa opinión. He visto demasiadas situaciones en las que se espera que la tutoría sea "orgánica y espontánea" y esto ocurre muy raramente. Creo que las organizaciones deben asumir la responsabilidad de dar a los mentores la oportunidad de contagiarse, pero no se puede forzar. Eso es difícil, pero vale la pena. Creo que la organización podría hacer cosas como:

• Reuniones informales entre mentores potenciales y protegidas potenciales
• Formas y oportunidades sugeridas para que la organización reconozca formalmente la tutoría (por ejemplo, si usted es un lugar que tiene un número de cargo para prácticamente todo, cree un número de cargo para las reuniones de mentores, aclarando que esto ES una parte viable del trabajo )
• Capacitación y apoyo para mentores.
• Orientación para proteger cómo seleccionar un mentor y qué esperar
• orientación a los mentores sobre qué esperar y qué ofrecer
• Patrones sugeridos (o forzados) para tutorías con plantillas para la participación; por ejemplo, es mucho más fácil darle una oportunidad si sabe de antemano que su objetivo es una experiencia de 3 meses con reuniones semanales y el objetivo de ayudar a un nuevo desarrollador a levantarse e ir en la empresa. No quiere decir que no se convertirá en más ... pero da un lugar para que la gente comience.

Creo que hacer que sea un requisito podría ser contraproducente, ya que algunas personas simplemente no están conectadas de esa manera, y la idea les disgustaría mucho. Dicho esto, debe identificar a las personas que cree que son adecuadas para ser mentores y abordarlas para que tomen un papel más activo en la mentoría (si no lo son). Este enfoque basado en ejemplos podría captar e inspirar una tutoría más espontánea.

También puede programar actividades grupales que se realicen regularmente, lo que ayudará al equipo a gelatinar. Estas podrían ser actividades completamente sociales, como un almuerzo en equipo, o actividades que incorporan el aprendizaje sobre programación, como un club de libros de programación semanal.

También podría tener "mini postmortems" regulares en los sistemas, que funcionarían como una revisión de código de grupo. Un beneficio de hacer la revisión en un entorno grupal es que todos pueden beneficiarse de los comentarios, en lugar de solo la persona que escribió el código original. Es posible que necesite conseguir algunos voluntarios que se sientan cómodos al juzgar su código para comenzar, y asegúrese de mantener la cortesía.

Nunca me gustaron los términos programadores Junior y Senior. Por ejemplo, he estado programando durante un tiempo y, aunque tengo experiencia en algunas áreas, soy muy ecológico en otras. Por ejemplo, nos estamos mudando a WPF y aunque tengo toneladas de experiencia en aplicaciones de formularios de Windows, WPF todavía es nuevo y extraño para mí. Entonces, aunque soy un programador "senior", podrías contratar a alguien fuera de la calle con mucha menos experiencia 'total' y probablemente podrían programar una aplicación WPF mejor y más rápido que yo en este momento.

No quiero decir que no tenga mucha experiencia en diseño y arquitectura de aplicaciones que pueda aplicarse a la aplicación WPF, pero conozco mis límites.

Supongo que tienes que estar dispuesto a ser el mentor en algunos momentos y el mentoreado en otros.

Si tiene miembros del equipo que no tienen miedo de ser el mentor cuando tienen el conocimiento y un mentoreado en otros cuando lo necesitan, tendrá una experiencia fructífera.

Si puede fomentar ese tipo de entorno de desarrollo donde los desarrolladores son humildes y están abiertos a nuevas ideas y ayudan a los demás cuando sea necesario, las relaciones sempai-kohai saldrán de forma natural.

Forzar la tutoría probablemente creará un sistema de castas que los desarrolladores pueden resentir entre sí. Es mejor tratar a cada desarrollador por igual en el mismo nivel.

Esta industria es muy diferente. La senoridad no siempre es mejor.

A veces las personas mayores necesitan ser asesoradas por los jóvenes.

He estado en entornos que hacen las cosas en ambos sentidos.

El primer trabajo que tuve fuera de la escuela, me asignaron un mentor. No me gustó el chico, y ciertamente no estaba de acuerdo con él en todo. Me molestaba que me obligaran a trabajar con él, y estaba bastante seguro de que mi empleador había cometido un error, pero en retrospectiva aprendí mucho.

Avancemos unos años, y ahora estoy con una compañía que trata a los desarrolladores con una actitud de hombre por persona. Los desarrolladores están bajo plazos ajustados, y se otorgan pocos permisos para desarrolladores que pasan tiempo tomando a otros bajo sus alas para mostrarles las cuerdas. Creo que es una pena. Veo cómo los desarrolladores junior luchan con las mismas cosas que hice, pero sin un mentor que los ayude, les lleva mucho más tiempo.

He desarrollado una reputación como "el mentor" porque los nuevos empleados "parecen apreciar la ayuda que puedo brindarles". Por lo que puedo decir, esta es una forma elegante de recursos humanos de decir que estoy dispuesto a tolerar revisiones de productividad mediocres para poder hacer lo correcto, que es permitir a los desarrolladores junior hacer su trabajo de manera efectiva y mejorar rápidamente.

Creo que eso es lo que se merecen nuestros empleados junior, y con el beneficio de la retrospectiva y la experiencia, creo que la primera compañía para la que trabajé, y ese tipo que me guió, tenía mucho más de lo que pensé en ese momento.

Todo esto es el largo camino para decir que, si bien desearía que no tuvieras que asignar mentores, es probable que sea la única forma justa de difundir el trabajo. Si no lo hace, debe dar a las personas que lo hacen lo que les corresponde. No es un trabajo fácil; requiere habilidades interpersonales y de ingeniería; y lleva mucho tiempo.

Se debe esperar que los desarrolladores senior vayan más allá de la eliminación del código. Sin embargo, la dirección que toman no debería ser la misma para todos los desarrolladores senior.

Algunos son adecuados para la tutoría. Otros no lo están, y deberían perseguir alguna otra meta de alto nivel, ya sea planeando e implementando mejoras arquitectónicas, o evaluando nueva tecnología, o planeando y liderando mejoras de procesos (por ejemplo, integración continua, TDD, etc.)

Básicamente, un senior no debería ser solo alguien que ha estado cortando el código durante algunos años más que los juniors. Debe ser alguien que esté dispuesto y sea capaz de asumir responsabilidades adicionales que contribuyan al éxito del equipo. La tutoría de juniors es importante, pero no es lo único importante, y no es algo para lo que todos estén bien preparados.

Obligar a este tipo de tutoría es contraproducente porque los seres humanos se esfuerzan naturalmente contra las actividades, acciones y relaciones forzadas. Un mejor enfoque es recompensar a las personas que hacen una buena mentoría, logrando así que las personas quieran ser mentoras.

Por supuesto, esto plantea el problema de medir "bueno" en este contexto. Una solución imperfecta pero fácil de implementar podría ser hacer que los recién llegados después de un año (posiblemente de forma anónima) escriban los nombres de, por ejemplo, las tres principales personas que los ayudaron a integrarse en la empresa y / o la base de código. Después de eso, puede recompensar a las personas cuyos nombres se mencionan más. Sin embargo, las recompensas monetarias no funcionarán aquí. Es mejor encontrar algún tipo de recompensa social.

el equipo lidera la estructura, lo que lleva a revisiones de código debería hacer el truco

Tendría un miembro senior de su personal responsable de uno o más juniors. No creo que deba ser una ayuda espontánea, sino más bien un proceso formal; en el sentido de que el miembro superior será responsable de la calidad del trabajo producido por los recién llegados. Este enfoque tiene 2 beneficios (al menos): instruir a los seniors en los estilos de gestión y asegurarse de que los juniors produzcan un código de calidad.

En todas las cosas, la programación depende . Pero definitivamente quisiera que un desarrollador sénior asesore a nuevos empleados, ya sean jóvenes o no, para obtener la mejor capacitación para el trabajo en cuestión.

No, porque eso implicaría que el número de desarrolladores senior y junior sería el mismo todo el tiempo. Pude ver alentar a los desarrolladores senior que quieren ser mentores, pero forzar un emparejamiento podría ser una muy mala idea. La idea de apoyar las relaciones de mentoría es buena y no debe ser arrojada aquí.

Sin embargo, el estímulo artificial no es una mala idea aquí. Decirles a todos los desarrolladores junior y senior que van a ser aprendices y mentores sin importar lo que pueda ser un poco religioso y contraproducente con bastante rapidez.

Si hay un marco conocido dentro de la empresa sobre cómo manejar la tutoría, sería genial. Sin embargo, si eso no existe, entonces la clave se convierte en tener algunos tipos diferentes de momentos entre el mentor y el aprendiz:

1. Estado actual: ¿dónde están las cosas ahora? ¿Cuál es el desafío actual que el mentor puede brindar asistencia para resolver?
2. Estado futuro: ¿Qué se quiere: una pista, una solución, preguntas para hacer, a quién preguntar?
3. Retrospectiva: ¿qué funcionó y qué no funcionó al hacer cambios?
4. Cambios futuros: ¿qué se intentará en el futuro que funcione mejor que lo que se hizo anteriormente?

Al menos esos son estados que puedo ver y tener sentido desde mi punto de vista para adoptar un enfoque lógico de arriba hacia abajo. Otros pueden querer algo mucho más orgánico y de forma libre que también puede funcionar. La clave es tener una idea de cómo hacer que cada lado tenga algunas habilidades que deben perfeccionarse mediante la práctica de comunicarse en esta relación. Cada parte debería ganar algo de la relación y debería haber algunas reglas básicas comunes para tener este tipo de relación, ya que la retroalimentación es un gran problema aquí.

Cuánto tiempo se pasa en esto es una pregunta justa que, de manera realista, uno tiene que ver qué se está haciendo y en qué medida es aceptable pasar tiempo desarrollando habilidades y construyendo relaciones. Pude ver algunas parejas que desean pasar una hora a la semana, mientras que otras pueden querer un par de horas al día para cubrir esto. No olvide que puede haber otras interacciones en las que un senior y un junior pueden trabajar juntos, aunque no dentro de una relación de mentoría formal.

He visto un par de intentos diferentes en los sistemas de tutoría. Las que más me gustaron fueron aquellas en las que el desarrollador senior tenía un conjunto específico de tareas que realizaba para ayudar al desarrollador junior, lo que allanó el camino para la tutoría sin requerirlo. Por ejemplo, un revisor de códigos uno a uno de un desarrollador senior asignado durante los primeros seis meses podría ser muy útil y es probable que conduzca a la tutoría. Los que no me gustaron fueron los que se sentían como trabajo extra ocupado y que no parecían estar directamente relacionados con el trabajo que se estaba haciendo, por ejemplo, reunirse con su mentor asignado durante media hora cada semana. Esto fue especialmente molesto cuando los dos miembros de la relación de tutoría generalmente no interactuaban entre sí durante la semana y no tenían nada que ver con los proyectos del otro. Se sintió muy forzado y sensible en lugar de centrarse en crecer profesionalmente. Lo último que desea es que una relación de mentoría se sienta como una sesión de asesoramiento.

IME, no puede contar con el desarrollo de relaciones de mentoría, por lo que proporcionar un mentor potencial al emparejar un desarrollador senior y un desarrollador junior para un conjunto de actividades comerciales emparejadas normales (revisiones de código, depuración, programación de pares, etc.), al menos al menos Primero, es una gran idea. Idealmente, el miembro principal debería ser voluntario para el papel y debería ser capaz de percibir algún beneficio personal. En mi empresa actual, los desarrolladores senior son casi líderes para sus proyectos, y el beneficio es que están formando el equipo de su propio proyecto. En la otra compañía, los mentores a menudo investigaban la vía de gestión.

Creo que todas las empresas que contratan a desarrolladores jóvenes deberían tener algún tipo de programa de tutoría razonablemente eficaz. Pero no estoy seguro de que la posición predeterminada debería ser que todos los desarrolladores senior lo hagan por la sencilla razón de que muchos desarrolladores, independientemente de lo buenos que sean en el desarrollo, son pésimos en la tutoría. Va con el territorio por desgracia. Algunos de nosotros simplemente no somos grandes personas, si quieres.

Por otro lado, donde hay personas que son buenas en eso, deberían obtener reconocimiento por ello, y no marcas negras porque su producción de desarrollo real cae mientras explican un problema localizado simple relacionado con la implementación de IDE a algún novato que siempre ha usó NotePad y Javac, por ejemplo.

Esto requiere una gestión equilibrada. No estoy seguro de que sea común.

Para que cualquier tutoría funcione, es esencial que la gerencia reconozca que esto es importante y asigne tiempo para esto, ¡y lo aliente activamente!

Para cualquier persona 100% reservada con tareas, literalmente no hay tiempo para hacer o recibir tutoría, y no sucederá.

En general, las naves de mentores son un buen paso para la transición del liderazgo o gerente senior al equipo. Es más efectivo vincular la tutoría con el avance en un PDP (Plan de Desarrollo Personal) o cualquier plan de mérito que utilice su empresa. Relacionar su aumento salarial y el desarrollo profesional al menos en parte con su capacidad para transmitir conocimientos y preparar nuevos desarrolladores es clave para crear un personal de TI sólido que pueda resistir los cambios en la gestión y la rotación del personal. Proporcionar objetivos clave y trabajar con el personal para ayudarlos a mejorar es parte de ese crecimiento hacia el liderazgo. Para aquellos que piensan que no es justo vincular una evaluación senior con un desempeño junior que es parte del crecimiento. En la mayoría de los casos, no se trata de un recorte salarial, sino de un aumento reducido o un avance lento.

Cuando llegué al equipo por primera vez, tuve el propietario y un desarrollador líder que me dieron instrucciones. Podría preguntarle a cualquiera de ellos y ambos responderían. Sin embargo, fui lo suficientemente respetuoso como para no seguir molestándolos a menos que no pudiera resolverlo de manera oportuna.

Funcionó muy bien, pero de nuevo, probablemente necesites personas agradables con sentido del humor para que esto funcione.