¿Cuándo no ayuda a los programadores menos experimentados? [cerrado]

En uno de mis trabajos, estaba aprendiendo y enseñando (porque, por supuesto, no sé todo, pero sé más que algunos)

No cueste lo que cueste ponga sus manos sobre el teclado. Esto es frustrante tanto para ti como para la persona que estás enseñando. Incluso si les das instrucciones paso a paso, cuando pones las manos sobre el teclado es el equivalente a darles un código y decir "esto lo soluciona".

En lo que he aprendido:

• No escriba el código para ellos
• Trate de enseñar en su nivel (si ellos comprenden la sintaxis, no se lo expliquen. Esto los aburre; en lugar de eso, enseñe las clases / funciones utilizadas)
• No los ignore ni diga "descúbralo por su cuenta". Lo que obtendrás es que te lleguen más tarde, excepto ahora que las 3 líneas de código con las que tuvieron problemas, ahora son 50 líneas repartidas en 8 archivos que intentan solucionar el problema.
• Enséñales a aprender por su cuenta. Una de las mejores formas es decirles que usen stackoverflow. A veces, incluso sabiendo la respuesta, si me preguntaban. Yo diría "bueno, voy a hacer esta pregunta en stackoverflow". y les daría un enlace a la pregunta. Tome un descanso para tomar un café y observe un código diferente. Cuando regresaron preguntando "entonces, ¿cómo soluciono el problema?", Dígales que busquen su pregunta en SO (usando la URL que les dio). Descubrí que las masas suelen ser mejores maestras que yo.
• Cuando copian y pegan el código de Internet y preguntan por qué no funciona, pídales que expliquen qué hace cada línea. Si no pueden, entonces dígales que investiguen las funciones / clases utilizadas. Si es necesario, proporcione explicaciones para la clase y funciones
• Realice revisiones de código para asegurarse de que están resolviendo el problema, no solo de resolverlo para que aparezca más adelante.
• Sé amable. Cuando alguien está empezando en su código base sin documentación, no solo le pida que lea el código fuente. Proporcione un resumen de alto nivel de la función en cuestión. O, mejor aún, comience a escribir documentación :)
• Sé humilde. No BS sobre el problema. Si no lo sabes, dile que no y ayúdalos a buscarlo. Muchas veces, solo saber el dominio lo suficiente como para saber qué palabras clave buscar es suficiente ayuda para que las proporcione.

Método socrático, es decir, hacerles preguntas que los lleven a pensar en una dirección positiva

[esto es útil incluso cuando no sabes cuál es el problema, y mucho menos la solución]

He aprendido a ayudarlos a arquitectos y detenerme allí. Elija las herramientas adecuadas, elabore un diseño general para un problema complejo o dos, y déjelos ir. Si vuelven y piden consejo, dáselos en pequeños trozos. Si no lo hacen, déjalos ser.

Tienes toda la razón acerca de los "quemados y frustrados". Serán exactamente eso si usted realiza una microgestión o una minuciosa selección. Finalmente, ayuda mucho establecer una relación de trabajo amigable con sus compañeros de trabajo. El tiempo dedicado a ganar confianza y respeto mutuo se pagará por sí mismo 10 veces más.

Les ayudo cuando realmente necesito que las cosas se terminen rápidamente, cuando está claro que han chocado contra una pared de ladrillos, y cuando es claramente irrazonable esperar que lo descubran sin ayuda. Sin embargo, si no han dedicado tiempo a algo, es mejor que lo intenten primero.

En cuanto a tomar el "pez" en lugar de "enseñar a pescar", la mejor manera de hacerlo es no resolver los problemas de la gente por ellos . Dales ideas y déjalos correr con ellas. Si corren con él, y fallan, entonces ayúdales más. Si tienen éxito, aún mejor.

Si son un buen programador, deberían encontrar la manera de hacerlo por sí mismo. Ahora, en una situación en la que es casi imposible encontrar información o una solución a un problema dado, dar una mano está aparentemente dentro de la razón siempre y cuando usted la mantenga dentro de la razón. No les dé la respuesta a la cuchara.

