¿Cómo puedo animar a las personas a leer los mensajes de error? [duplicar]

No ayudes de inmediato. Haga que el colega junior espere al menos 15 minutos, después de uno o dos de estos ciclos de 15 minutos, él / ella comenzará a analizar el problema por su cuenta. Simplemente no digas directamente "espera 15 minutos", usa algo como "Estoy ocupado, déjame terminar x, luego te ayudo".

Si lo ayudas de inmediato, este es el camino más corto que tiene para la solución del problema, por supuesto que usará este camino. Pero, en cambio, si usted lo dice, lo ayudaré y resolveré el problema, pero, por favor, espere 15 minutos antes de poder ayudarlo. Durante este tiempo, él mirará la pantalla para ver qué podría probar en este "tiempo de espera". , probablemente verá los mensajes de error por su cuenta. :-)

Si no comienzan a buscar el error por sí mismos, puede decir que la persona carece de iniciativa o experiencia. Si el problema es la iniciativa, es difícil de resolver. Si es experiencia después de uno o dos análisis juntos, deberían comenzar a averiguarlo.

Encuentro a los desarrolladores senior culpables del mismo error; por eso creo que esto es una señal de estar abrumado en lugar de "no importa".

Mi reacción es siempre la misma: cuando escucho "no funciona", pregunto: "¿Qué mensaje de error aparece?" (y trato de ser educado).

La respuesta luego me dirá si la persona necesita desahogarse antes de que pueda comenzar a pensar otra vez: si alguien está en este estado, ningún consejo en el mundo funcionará ya que simplemente no pueden escuchar; Calmarlos, primero.

Si solo eran perezosos, insista en que vuelvan y lean el mensaje de error. Si crees que deberían saber qué significa / cómo resolverlo, comienza a hacer preguntas: como "¿Qué crees que podría causar esto?", "¿Qué significa foo aquí?", "¿Qué cambiaste justo antes del error ocurrido? " Hacer preguntas es una buena manera de poner en marcha el cerebro de otra persona, ya que la mayoría de las personas tratan de ser útiles cuando se les pregunta. Así que esto se recibe como un apoyo positivo, aunque en realidad no los "ayudes".

Si ellos simplemente no entienden lo que está sucediendo, siéntese con ellos y explíqueles cómo corregir el error. Tiendo a que ellos mismos corrijan el error por dos razones:

1. El cerebro recuerda mejor las cosas que has hecho tú mismo (en lugar de ver a otra persona hacerlo).
2. Si no entienden la explicación, eso les da la oportunidad de preguntar.

Si yo mismo corrigiera el error, siempre existe el peligro de que ahora tengan un código de trabajo pero no sepan por qué.

PS: Esto va a todos los desarrolladores senior: escribe mejores mensajes de error. Un buen mensaje de error explica cómo solucionar un problema ; una mala es una variante de "Hubo errores".

Entonces, en lugar de File not found , digamos File ...path... not found . En lugar de Glabarfel couldn't be initialized , diga Glabarfel wasn't initialited properly; missing Foo. See http://.../docs/setup/glabarfel/foo.html for details.

Esta es una pregunta de modificación de comportamiento, pero debe abordarse en un entorno de equipo de desarrollo. ¿Sus desarrolladores junior tienen que hacer soporte o algún tipo de corrección de errores? Pregúnteles cómo se sienten cuando alguien simplemente les dice: "Recibí un error" sin otra información. Podemos evitar todos los insultos que probablemente ocurran cuando tienen que tratar con usuarios estúpidos.

Cuando te digan que hay un error, pregúntales cuál fue el mensaje de error. Pueden incluirlo en un correo electrónico o registrarse en algún tipo de rastreador de errores / información del equipo / sistema wiki. De esta manera, otros pueden buscar una solución para este mensaje de error cuando vuelva a ocurrir.

Necesitas ser diligente. Pregunta por el mensaje. Pregunte si buscaron el mensaje en busca de soluciones anteriores (igual que le dice a sus usuarios). No quiere que lo perciban como que no ayuda, por lo que si se trata de un problema nuevo, debe tratar de solucionarlo de la manera más conveniente posible. Felicite a quienes contribuyan a la documentación de estos errores.

