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

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.

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.

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 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 can fix programs without knowing their use if that counts.

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

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.

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.

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

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