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

¿Crees que es una buena idea cuando un programador junior necesita ayuda para participar y tratar de educarlos? ¿O ignorarán todos los consejos de "enseñar a pescar" que les das y se concentrarán en el "pez" que acabas de traerles? ¿Les dejas siempre resolver las cosas por su cuenta, sabiendo que los errores son la mejor manera de aprender? ¿O tienes miedo de que se quemen y se frustren tanto que pierdan el deseo de acelerar?

¿Cuándo eliges cuándo ayudar a alguien más joven que tú y cuándo retroceder y dejar que aprendan a través de sus errores?

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

No cueste a toda costa las manos sobre el teclado. Esto es frustrante tanto para usted como para la persona a la que está enseñando. Incluso si les da instrucciones paso a paso, cuando coloca las manos en el teclado es el equivalente a darles un código y decir "esto lo arregla".

En lo que he aprendido:

• No escriba el código para ellos
• Trate de enseñar en su nivel (si entienden la sintaxis, no se los explique. Esto simplemente los aburrirá; en su lugar, enseñe las clases / funciones utilizadas)
• No los ignore ni diga "descifre por su cuenta". Con lo que terminarás es que llegarán a ti más tarde, excepto que ahora 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éñeles a aprender por su cuenta. Una de las mejores formas es decirles que usen stackoverflow. A veces, incluso sabiendo la respuesta, si me preguntan. Yo diría "bueno, voy a hacer esta pregunta en stackoverflow". y les daría un enlace a la pregunta. Tómate un café y mira un código diferente. Cuando volvieron a preguntar "entonces, ¿cómo puedo solucionar ese problema", solo diles que busquen su pregunta en SO (usando la URL que les diste). He descubierto que las masas suelen ser mejores maestros que yo.
• Cuando copian y pegan código de Internet y preguntan por qué no funciona, pídales que expliquen qué hace cada línea. Si no pueden, dígales que investiguen las funciones / clases utilizadas. Si es necesario, proporcione explicaciones para la clase y las funciones.
• Realice revisiones de código para asegurarse de que están resolviendo el problema, no solo de solucionarlo para que aparezca más tarde.
• Se bueno. Cuando alguien recién está comenzando en su base de código sin documentación, no solo le diga que lea el código fuente. Proporcione un resumen resumido de alto nivel de la función en cuestión. O, mejor aún, comience a escribir documentación :)
• Se humilde. No BS sobre el problema. Si no lo sabe, diga que no y ayúdelos a buscarlo. Muchas veces, solo conocer el dominio lo suficiente como para saber qué palabras clave buscar es suficiente ayuda para que les des.

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

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

He aprendido a ayudarlos a diseñar y parar allí. Elija las herramientas correctas, elabore un diseño general para un problema complejo o dos, y déjelos actuar. Si regresan y piden consejo, déselos en trozos pequeños. Si no lo hacen, déjalos ser.

Tienes toda la razón sobre el "quemado y frustrado". Serán exactamente eso si micro-manejas o picas. Finalmente, ayuda mucho establecer una relación de trabajo amigable con sus compañeros de trabajo. El tiempo dedicado a ganar la confianza y el respeto mutuo se amortizará 10 veces.

Los ayudo cuando realmente necesito que las cosas se terminen rápidamente, cuando está claro que han golpeado una pared de ladrillos y cuando es claramente irracional esperar que lo resuelvan sin ayuda. Sin embargo, si no han dedicado tiempo a algo, entonces es mejor que lo intenten primero.

En cuanto a tomar el "pez" en lugar de la "enseñanza para pescar", la mejor manera de hacerlo es no resolver los problemas de las personas para ellos . Dales ideas y déjalas correr con eso. Si corren con él y fallan, entonces ayúdenlos más. Si tienen éxito, aún mejor.

Si son buenos programadores, deberían encontrar la manera de hacerlo por sí mismos. Ahora, en una situación en la que es casi imposible encontrar información o una solución a un problema dado, echar una mano parece estar dentro de lo razonable siempre y cuando se mantenga dentro de lo razonable. No les des la cuchara con la respuesta.