Como equipo, debe abordar los problemas de las interrupciones. Puede parecer más conveniente simplemente preguntarle a la persona que conoce la respuesta de inmediato, pero al retirarse de su código puede crear otros problemas y retrasos a largo plazo. Los desarrolladores junior necesitan aprender esto.

"Cuando falla la compilación" ... en tales casos, me dirijo a ellos como para ayudarles con un error nuevo, difícil, de experiencia requiere ... Pasaría por los pasos básicos de "Muéstrame" y luego leería el mensaje de error que mostraba el compilador, y si realmente se tratara de un mensaje de "haz lo que el error dice", pondría lo mejor de mí "eres un cara del niño, pregúntales por qué no pudieron haberlo leído ellos mismos, y luego alejarse.

Realmente no puedes no ayudarlos cuando te lo piden, pero puedes ser despectivo si pierden el tiempo.

  

1. Les digo que revisen los mensajes de error cuando falla la compilación.
  
2. Me siento y reviso los mensajes de error con ellos.
  
3. Cuando me piden ayuda, les pregunto si han verificado el error o no.
  

Por lo que estás escribiendo, parece que tus juniors o no entienden realmente tus soluciones y no pueden aplicarlas en otras situaciones que no son 100% idénticas a las anteriores, o han aprendido que eres la hada de la solución mágica y esa molestia es la forma más rápida de solucionar sus problemas.

Afortunadamente, la mayoría de las veces, puede ayudarlos de la misma manera: diríjalos con preguntas analíticas en lugar de con su conocimiento.

• "¿Cuál parece ser el problema?" A veces, solo intentar explicarte el problema hará que la respuesta se dé cuenta. Por lo menos, le permite ver su marco de referencia y, para no ser subestimado en importancia, le dice cómo perciben el problema.

• "¿Qué dice la documentación / Google / lo que diga?" Supongamos que al menos trataron de averiguarlo. Si no lo han hecho, quédate con ellos un rato mientras lo buscan (no te adelantes y dales la solución). Si la solución está ahí, dale un adiós amistoso, feliz de ayudar y vuelve al trabajo. Si no, o si no es realmente aplicable, pase al siguiente bit:

• Guíelos hasta encontrar el problema subyacente. ¿La función ya está definida? Pregúnteles dónde más se puede definir la función; señalarlos a funciones de búsqueda si es necesario. ¿Variable indefinida? Pídales que verifiquen dónde lo definieron y analicen la ortografía. ¿Inesperado if ? ¿Es esto realmente el comienzo de una nueva declaración? ¿Terminaste el anterior?

  (No es necesario ser pedante o seguir las Enseñanzas 660 de Aristóteles en ellos, pero sí es necesario guiarlos a través de los pasos necesarios para encontrar una solución, y debe ser abierto y paciente).

Una vez que haya encontrado la fuente del problema, es de esperar que la solución sea trivial; si no lo es, entonces su desarrollador junior tiene un problema real que no es obvio para los no iniciados.

¿Pero todo esto no toma más tiempo que tu enfoque anterior? Probablemente. Los principios del enfoque son triples:

1. Usted enseña a las personas a encontrar una solución a sus problemas. En particular, ese análisis de los comentarios de sus acciones (mensajes de error) es crucial para encontrar una solución. Esto no solo mejorará su independencia, sino también su pensamiento analítico, que en última instancia los hará sentir más cómodos. entorno automatizado o, al menos, menos probable que obstaculice activamente a otros.

2. No asumes que son idiotas o perezosos; esto hará que sea más probable que te escuchen y sigan tu ejemplo. Enfoque su problema como un problema real y fidedigno que debe resolverse. Quién sabe, tal vez sea.

3. Usted ayuda a establecer un estándar cultural (de equipo) que está bien pedir ayuda para resolver problemas que no puede resolver, que está dispuesto a entrenar y ayudarles a encontrar y aprender una solución, pero también que no eres el hada de la solución mágica de la oficina, y que tiene que haber al menos un esfuerzo simbólico de su lado. Tratar de descubrir la información que tiene, como un mensaje de error, es el paso más básico.