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

I am this way completely. If I don't fully understand all the details of something, I have no chance of remembering it. Elementary math classes were difficult in college because they infrequently included formal proofs, but as I progressed into more advanced courses I found I really loved math. The formal proofs made the difference. I need to be convinced that something is true; I can't simply take it at face value.

Ooh! Get an Arduino/electronics starter kit! You'll learn how computers worked in the 80s. Then you'll be able to move on up to say, Python in no time 👍

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.

I'm the same way. I can't just know how to do something, I need to know why I'm doing something.

I can't just blindly follow instructions or I'll never learn. I need to understand everything so that I can find more efficient ways to do the thing I need to do. This is a common frustration I have in the workplace.

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

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.

I recommend the book “Code: The Hidden Language of Computer Hardware and Software”. https://www.barnesandnoble.com/w/code-charles-petzold/1100324884?ean=9780137909100

There’s a second edition, I’m not sure how good it is, but the first edition is excellent and will make sure you understand every part of the computer.

I also recommend the course Nand2Tetris and its accompanying book The Elements of Computing Systems, where you will build an actual computer from the ground up with just code.

www.nand2tetris.org

https://www.barnesandnoble.com/w/the-elements-of-computing-systems-second-edition-noam-nisan/1136466530?ean=9780262539807

I'm sort of like this especially when it comes to math, but mostly because my memory is shit.

I can't just memorize a formula, I need to know how something works and then I can work out what i need to do. The "understanding" is what triggers the memory to stick, not the need to remember "you need to use x+y-65bm(y+ba)/gap+5-13 when you have a problem involving bears." I'll never just remember that. I basically always barely passed my math classes in highschool...

So I never studied science and never followed my passions and am now in a factory lol stupid memory...

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.

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 :)

I can relate. I have a natural aversion to "high level" languages that obfuscate a lot of the details from me.

I actually do know a lot about the low-level details of programming, how code interacts with hardware, etc. BUT - I didn't start with that. I first learned BASIC (indeed - in the '80s). Then Pascal, then C. THEN I learned about assembly, computer architecture, etc.

Does knowing those low-level details make me a better programmer? Probably - but they're certainly not necessary to get started or to even be effective. And if I started with them I may not have gone into programming.

I've learned to how to convince myself that "I will simply accept this as it is for now (and that's okay) but I will let myself dive deep on it later". A bit of a bargain to give me permission to "cheat" for the time-being. It's helped when learning new frameworks which can be very complicated. And starting top-down can give you a better appreciation for the details underneath.

In programming you do not need to know the inner workings in order to use something, in fact most people use abstraction to make a project more manageable and modular.

Also don't learn anything before you start a project because it's too boring. I always start a project and learn things I need to learn along the way

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'm like that and one of my friends as well. We're both not diagnosed but strongly suspecting AD(H)D, and I'm also diagnosed with autism.

I can't count the times I started trying to learn programming and ended up quitting for that very reason - but every time I did I knew a little bit more. So I just tried to learn my way and next time I wouldn't need to look up asuch and got a little farther. But I also have the luck of having programmer friends who don't mind trying to answer my sometimes very unusual questions, and over the several attempts I've learned enough to be able to work in test automation.

If you have patient and encouraging people around you you'll eventually get there :) don't go for ui at first, look for console programs so you can get to things like conditions and loops quickly. That's where the meat is for me.

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 don't know if it applies to people with adhd, but there is this theory that people with autism have weak central coherence. That is, they have a tough time dealing with broad strokes and assembling context into a comprehensive picture of reality. This manifests in simple things like preferring instructions like "buy one dozen eggs" over "buy some eggs", to more complicated things like understanding that someone is joking when there's a thunderstorm out and they say "nice weather". Oftentimes, people with autism are very detail oriented, and uncomfortable with missing puzzle pieces.

For me, this reveals itself very similarly to what you describe. If I want to center a div, there's a good chance I'll be looking up how css works, then at the eBNF form of css, and then probably the Chomsky hierarchy, and then probably set theory bc the formal language theory book I picked up uses it, at which point I'll probably be lead to learn about Russel's paradox and so on. It's debilitating.

I don't know if you're autistic (although there is like a 60% comorbidity with adhd), but I do know that folks with autism experience the same thing. I don't have a solution for you, but you could potentially find tips on dealing with this on forums for autistic people.

I've wanted to learn the guitar my entire life, but I can't just start slow and easy with some chords, I keep going all in trying to learn classical guitar simultaneously with music theory because chords seem too simple and I hate myself... I didn't mention the research phase where I learned all about the origin of the instrument and its importance through history.

It is ok to "cheat" even if you know the "real" way it should be done. It took me ages to come to grips with this but you can get over it too. There are still hobbies I won't pursue because of this mentality though like drawing.

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.

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 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.

I never understood how programmers had no clue how the hardware worked. How can you write high performance code without understanding memory access optimization and opcode pipelines? Why even attempting rewriting old Fortran array code to C and then to C++ without understanding that Fortran array code fits cache lines just fine, while your newly shiny refactored code doesn't, so now you wonder why your code performance sucks?

Oh yeah, I totally get that.

When I'm doing something for fun, I'm far more interested in the process than the end result, so I'll do everything from first principles. And probably never finish before I move on to something else. But that's fine.

If it's something I need to get done, on the other hand, then by the time I've started we're probably already into crisis mode, and so getting it complete as quickly as possible becomes the goal. Then I'm all for finding whatever shortcuts I can.

Fortunately I've explored a enough topics (particularly in programming) for fun by now that I have enough background knowledge to be good at it for a career. Experience does build up, and even if you're jumping around all over the place, eventually you'll start to see the bigger picture.

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.