Recientemente, mi gerente me ha asignado un papel más importante para ayudar a dar forma a algunos de los nuevos desarrolladores del equipo. Tengo mucha experiencia con el código base con el que están tratando, por lo que a veces simplemente me deja asignar problemas.
La mayoría de las veces hay algunos problemas de diversa complejidad. No tengo ningún problema en dar los que son extremadamente simples, pero para los que requieren comprender más partes del código base, generalmente agregaré algunas ideas en el ticket para darles una mejor comprensión de lo que podría estar sucediendo.
Recientemente, por algunos problemas, algunos de los nuevos desarrolladores naturalmente harán muchas preguntas. Tengo la mala costumbre de decirles inevitablemente cuál debería ser la solución.
¿Cuál es un buen equilibrio para esto? Si bien quiero que resuelvan el problema por su cuenta, también me siento raro al ocultarles información. Al mismo tiempo, creo que es valioso dejar que lo averigüen por sí mismos, incluso si eso significa que pueden tardar un tiempo en comprender lo que está sucediendo. Además, ¿cuál es la forma correcta de responder a alguien que hace una pregunta muy básica que creo que debería poder resolver por sí mismo?
¿Tienes documentación, o eres tú los docs? Si es lo último, muy mal, se referirán a los documentos tanto como puedan y tendrá que responder. Por supuesto, podría comenzar a escribir todo lo que sabe y luego remitirlos a eso para que con el tiempo sea menos necesario.
En el otro caso, remítalos a los documentos y remítalos a las áreas de código que necesitan buscar. Si agrega algún conocimiento de arquitectura que ayudará, pero luego, una vez que les haya mostrado dónde buscar, déjelos. lo.
Otra cosa que ayuda son las revisiones de código. Dígales que presenten la solución que consideren mejor, pero que se la traigan para que la verifique antes de que comience la codificación. Eso les ayuda a ganar confianza en que lo han resuelto correctamente antes de hacer un lío. Cuando mejoren en su conocimiento del sistema, cambie el enfoque de su revisión de código al código real después de codificar la solución, y aproveche la oportunidad para explicar las áreas en las que se equivocaron o (más probablemente) se podría hacer mejor o más de acuerdo con la base de código. .
Con el tiempo se volverán más seguros y autónomos.
Parece que tienes tendencias naturales de educador. Pero también parece que eres un poco nuevo en aplicarlos o te falta el estímulo para apegarte a tus principios. Ser educador (o líder de equipo, que tiene muchas similitudes) requiere persistencia de su parte para no dar respuestas. Hay varios enfoques educativos positivos que puede utilizar:
-Actuar como caja de resonancia para aquellos que están expresando problemas. En este caso, es posible que ni siquiera necesite reaccionar activamente, sino simplemente recibir pasivamente.
-Discute el problema que te presentan tus compañeros. Ya sea pretendiendo buscar una aclaración al respecto, o confirmando genuinamente cuál es el problema. A través de esto indirectamente puede surgir la respuesta.
-Cuando se le plantee una pregunta, mencione que "no está seguro" y que tal vez quieran probar o verificar tal o cual ubicación, luego discúlpese de la situación y dígales que regresará en breve; cuando regreses pregúntales si llegaron a algún lado con su búsqueda.
-Punto final--y este es oro. Casi tengo ganas de no revelarlo aquí. Vocalice sus propios procesos de pensamiento internos cuando esté en el trabajo. Tus colegas escucharán lo que dices y aprenderán a ser más independientes.
Lilienthal
Kilisi
kevin xu