How common is it to need to know the absolute inner workings of something in order to do it?

I'm this way 100%. Feels like I'll be able to do it better and be less distracted by questions if I get to know something from the ground up, and just doing it a certain way because everyone agrees it works that way is never satisfying/I never feel like I can trust that completely.

Yea, can strongly relate. Hindered me a lot during my school years. I just couldn't do anything without knowing the reasoning behind it. In the way I function, any amount of work is dictated by a need, and if the need -or the rationale, is never presented to me, then I fail to tackle the problem. I love solving problems, but they need to be real, applied.

That's why I never used Unity for anything but rather just started with raylib. And then went to pure Vulkan.

Can you trick yourself into doing it the other way?

'GUI building blocks let me see the shape of the finished code. Once I know the shape, I can work backwards to finer detail.'

'Making music with the simplified tools lets me get the tune out so I don't forget it, then I can replace parts with the proper instruments and tools.'

I'm still trying to get my head around coding, but I use the music trick to learn songs. I play them one note at a time on either bass or guitar to figure out the tune, then play them properly with chords or figure out the bass line once I know where the song's going :)

Yeah. I have found the prototype perspective can help. The idea being that this first attempt is part of the learning exercise and you will redo it "properly" the second time. It helps prevent building a emotional mountain of requirements to get started that only exist in my head. It's kind of an mindset of knowing you will mess up the first one and that is OK because it is expected and a required part of the process.

I have this problem. You are being a perfectionist. Some advice I have gotten that helps is trying to make something intentionally bad. It think it was from Simone Giertz's TED talk. She said that trying to make Shitty Robots was easier because she couldn't mess up, they were already bad.

https://youtu.be/GEIvFfeSjuE behind the scenes, idk where the full vid is.

Another thing to remember with programming is that bad, but working code will always be better than no code.

I definitely relate. I also kind of have this obsession with using only open source software which also tends to hinder my creativity because some of the open source alternatives to things have steep learning curves.

Anyway, I think this is one of the things that makes me great at math but terrible at learning math. If something is complicated, I have to chew it down to the bone and then rebuild back to the original complicated thing.

As such, I’m really good at doing all sorts of math and even have some of my own weird identities/constants memorized, but it takes me a lot of time and effort to learn new math from a textbook instead of (re)inventing it myself.

I can certainly relate. I remember disassembling mechanical things as a young kid and it always bugged me that there was this digital level of design that I couldn't physically investigate intuitively. Then once I started programming I remembered initially being disappointed by the concept of scripting/dynamic language. It felt like if I tried to imagine the twinkle of the 1s and 0s as they moved around the machine the patterns would more divorced from the physical hardware. Probably not an accurate or valid abstraction but it is the model that I mentally interact with at a high concept level. I've grown more partial to dynamic languages since then but only as I've come to terms with the underlying mechanisms. ADHD needs solid walls to bounce off of and having a interpreter that exists in this virtual environment doesn't naturally capture my trust. So in my hubris I doubt the veracity of the tools and learn that it requires a context change to dig in to the lower level of the issue which is demoralizing as an ADHD person. And now because I want to mitigate future context change I spend a lot of time forecasting potential context changes and quickly get overwhelmed by my own efforts.

Extremely valuable to me.

I wasn't much of a cook until I started watching Good Eats, and learning the actual science behind shit. Now if I am unable to find X, I know I can substitute a bunch of other things because I know why you're using X in the first place. Most of the time, it's not taste that governs what goes into a dish, but the chemical reactions being created.

Knowing how a game works helps determine what is and isn't a bug, as well as finding bugs or exploits for various reasons. Maybe you're making a game and wanna crush them. Maybe you're a speed runner and you can do some frame perfect bullshit because you know how the game does a specific action and it can be manipulated to your favor.

I've struggled with this mentally, especially when I first was learning how to code. Eventually I realized while it's great to know the ins and outs, you can allow yourself to only worry about what you need to know to get your code running (and that's okay).

Write a script to go a thing, then learn about how to automate that with a cronjob, then learn about coding in the cloud. If you start too big you might get overwhelmed

So, for this, the easiest way I've found is to look at it in the following sort of way:

Using the example of coding, you can already USE software, think of that like knowing how to DRIVE a car. Start with learning how to REPAIR the car (GUI building block code).

Then learn how to MOD the car with a kit (high-level object-oriented, TYPED code with an IDE or editor that does stuff like auto complete, syntax highlighting, and has add-ins that assist in getting the typed code to completion).

Then learn how to create your own car mods from "scratch" (get to the point where you don't necessarily NEED all those editor widgets to help code)

Then learn how the car functions at a base level and how all the various chemicals, heat, and aerodynamics, pistons, filters, etc interact to make the car function (interacting with and modifying OS-level code/low-level languages with things like hardware access instead of applications that run on the OS)

THEN worry about the various chemicals themselves create the energy needed to generate power for the car (firmware on top of circuits and chips like the CPU/GPU/PSU, storage controller boards, audio chips, and motherboard/bios)

THEN worry about the actual molecular interactions occurring in the batteries or fuel at the atomic level (binary electrical functions of the parts themselves, where 1's and 0's are just current on or current off).

Just because the binary is there at every stage doesn't always mean that understanding how the bonds between the "atoms" operate is going to make you a better programmer UNTIL you understand what you're trying to get those atoms to do and why.

I would like to know but I don’t consider it vital, my spouse is autistic and he considers it to be vital to how he functions.

I can fix programs without knowing their use if that counts.

I always have the feeling that there is "no time" to start in the beginning. "I SHOULD know that already", "I'll pick it up on the way", "It'd take too long to start there" and other excuses.

But experience tells a different story: When I dare to start at the very beginning, no matter how small, it often lead to great success, while jumping into the middle never got me anywhere.

In your concrete situation with programming: After getting a grasp with BASIC and Pascal in the late 80s, I wanted to learn Assembly and really understand it. And so I did. And it was not wasted time. (Except for macro assembler, aimed at really using it for big projects; could have skipped through that and just used the old MS-DOS debug tool.) Some of my most fond memories with the PC were not fancy UIs I developed, but how I wrote a 10 byte long program directly into the MBR of a floppy disc and booted from it to execute it, without loading any OS.

Later with C, C++, Java, I also focussed on the core language and libraries, only then moved on to UIs and big frameworks. And it did me a great service once more. I notice people around me who skipped through the Java fundamentals in less than a week and got right into a big framework - even 10 years after, they have odd misconceptions and knowledge gaps that hinder their development.

But I also respect that there are different approaches that work better for other people.

You could also go a middle way, for example: Set a weekday that is for "core research". But don't try to "wing it", won't work. It needs to be an automated reminder on your calendar, a differently marked column on your habit tracker, whatever you use.