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

Soy el líder de un pequeño equipo donde todos tienen menos de un año de experiencia en desarrollo de software. De ninguna manera me llamaría un gurú del software, pero he aprendido algunas cosas en los pocos años que llevo escribiendo software.

Cuando hacemos revisiones de código, enseño y corrijo bastante. Diré cosas como "Esto es demasiado complejo y complicado, y he aquí por qué" o "¿Qué piensas acerca de mover este método a una clase separada?" Tengo mucho cuidado al comunicar que si tienen preguntas u opiniones discrepantes, está bien y tenemos que discutir. Cada vez que corrijo a alguien, pregunto "¿Qué piensas?" o algo similar.

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

Necesito un equipo que pueda aprender a hacer las cosas de manera autónoma, no solo seguir las instrucciones. ¿Cómo se corrige a un desarrollador junior, pero aún lo alienta a pensar por sí mismo?

Editar: Aquí hay un ejemplo de uno de estos signos obvios de que no están formando sus propias opiniones:

Yo: Me gusta tu idea de crear un método de extensión, pero no me gusta cómo pasaste un lambda complejo grande como parámetro. La lambda obliga a otros a saber demasiado sobre la implementación del método.

Junior (después de entenderme mal): Sí, estoy totalmente de acuerdo. No debemos usar métodos de extensión aquí porque obligan a otros desarrolladores a saber demasiado sobre la implementación.

Hubo un malentendido, y eso se ha solucionado. ¡Pero ni siquiera había una ONZA de lógica en su declaración! Pensó que estaba regurgitando mi lógica hacia mí, pensando que tendría sentido cuando realmente no tenía idea de por qué lo decía.

Respuesta corta:

Involucrarlos (poner el rompecabezas en su mente), capacitarlos (confiar 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 malo en decirles de frente que estás equivocado, pero lo mejor es que les hagas pensar. ¿Por qué? ¿Hay otras maneras? ¿Hay mejores formas 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 inversión de tiempo, 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é!" lo cual es mucho mejor que ir a casa con la sensación de que "¡Me equivoqué!" o peor aún "Me dijeron / demostré que estaba equivocado incluso cuando tenía puntos de vista válidos" .

En general, los niños muy pequeños tenderán a ser más expertos en cuestiones técnicas (¡como qué patrón de diseño funciona mejor!) En relación con los problemas del proceso , pero con el tiempo cuando los entrena, funciona.

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

En general, esto es un resultado que le hace llevar a sus sugerencias, pero después de hacer caso omiso de ellos y ellos están igualmente convencidos acerca de sus puntos de vista; ¡solo porque eres mayor están evitando una pelea!

Lo mejor que aprendí de uno de mis jefes pasados: pedirá a los miembros del equipo que debatan primero (se sienten bastante iguales aquí) y, con suerte, después de agotar todos los argumentos, entraría en la sala con una sola 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 puntos (válidos) no se toman en cuenta la próxima vez, sienten que no vale la pena participar en la discusión.

No solo en el software, sino en todas partes, en última instancia, solo los compañeros de equipo más capacitados se atreverán a responder y mucho menos 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 lo que cree que está mal acerca de su solución, hágales preguntas pertinentes al respecto. En su ejemplo, podría preguntarles qué necesitaría saber alguien que usa el método de extensión para crear la lambda. Siga haciendo preguntas como esta hasta que sugieran que es un problema. De esa manera, usted sabe 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 fácilmente ignorado. Si se dan cuenta por sí mismos (con un poco de ayuda), se darán cuenta de lo bien fundamentado que está 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 preocupación, lo que significa que no es necesario que corrija. Eso reduce cualquier percepción (aunque involuntaria) de que estás gobernando por mandato ejecutivo.

Como tiene varios desarrolladores junior, realice revisiones de código como grupo, no 1 uno 1.

Abra preguntando al grupo "¿De qué otra manera podría resolverse 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 mesa redonda sobre las ventajas y desventajas relativas de las diferentes implementaciones con la intención de guiar a los desarrolladores junior a elegir la mejor implementación sin que se les diga cuál es.

Como generador de confianza para los desarrolladores junior, puedes comenzar con algunos casos en los que eligieron lo que crees que es la mejor opción y convertir tu alternativa en un hombre de paja que tiene un defecto semi obvio y dirigir la discusión hacia por qué la implementación original es la mejor.

Cuando comencé a trabajar en un trabajo de programación, hice exactamente lo mismo que describiste: cuando me dijeron 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 debatir sobre metodologías e ideas fue aprender de la experiencia, así como leer sobre diferentes enfoques y nuevas tecnologías. Para que su equipo piense por sí mismo, necesitan saber realmente qué problemas pueden surgir de cosas como el código "demasiado complejo y complicado", y la única forma real que descubrirán es a través de la experiencia.

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

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

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

He robado descaradamente que copié este truco de mi tutor de matemáticas hace unos 25 años, y no me ha fallado desde entonces. Lo usé en clase durante mi breve período como asistente de enseñanza, en el trabajo cuando hablaba sobre diseño de software, y con mi hija de 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 debe ajustar su estrategia. Por ejemplo, así es como volvería a redactar su declaración de seguimiento del OP como una pregunta "inquisitiva":

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

Esta pregunta es imposible de responder correctamente sin comprender el problema que está tratando de 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 retroalimentación de que necesito hacer correcciones.

Por lo general, cuando la gente no dice lo que quieres, significa que debes trabajar para escuchar. 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 de su solución y modifique su solución para incorporar esas cosas.

También debes 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, pero trabajen juntos todo el tiempo. Diga cosas como: "Mi interfaz parece demasiado compleja, pero no estoy seguro de la mejor manera de simplificarla". Y deles tiempo para responder sin sesgarlos a sus propias ideas primero.

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

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

Esto generalmente ha sido suficiente para dirigir 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 hicieron 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, generalmente se compromete un poquito más de sí mismo en lo que hace. Sin 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 comprendan las verdaderas razones de los elementos que aborda en las revisiones de código hasta que se hayan ido y trabajen en otro lugar que tenga desarrolladores de software terribles, administración terrible y código terrible.

Para entonces, habrán aprendido las buenas prácticas por costumbre y tendrán que vivir a través de los errores de codificación y diseño que otros cometen y están obligados a hacer que ahora tengan que trabajar en 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. Lamentablemente, la mayoría de nosotros tuvimos que aprender por las malas.

Basado en el ejemplo dado, diría que seguir sus comentarios con preguntas probablemente sea la mejor opción. Si hace una pregunta junto con sus comentarios, no los deja simplemente de acuerdo o en desacuerdo, al menos tienen que pensar 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 una gran lambda compleja como parámetro. La lambda obliga a otros a saber demasiado acerca de 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 al mismo tiempo que les da la oportunidad de resolver el problema que introdujeron en la aplicación.