Si bien no puedo enumerar todos los escollos, a menudo, formular una pregunta y encuadrarla en un problema autónomo a menudo requiere tanto trabajo que para cuando la has preparado lo suficiente, has respondido tu propia pregunta en más tiempo de lo que hubiera tomado de otra manera.
Experimento lo mismo para> 75% de las preguntas que publico.
Sin embargo, ese no es un argumento para no molestarse en hacerlo. Esto es efectivamente la depuración del pato de goma. Está encontrando respuestas a preguntas que cree que podrían surgir en respuesta a su pregunta; lo que significa que está pensando en el problema desde los puntos de vista de diferentes personas; lo que significa que está pensando en el problema desde todas las direcciones posibles; cuál es la mejor manera de encontrar la falla.
En el mejor de los casos, ha demostrado de manera concluyente que claramente no puede pensar en la respuesta aquí. En el "peor", terminas respondiendo tu propia pregunta. Tenga en cuenta las citas, porque esto no es malo en absoluto. Tal vez fue un poco ineficiente, pero resolver el problema lentamente es mejor que decidir rápidamente no abordar el problema . Tendrás más rapidez para resolver el problema eventualmente.
Caso en punto:
Cuando era un desarrollador incipiente, me ocupé muchas veces de la página de errores ASP.Net . Necesitaba buscar el mensaje en Google para descubrir qué estaba mal. Pueden pasar varias horas antes de obtener la solución correcta. Básicamente cometí todos los errores en el libro y posteriormente tuve que lidiar con las consecuencias de tener que depurar los problemas.
Ahora, cuando aparece un error, ya conozco a los "sospechosos habituales" de lo que podría estar causando el problema. Mi lista mental de "sospechosos habituales" se basa efectivamente en los problemas con los que he tenido más problemas durante mi carrera. Sin haber hecho el trabajo de pierna de horas de Google en tiempo ineficiente, nunca hubiera hecho esta lista mental . Pero ahora que tengo esa lista mental, soy considerablemente más rápido en la resolución de problemas.
Además, si bien no puedo identificarlo, la capacidad de respuesta de la conversación libre no puede igualarse con ninguna forma de discusión textual en Internet que se me ocurra.
Estoy un poco en desacuerdo aquí. Tienes razón en que la comunicación por Internet responde menos, pero estás equivocado (en mi opinión) de que esto es malo para ti.
Como desarrollador solitario, dependerá de la depuración del pato de goma. El ingrediente clave para que RDD funcione es que anticipa las preguntas que el pato de goma pueda tener para usted. Obviamente, no puedes confiar en lo que dice realmente el pato de goma.
Cuando se trata de sistemas de mensajería lenta (publicación en StackOverflow o comunicación por escrito), tiene el incentivo inherente de asegurarse de hacerlo bien la primera vez. Porque la necesidad de corregir un error será un proceso lento y arduo.
En comparación, considere que los sistemas de mensajería rápida (conversación, mensajería instantánea), puede corregir algo inmediatamente . La capacidad de corregir rápidamente algo hace que las personas tengan menos incentivos para asegurarse de que sea correcto.
Cuatro casos en punto:
- Cuando estoy haciendo mi propia lista de análisis / tareas personales como desarrollador, sigo usando lápiz y papel. Me di cuenta de que paso por alto las suposiciones y falsedades cuando escribo mis notas, porque mi mente piensa que "puedo arreglar esto fácilmente más tarde". Sin embargo, tener que corregir algo que ha escrito en papel es molesto, necesita tachar las cosas y escribir entre líneas, y el documento se ve mucho peor cuando tiene garabatos. Escribir en papel me hace comprobar los hechos antes de comprometerme a escribirlo. Esto capta muchos malentendidos antes, incluso antes de que escriba un código que produzca errores.
- Mi abuela era secretaria (edad de la máquina de escribir). Hacer un error tipográfico en un documento formal significaba tener que volver a escribir toda la página. Mi tía es secretaria (edad del procesador de textos). Puede confiar en un corrector ortográfico automático, y los errores se pueden solucionar fácilmente y con un mínimo esfuerzo. Como era de esperar, mi abuela comete considerablemente menos errores de escritura y ortografía en comparación con mi tía.
- Los videojuegos solían imprimirse en cartuchos. Arreglar un error después del lanzamiento era casi imposible. Debería reimprimir todos los cartuchos, distribuirlos a todos los proveedores y esperar que los vendedores puedan ponerse en contacto de alguna manera con los clientes que ya compraron el juego. Costaría toneladas de dinero (el doble del costo de producción física) y aún no llegaría a algunos clientes. Ahora, en la era de los parches de Internet, los desarrolladores de juegos han demostrado una inversión mucho menor en probar sus juegos para que puedan evitar los errores del día de lanzamiento, porque es mucho más fácil simplemente enviar una solución a cada cliente directamente. El impacto de cometer un error se minimiza a un punto en el que es mejor solucionar un puñado de problemas después del hecho, en comparación con tener que probar todas las posibles errores que pueden ocurrir
- Solía vivir en un departamento del tercer piso, sin ascensor, y a menudo tenía que estacionar una o dos calles de mi edificio. Casi nunca olvido tomar algo de mi auto. Ahora vivo en una casa con mi auto justo a mi lado en el camino de entrada. Me olvido de sacar cosas de mi auto todo el tiempo .
La idea subyacente aquí es que un sistema de intercambio difícil incentiva a las personas a realizar intercambios correctos y verificados . La severidad del castigo (= proceso de corrección difícil) te enseña a no cometer errores.
Además, ocultar detalles para hacer una pregunta bien definida elimina la posibilidad de que alguien descubra problemas en los que no había pensado.
Cuando crea un MCVE , no debe crearlo y publicarlo en la pregunta. Primero debe hacerlo usted mismo , para poder aislar el problema. Y luego, cuando crees que el problema ya no se puede reducir, y aún no ves la causa; entonces tiene una pregunta válida para StackOverflow.
Caso en punto:
Siempre tengo un segundo Visual Studio ejecutándose con una aplicación de consola simple llamada Sandbox. Cada vez que me encuentro con un problema técnico, copio el código ofensivo en el sandbox y empiezo a jugar con él.
- ¿Qué sucede cuando cambio esta configuración?
- ¿Puedo reproducir el problema si acorto el código?
- ¿Qué ajustes hacen posible / imposible reproducir el problema?
En el 90% de los casos, encuentro la causa del problema porque la caja de arena me ayudó a mirar el código ofensivo sin distraerme con el contexto circundante (o, por ejemplo, cualquier incertidumbre sobre los valores que vienen para diferentes partes del código.
En el otro 10% de los casos, me queda el código mínimo para reproducir el problema, que sirve como un fragmento de ejemplo perfecto para publicar en StackOverflow.
Por último, pero no menos importante, no quiero publicar todo mi proyecto para que el mundo lo vea por el resto de la eternidad, por razones obvias.
Cuando ya tiene su MCVE, no debería tener mucha información personal (o de la empresa) en él. Si lo hace, dado que el código es mínimo, es fácil cambiar el nombre de las cosas a un ejemplo más básico de foo / bar / baz.