¿Cómo corregir a un junior, pero animarlo a pensar por sí mismo? [cerrado]

Respuesta corta:

Involúcralos (pon el rompecabezas en su mente), dales poder (confía en sus respuestas).

  

Es la pregunta que nos impulsa! - Matriz.

En general, en mis observaciones, los jóvenes tienen su propio mundo: su propia visión limitada de cómo piensan y en alguna parte su propio entusiasmo / favoritos / opiniones sobre las cosas.

No hay nada de malo en decirles de frente que estás equivocado, pero lo mejor es que les haces pensar. ¿Por qué? ¿Hay otras maneras? ¿Hay mejores maneras de hacer lo mismo? Una de las anécdotas que siempre uso es: "¡Dame tres soluciones (a este problema)!"

Cuando piensan en estas soluciones, comienzan a darse cuenta de muchos problemas. Les lleva algo de tiempo invertir, pero con el tiempo tienden a visualizar las limitaciones y las deficiencias de su pensamiento. Comienzan a ver eso más como "¡No lo pensé!" , que es mucho mejor que ir a casa con la sensación de que "¡Estaba equivocado!" o incluso peor "Se me dijo / se demostró que estaba equivocado, incluso cuando tenía puntos de vista válidos" .

En general, los niños muy pequeños tienden a ser más adeptos a los problemas técnicos (¡por ejemplo, qué patrón de diseño funciona mejor!) sobre los problemas del proceso , pero con el tiempo Cuando los entrenas, funciona.

  

Sin embargo, rara vez si no están de acuerdo o preguntan por qué. Y últimamente he estado   notando signos más evidentes de que están ciegamente de acuerdo con mi   Declaraciones y no formando opiniones propias.

Esto generalmente es un resultado que hace toma sus sugerencias pero luego las invalida y tampoco están convencidas acerca de sus puntos de vista; ¡Sólo porque eres mayor están evitando una pelea!

Lo mejor que aprendí de uno de mis jefes anteriores: él les pedirá a los miembros del equipo que debatan primero (se sienten bastante iguales aquí), y espero que después de que todos los argumentos se agoten, entraría en la sala con solo una pregunta: "¿Cuáles fueron los puntos de desacuerdo?" - El punto es que a la gente siempre le gusta participar en debates y discusiones, pero si sus (válidos) puntos no se ponen en acción la próxima vez que sientan que no vale la pena participar en una discusión.

No solo en software, sino que en todas partes, en última instancia, solo los compañeros con más poderes podrán atreverse a responder, y mucho menos a cuestionar el sistema.

Si quieres que tus juniors piensen por sí mismos, no los corrijas: haz que se corrijan ellos mismos .

En lugar de decirles qué piensa que está mal con respecto a su solución, hágales las preguntas pertinentes al respecto. En su ejemplo, puede preguntarles qué necesitaría saber alguien que use el método de extensión para crear el lambda. Siga haciendo preguntas como esta hasta que ellos sugieran que es un problema. De esa manera, sabrá que han entendido por qué su solución podría ser un problema y, además, es más probable que aprendan de ella. Si simplemente les dice que su solución es incorrecta, eso es un juicio externo y se ignora fácilmente. Si se dan cuenta por sí mismos (con un poco de ayuda), se darán cuenta de lo bien fundamentado que es y serán mucho más propensos a aprender de su error.

Además, esto le da a sus juniors la oportunidad de defender su diseño, tal vez hayan pensado en el problema y tengan una buena justificación que aborde su inquietud, lo que significa que no es necesario que haga nada. de corrección. Eso reduce cualquier percepción (sin embargo no intencional) de que usted está gobernando por mandato ejecutivo.

Ya que tiene múltiples desarrolladores junior, haga revisiones de código como grupo no 1 uno 1.

Abra preguntando al grupo "¿De qué otra manera se podría resolver el problema?", y permita que los otros desarrolladores junior sugieran primero sus implementaciones. Solo agregue su implementación después de que los otros miembros del equipo hayan hablado y si ninguno ha sugerido algo similar a su idea.

Luego, tenga una discusión de mesa redonda sobre las ventajas y desventajas relativas de diferentes implementaciones con la intención de guiar a los desarrolladores junior a elegir la mejor implementación sin que se le diga qué es.

Como creador de confianza para los desarrolladores junior, podrías comenzar con algunos casos en los que eligieron la mejor opción y hacer de tu alternativa un hombre de paja con una falla semi-obvia y dirigir la discusión hacia por qué la implementación original es mejor.

Cuando empecé a trabajar en un trabajo de programación, hice exactamente lo mismo que describiste: cuando me informaron sobre algo que podría estar haciendo, siempre estaría de acuerdo. Fue principalmente porque no tenía suficiente experiencia para decir lo contrario.

Lo que me dio la capacidad de discutir realmente metodologías e ideas fue aprender de la experiencia y leer sobre diferentes enfoques y nuevas tecnologías. Para que su equipo piense por sí mismos, necesitan saber realmente qué problemas pueden surgir de cosas como el código "demasiado complejo y complicado", y la única forma real de que lo descubran es a través de la experiencia.

