When Stack Overflow and Google do not help, you start doing it yourself. You use tools like a debugger. If the tools do not help, you can look for other tools. If you cannot find them, you can develop your own. You can look at your code, the code of your operating system, and every library you use. You can trace and observe every instruction a CPU performs.
In my experience there are only two ways to really learn about programming: teaching and debugging.
I'll add curiosity to stubbornness too. I very much have to understand how a system is actually working before I'm willing to call it quits and call something successfully debugged. I've definitely worked with folks in the past who don't have that drive; they're more concerned about making it work than understanding why it does/doesn't work. My revelation last night was "deep in this (internal) library, a URL is being manipulated using a badly conceived regex, and that's why this URL is getting mangled".
The curiosity to understand it on a deep level pretty much defined my academic career too. I'd already been programming (in some capacity) for about a decade by time I turned 18 and finished high school. Computer Science was a pretty obvious career path. But I ended up doing an EE/CS dual major, entirely because I wanted to understand the pieces below software as well. A few years after undergrad, I realized that a lot of people struggled to debug complex "cloud" systems, and went back to do an M.Sc. to study the problem more carefully.
(And, per cup-of-tea's comment, I spent a fair bit of time during my M.Sc. teaching as well, including taking on a Spring & Summer session 200-level CS course as a sessional lecturer)
Where do I sign? When I get really stuck on a bug it's sometimes taken weeks to solve in a never ending game of software dominoes. In very rare cases it ended up being a bug that you could only solve with a soldering iron and some creative rewiring of interrupts.
Bugs can be crazily obscured. To the point where you wish you hadn't started but the sunk cost of time invested is such that there is no way back either. This is one of the reasons I was so happy to switch to Unix (and later Linux), the fact that in most cases the program crashes with a core file and access to post mortem debugging (and in many cases a nice stacktrace of how you got there) made short work of most of the bugs. Of course that means you now only have the hardest categories to deal with.
"All causes shall give way. I am in code
Stepped in so far that, should I wade no more,
Returning were as tedious as go o'er."
My substitute is to externalize my brain: Write things down. Journaling. Blogging.
Debuggers are still useful but I don't actually recall the last time when I hit a bug that required interactive debugging.
Microcontrollers: As a side rant, I'm perpetually grouchy with the fact that Arduinos don't have debugger support. I was using AVRs well before the Arduino was a thing (still have my STK500 kicking around...) and I feel like it's a pretty big lost opportunity for hobbyists to not be able to do a deep dive into what is actually going on for when they want to "level up" their MCU skills. Printfs over serial are great, but they often dork with the timing enough to change the character of bugs; JTAG debugging does too, but you can often insert breakpoints with surgical precision to see what's happening without breaking the timing of what you're trying to debug.