Diría que es esencial comprender cada detalle sobre por qué ocurrieron algunos errores y por qué ciertos cambios eliminaron esos errores, y también es común entre los desarrolladores hacer que el programa funcione a veces sin ¡realmente conociendo los detalles sobre por qué funcionó la solución!
El arte de cambiar las cosas hasta que desaparece un error, sin entender qué lo causó o por qué el cambio lo solucionó, a menudo se llama "programación de vudú" y no es un cumplido. Realmente no hay forma de que puedas estar seguro de que realmente hayas arreglado un error, en lugar de corregirlo parcialmente para el caso particular que estabas investigando, si no entiendes la causa.
En el peor de los casos, no has hecho nada, excepto mover el error: recuerdo desde el primer año de cómputo en la universidad, cuando muchos estudiantes estaban aprendiendo C e indicadores por primera vez, los errores de puntero a menudo dejaban de manifestarse cuando cambiaron las cosas al azar, porque los cambios reorganizarían las estructuras de datos en la memoria lo suficiente como para que el error del puntero se detuviera en un bit de memoria diferente. Obviamente eso no ha ayudado a en absoluto .
Pero habiendo dicho eso, las realidades comerciales de la programación son a menudo tales que satisfacer al cliente de que se solucione un error es más importante que satisfacerse a usted mismo. Nunca recomendaría que declararas algo fijo si no tenías ni idea lo que lo causó, pero si puedes ver que algún código fue problemático y lo reelaboró, incluso si "no estás al 100% seguro "cómo eso hizo que el error específico se manifestara, a veces solo tienes que pasar al siguiente error antes de que el cliente grite demasiado fuerte sobre tu lento progreso.