Una buena forma de facilitar el pensamiento individual es hacer que consulten sitios web de programación como Stack Overflow o Programmers SE. Sé que me ayudaron a aprender sobre las diferentes técnicas que existían y me permitieron tener discusiones con los miembros principales del equipo, en lugar de estar ciegamente de acuerdo con ellos.

El punto es que, sin experiencia, las sugerencias de los miembros senior siempre les sonarán acertadas.

La interacción de tu publicación demuestra un principio clave para enseñar casi cualquier cosa: pídeles que te expliquen lo que creen que dijiste y escucha atentamente la respuesta: te dirá exactamente lo que debe ser. corregido.

He robado descaradamente copiado este truco de mi tutor de matemáticas hace unos 25 años, y no me ha fallado desde entonces. Lo utilicé en clase durante mi breve etapa como asistente de enseñanza, en el trabajo cuando hablaba sobre diseño de software y con mis ocho años cuando hablaba sobre sus tareas escolares.

Por supuesto, no siempre puede ser franco al pedirles que repitan lo que acaba de decir, por lo que necesita ajustar su estrategia. Por ejemplo, aquí es cómo volvería a redactar su declaración de seguimiento del OP como una pregunta de "sondeo":

  

Me gusta tu idea de crear un método de extensión, pero no me gusta cómo pasaste un gran lambda complejo como parámetro. ¿Ves cómo este complejo lambda obliga a otros a saber demasiado ciertas cosas sobre la implementación del método?

Es imposible responder correctamente a esta pregunta sin comprender el problema que intenta resaltar. Descubrí que terminar mis explicaciones con una pregunta que requiere un análisis de lo que acabo de decir acelera el proceso de aprendizaje y me da información de que necesito hacer correcciones.

Por lo general, cuando las personas no dicen lo que quieres, significa que debes trabajar en tu escucha. Escuchar significa escuchar las razones de su diseño antes de emitir un juicio. Significa no solo decirles que está bien disentir, sino probarlo considerando honestamente lo que tienen que decir, y no solo corregirlos. Busque las cosas buenas acerca de su solución y modifique su solución para incorporar esas cosas.

También necesitas liderar con el ejemplo. No me refiero a escribir código súper impresionante, me refiero a pedirles su opinión sobre sus propios diseños. No espere las revisiones de código después del hecho, sino trabaje en conjunto a lo largo del camino. Diga cosas como: "Mi interfaz parece demasiado compleja, pero no estoy segura de cuál es la mejor manera de simplificarla". Y déles tiempo para que respondan sin desviarse primero de sus propias ideas.

Cuando tuve que lidiar con esto, he dicho (honestamente) cosas como:

  

Sabes, esa es una solución realmente creativa en la que nunca hubiera pensado. ¿Cómo se puede escalar? / ¿Cree que podría haber un enfoque que sea conceptualmente más simple para hacer que el desarrollo sea más rápido o más fácil de mantener? / Desafortunadamente, no creo que se ajuste realmente al resto de la arquitectura del proyecto. La configuración parece?

Por lo general, esto ha sido suficiente para señalar a las personas en una nueva dirección.

La responsabilidad es una cosa que puede ayudarlos.

He liderado un equipo o dos en el pasado y una de las cosas que hizo brillar a los juniors fue la carga de la responsabilidad personal. Cuando uno se da cuenta de que sus acciones pueden implicarlo en un punto, por lo general se compromete a hacer un pequeño esfuerzo de sí mismo en lo que hace. No mencionar que cuando sienten su trabajo, los buenos resultados son mucho más satisfactorios.

No me preocuparía demasiado el hecho de que te sigan ciegamente, esto es lo que deberían hacer como juniors. La cuestión es que es probable que no entiendan las verdaderas razones de los elementos que aborda en las revisiones de código hasta que se hayan ido a trabajar en otro lugar que tenga desarrolladores de software terribles, administración terrible y código terrible.

En ese momento, habrán aprendido buenas prácticas por costumbre y tendrán que vivir de acuerdo con los errores de codificación y diseño que otros cometen, y están obligados a hacer que ahora tengan que trabajar en un software mal diseñado e implementado.

Esto será una eventual inevitabilidad en algún momento de sus carreras. Les está haciendo un gran servicio al acostumbrarlos a los buenos estándares y prácticas de codificación. Desafortunadamente, la mayoría de nosotros tuvimos que aprender de la manera más difícil.

Según el ejemplo dado, diría que seguir tus comentarios con preguntas probablemente sea la mejor manera de hacerlo. Si hace una pregunta junto con sus comentarios, no los deja simplemente de acuerdo o en desacuerdo, al menos tienen que pensar en cómo pueden implementar algo.

por ejemplo "Me gusta tu idea de crear un método de extensión, pero no me gusta cómo pasaste un gran lambda complejo como parámetro. La lambda obliga a otros a saber demasiado sobre la implementación del método. ¿Puedes pensar en una mejor manera de implementar? este método de extensión que no expone tanta información? "

Esto les permite ver las fallas en lo que están desarrollando y al mismo tiempo les da la oportunidad de resolver el problema que introdujeron en la aplicación.