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

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 👍

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

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

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.