Ask HN: How much does your debugging process rely on learning how a thing works?
I've been a developer for a several years and something has bothered me for much of that time. When I encounter an error or bug, I am always tempted to try to understand something about what is going wrong in order to then be able to fix it.
For example, let's say the problem is that the language server of the ruby plugin for VSCode kept crashing and reporting a path issue. I would be tempted to:
Step 1: Look at any settings options that are obviously related to paths of that plugin. Check for a quick fix there.
Step 2: Understand how VSCode passes the path and working directory to that process. Make some notes in a notepad as I do this. Write automated tests if practicable.
Step 3: Continue expanding the map of my understanding from there, filling in my mental model, and testing hypothesis until I find the problem.
However, I have memories of people telling me to "stop trying to understand the universe" in response to questions--or to stop trying to look under the hood during troubleshooting. This keeps leading me to think there is some other technique of troubleshooting where you don't try to learn pieces of how something works. Yet when I try to do that, then 15% of the time I get lucky but 85% of the time I end up lost.
I'd like to know: What is your experience?
How much do your debugging techniques rely on learning pieces of how something is supposed to work?