Quizás, como ejemplo, tengo 18 años y he estado aprendiendo solo por años y he escrito algunas locuras, incluido mi propio compilador y soy autodidacta. Solo busco ayuda con cosas en las que realmente estoy atascado (como en que he estado buscando y experimentando durante al menos un día, pero en vano). También me gustaría ofrecer un contraejemplo: en una clase de programación, una vez, un estudiante me pidió que depurara un código que ni siquiera había compilado.

Esencialmente, un buen programador, incluso uno junior, debería poder experimentar e investigar soluciones para la mayoría de los problemas.

Seré un mentor, pero me iré si quieren que haga su trabajo por ellos. Por lo general, solo un consejo sobre cómo resolver un problema, o volver a redactar la descripción de la tarea puede ser de gran ayuda. Incluso simplemente diciéndoles las palabras que deben usar en google puede ser suficiente ayuda. 2 minutos máximo.

Recientemente comencé a utilizar la técnica de pomodoro pomodoro . Como resultado, si no puedo responder una pregunta sin romper mi línea de pensamiento en mi tarea actual, comencé a preguntar si puedo posponer una respuesta hasta el final del pomodoro, un promedio de alrededor de 15 minutos de retraso. Un efecto secundario interesante de esto que he descubierto es que cuando paso por su escritorio para responder a la pregunta, a menudo ya lo han resuelto por su cuenta. Si no lo han hecho, en ese momento estoy mucho más preparado para prestarles toda mi atención.

Esto no es la escuela. No es trampa si rápidamente proporciona un hecho que eventualmente podrían encontrar por su cuenta. Por el contrario, es lógico para los negocios ahorrarles tiempo y, según mi experiencia, las habilidades se agudizan muy poco por ensayo y error en comparación con un mentor que le da pequeños empujes frecuentes en la dirección correcta. Prefiero que aprendan 10 formas correctas de hacer las cosas con mi ayuda que 9 formas equivocadas y una correcta por su cuenta.

Si se puede buscar algo fácilmente, enséñeles cómo hacerlo. Por otro lado, si es algo que solo puede saber por experiencia, como qué archivos investigar para detectar ciertos síntomas de error, no veo absolutamente nada de malo en dar una respuesta inexplicable.

A la inversa, las cosas más subjetivas, como la orientación de la arquitectura, siempre deben ir acompañadas del razonamiento que las sustenta. Por un lado, el desarrollador junior ha pensado mucho más en profundidad sobre su tarea específica que usted. Hablarlo te asegura que no estás llegando a conclusiones. Por otro lado, les impide aplicar reglas a ciegas en situaciones futuras en las que podrían no aplicarse.

Solo puedo pensar en un caso en el que me negué totalmente a seguir ayudando a un compañero de trabajo, y fue después de pasar un par de horas explicando algo varias veces y repasando varios ejemplos, después de lo cual, literalmente, aún no sabía la siguiente afirmación. para escribir con algunos consejos muy importantes. En ese momento, tenía pocas esperanzas de mantener su trabajo sin un reaprendizaje serio de los fundamentos, y por supuesto que solo duró un par de meses.

Dejo de ayudarlos cuando vuelven con la misma pregunta por tercera vez.

Les digo que me encantaría ayudarles, pero solo si ellos se ayudan a sí mismos primero. Desde allí, o bien, van a buscar otro estanque para pescar comida gratis, en cuyo caso generalmente son despedidos poco después. O trabajan en ello y ganan el premio gordo cuando regresan por más ... ¡eso es más cosas que aprender en lugar de más de lo mismo!

Creo que el contexto importa.

Si estamos lidiando con un problema de soporte de producción crítico en el que el tiempo de respuesta es importante, entonces realmente proporcionaré mucha ayuda junto con mucha explicación para que puedan conocer el problema.