Quizás como ejemplo tengo 18 años y he estado aprendiendo durante años por mi cuenta y he escrito algunas cosas locas, incluido mi propio compilador y soy autodidacta. Solo busco ayuda con cosas en las que realmente estoy atascado (ya que he estado buscando y experimentando durante al menos un día, pero fue 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 ser capaz de experimentar e investigar soluciones para la mayoría de los problemas.

Seré mentor pero me iré si quieren que haga su trabajo por ellos. Por lo general, solo algunos consejos sobre cómo resolver un problema o volver a redactar la descripción de la tarea pueden ser muy útiles. Incluso decirles las palabras que deberían usar en Google puede ser suficiente ayuda. 2 minutos máximo

Recientemente comencé a usar la técnica de pomodoro . Como resultado, si no puedo responder una pregunta sin romper mi línea de pensamiento en mi tarea actual, he comenzado a preguntar si puedo posponer una respuesta hasta el final del pomodoro, un retraso promedio de alrededor de 15 minutos. Un efecto secundario interesante de esto que he descubierto es que cuando paso por su escritorio para responder 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 escuela. No es trampa si proporciona rápidamente un hecho que eventualmente podrían encontrar por su cuenta. Por el contrario, tiene sentido desde el punto de vista comercial ahorrarles tiempo, y en mi experiencia las habilidades se agudizan muy poco por prueba y error en comparación con un mentor que le da pequeños y frecuentes empujones en la dirección correcta. Prefiero que aprendan 10 formas correctas de hacer las cosas con mi ayuda que 9 formas incorrectas y una sola por su cuenta.

Si algo se puede buscar 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.

Por el contrario, cosas más subjetivas como la guía de arquitectura siempre deben ir acompañadas del razonamiento detrás de esto. Por un lado, el desarrollador junior ha pensado mucho más en profundidad sobre su tarea específica que usted. Hablarlo se asegura de no estar sacando conclusiones. Por otro lado, les impide aplicar reglas ciegamente a situaciones futuras en las que podrían no aplicarse.

Solo puedo pensar en un caso en el que me negué directamente a seguir ayudando a un compañero de trabajo, y fue después de pasar un par de horas explicando algo varias veces y analizando varios ejemplos, después de lo cual, literalmente, todavía no sabía la siguiente declaración para escribir con Algunos consejos muy importantes. En ese momento, tenía pocas esperanzas de mantener su trabajo sin volver a aprender los fundamentos, y de seguro solo duró un par de meses.

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

Les digo que estaría encantado de ayudarlos, pero solo si se ayudan a sí mismos primero. A partir de ahí, van a buscar otro estanque para pescar comida gratis, en cuyo caso generalmente los despiden poco después. O trabajan en ello y ganan el premio gordo cuando regresan por más ... ¡eso es más cosas para aprender en lugar de más de lo mismo!

Creo que el contexto importa.

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

Si la fecha límite es menos sensible, entonces la complejidad se convierte en el conductor. Por supuesto, puede ayudar mucho a los novatos simplemente asignando tareas apropiadas para el 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 de que guiarlos sin dar la respuesta exacta es un gran enfoque .

Si hacen preguntas que son fáciles de responder buscando en otro lado, entonces los dirijo a hacer su propio trabajo. En ese sentido, si hay un proceso o solución que es bastante rutinario y tiene poco valor hacerlos esclavos, entonces, qué vergüenza si no tienes un wiki a mano para que lo revisen.

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

Creo que lo primero que tienes que preguntarles antes de ayudarlos es ¿has investigado sobre esto? en caso afirmativo, pregúnteles qué han descubierto y apúntelos en la dirección correcta. Investigarlo a menudo es infravalorado, 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, también dejará en claro que primero deben intentarlo.

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

Si no tienen idea, intente desglosarlo a un nivel muy básico en el que no revele todos los detalles, pero describa la solución lo suficiente como para que lo intenten, existen herramientas muy útiles para esto, como algoritmos o diagramas de flujo .

En conclusión, trate de guiarlos sin interferir con el proceso de aprendizaje, siempre ayudándolos hará que dependan de usted para cada tarea que se les asigne, eso tomará su tiempo y es contraproducente.

Evito ayudar en cosas simples como la sintaxis que deberían saber; o si no saben, deberían poder entender por sí mismos. 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 los tres avisos. Realmente creo que una persona es coja si tiene que explicarle las cosas tres veces. De hecho, ese es también uno de los criterios en nuestra evaluación.

Mucho depende del alumno. Espero que 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 se les ocurre "Estoy enfrentando este problema" y no han hecho nada, les pediré que vuelvan a los libros y busquen una solución.

Como programador novato (unos 9 meses en mi trabajo actual usando principalmente Perl y SQL y con a) sin conocimiento de Perl yb) unos meses de retoques con SQL antes de este trabajo), cuando hago preguntas de programación, trato de 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 el error podría estar. Cuando es posible, he tratado de aprender a pescar.

Dejo de ayudar en las siguientes circunstancias:

• Si estoy siendo utilizado para canalizar Google / Stack
• Si he proporcionado documentación y comentarios adecuados, y están atajando la etapa RTFM
• Si están sucios, sin comentarios, "¡Hackearé esto ahora y volveré a hacerlo más tarde" & & £>! PS

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