I’ve never been diagnosed with anything, but I strongly suspect I’ve got ADHD, so perhaps at least a similar head space as where you’re coming from. My main drives have often been solving problems, troubleshooting, creativity, variability from day.
There are options for programming that aren’t web pages. If you find a company that makes a software application rather than a website or a web service, there would be easier to find options there. Several things in private sector as well as in government if you’re close enough to a government site for that to be an option.
How are you with hardware? You could do stuff a bit closer to hardware potentially, like firmware development. Also an option could be QA for a company that makes hardware. I spent almost 7 years in “Operations” at a company that made hardware and software. I helped write functional tests that tested new hardware as it came off the assembly line, I inspected returned hardware to identify the failure (or if it was user error). I was a little linux sysadmin and managed my own VLAN off the main corporate network. The task needed had TONS of variability, and lots of problem solving, which very much helped me last as long in that job as I did. I can do hyperfocus on things I enjoy, but stuff I don’t enjoy is incredibly difficult to even get started in. Doing the “same thing” day after day gets old and becomes difficult. But if I’m doing one thing half of one day and then switching after lunch to something else, then spending a couple days fiddling with a functional test, then finish off the week by troubleshooting returned equipment. That kept me occupied and engaged for years! I don’t know that I would do as well in pure QA, but a smaller company where it required wearing multiple “hats” in just the one position offered the variability that kept me engaged.
I finally left there for better pay doing embedded firmware development for a primarily hardware company in the IT space. I enjoyed that a lot, but they didn’t quite come up to the amount I asked for, and had to leave to better support my family. So now I’m doing a bit of government contracting type stuff. But I wouldn’t have been able to get this particular position without all the prior software experience I had. They’re currently open for people with less experience now though, so it would be an easier time to get on board at many places.
So you could also consider things that have the ability to be programmer adjacent. They have programming bits, but it might not be the sole focus of the position. IT, Sysadmin, Tech Support, QA, Engineering, just to name a few potential options.
I can do short bursts of web backend stuff, but web service and DB stuff just wears me out faster than almost anything else I’ve tried so far. I’ve never made a “portfolio” myself, but I also have been avoiding the web sector of programming, which is where that seems more beneficial. So it might just be that you need to shift directions out of web services and web sites for a bit to see if you have any better luck?
Hopefully this helps a bit with ideas at least!
Ah sorry, I didn’t so much mean to push for switching entirely from developing software to designing hardware. I was trying to suggest aiming for developing software for low level hardware, like embedded development. If you’re comfortable with C#, it likely will be simpler to at least start reading C++. I went in the opposite direction there myself though.
I started learning programming by playing around with TI-Basic on Texas Instruments graphing calculators. Then I learned Z80 Assembly to get around a common bug with hitting left and up at the same time in writing games on the calculators. Then I got a different calculator that had a Motorola 68000 or something CPU in it instead of a Z80, so I attempted to learn that assembly, but noped out of it and learned C instead. Then naturally progressed into C++ before I ever took a programming course, which ended up being on Visual Basic.
It only took me a mere 9.5 years to graduate with my four year bachelors degree, so I started in tech support with no degree, then moved into Operations with no degree as an internal promotion. I’d been working in Operations helping with testing for years before I finally finished and got my degree, then just kept working there for several years more. So I think I get the self taught part pretty well at least. All of the things my degree tried to teach me, I had already learned either on my own directly, or by being pushed there for work.
I’m unfamiliar with that ISTQB certification, but if it is that expensive, they very well may be willing to pay for you to take the certification if you ask about it. Especially if they’re having trouble finding people to hire.
I guess just to try and describe my own experience with “testing”, although largely focused on testing hardware. The developer/engineer provided information on what the thing was supposed to do and how it should act. Sometimes they even had documentation instead of just a verbal discussion and a whiteboard. They would often provide a software tool or API to get into some portion of the hardware and allow access to various things to verify whether they were working. This often involved physically connecting various components to the device and trying to send data across. So there was a lot of send this thing, then try to read it back and see if it came through the same as a basic test that everything was connected. Then drivers/firmware would get installed/updated and we’d try some higher level functional usage of the device as best we were able. Depending on the purpose of the hardware, this wasn’t always possible to test in actuality, so a lot of the time this would be running more things in a loopback mode that the drivers supported, even by customers in the field. We used Linux, bash, perl, python, and various other things to try and automate as much of this procedure as possible for the hardware. By the time we were done automating, testing most of the hardware was as simple as install it in the test fixture and connect it according to a diagram, then turn on the test fixture. The fixture would identify what was installed, load the correct test, and report whether the results were nominal. If they were not, it would at least outline the step that failed so the test operator knew what to inspect if possible.
As for more direct me testing, that would be the returned field failures. Much of our hardware ran in a regular PC, so there was a lot of regular PC troubleshooting steps to reproduce/verify a failure. Then I eventually learned soldering and was taught some PCB/hardware stuff to do deeper dives on the boards, but that was all taught/learned on the job.
I basically got the operations position because I had shown I was good at troubleshooting and problem solving in general, and that I was capable of learning a system enough to be considered the local “expert” on it. Then I was taught or learned anything else I needed to know after I got the position.
So, hopefully you haven’t given up too much yet, and perhaps you can try out applying for some positions where you don’t quite meet all the “requirements” for it. Then just describe situations that show your general capabilities, and that you can learn what they need after you get onboard. Hopefully your luck will turn soon and you can get on into something somewhere.