Si la fecha límite es menos sensible, la complejidad se convierte en el controlador. Por supuesto, puede ayudar mucho a los novatos simplemente asignándoles tareas apropiadas al nivel de habilidad, pero si es algo que se puede resolver a través de la investigación, entonces estoy de acuerdo con los otros carteles que guiarlos sin dar la respuesta exacta es un excelente enfoque. .

Si hacen preguntas que se contestan fácilmente al buscar en otra parte, entonces las guío a hacer su propio trabajo. En la misma línea, si hay un proceso o solución que es bastante rutinario y tiene poco valor para que sean esclavos de él, entonces es una lástima si no tienes un wiki a la mano para que lo revisen.

Cuando se trata de transferir el conocimiento del dominio que es personalizado para el negocio, entonces no compito las palabras. Léalo directamente lo antes posible. Los novatos necesitan eso para ayudar con todo lo que viene después. No existe tal cosa como ser educado sobre el negocio demasiado rápido o fácilmente. Una vez tuve un jefe que jugaba todo tipo de trucos durante una hora tratando de guiarme a una respuesta. Era nuevo, no sabía nada sobre la aplicación o el negocio todavía, y estaba lidiando con un problema de soporte de producción. Quería gritar: "¿Por qué estás & # @ $! Jugando # @ & (¡* $%! Juegos? ¡Los usuarios que intentan sacar las facturas están esperando una respuesta!"

Creo que lo primero que debes preguntarles antes de ayudarlos es ¿has investigado sobre esto? si es así, pregúntales qué han descubierto y apúntalos en la dirección correcta. Investigarlo a menudo es poco valioso, pero es una de las mejores prácticas que he aprendido. Encontrar información sobre lo que necesita le da el poder de aprender por sí mismo, y también dejará claro que primero tienen que intentarlo.

Si el problema es más complejo, trate de no decirles qué hacer sino de compartir algunas ideas, pregúnteles cómo creen que podrían abordar el problema.

Si no tienen una pista, intente dividirla a un nivel muy básico donde no regale todos los detalles, pero describa la solución lo suficiente para que lo intenten, hay herramientas muy útiles para esto como algorithms o diagramas de flujo .

En conclusión, intente guiarlos sin interferir con el proceso de aprendizaje, siempre ayudándolos hará que dependan de usted para cada tarea que luego se le asignen, que tomarán su tiempo y son contraproducentes. .

Evito ayudar en cosas simples como la sintaxis que deben saber, o si no saben que deberían poder entender por sí mismas. Si es algo más complejo, no me importa explicarlo una vez.

Cuando se trata de cosas como explicar el proceso, o los estándares de codificación de nuestra organización / proyectos, etc., utilizo la regla de las tres huelgas. Realmente creo que una persona es coja si tiene que explicárselo tres veces. De hecho, ese es también uno de los criterios en nuestra evaluación.

Mucho depende del aprendiz. Espero que ellos recojan algunas cosas por su cuenta. Si se les ocurre: "Me enfrenté a este problema, probé los métodos A, B y C pero no pude resolver el problema", los ayudaré. Si simplemente dicen "Im frente a este problema" y no han hecho nada, les pediré que vuelvan a los libros y busquen una solución.

Como programador novato (aproximadamente 9 meses en mi trabajo actual, en su mayoría utilizando Perl y SQL y con a) sin conocimiento de Perl yb) algunos meses de retoques con SQL antes de este trabajo), al hacer preguntas de programación, intente mostrar lo que he hecho hasta ahora, o en el caso de que algo no funcione (y sea difícil de depurar), donde creo que podría estar el error. Cuando es posible, he tratado de aprender a pescar.

Dejo de ayudar en las siguientes circunstancias:

• Si estoy acostumbrado a canalizar Google / Stack
• Si he proporcionado Documentación y comentarios adecuados. y son atajos al RTFM etapa
• Si son un sucio, sin comentarios, "voy a piratear esto ahora y vuelva a él más tarde "& & £ & gt ;! $

Si no proporcioné documentos adecuados, o si están trabajando con una herramienta / clase que he creado, entonces es mi responsabilidad ayudarlos