>I get code challenges from employers that are supposed to take around X hours, yet I know that they'll take me multiple(s) of X to do well.
Yeah. Me to. I mean, employers don't give me 'build an app' challenges because I'm a sysadmin, not a programmer, but I'd have that trouble if I tried for a dev job, even though I know the languages and concepts involved. I have a really hard time finishing large and complex programming projects. The thing was? I found I was able to get things working better than most of my compatriots. I mean, part of that is I'm pretty good at reading code
I'm worlds better at reading code than at writing. I remember as a kid at my first programming job, I wrote a small patch to apache; this was in the late '90s, back when traversing a list of a million VirtualHost entries every time your webserver got a hit was a significant overhead. The first thing I did was that I read the apache docs. Turns out they have this "dynamically configured name-based virtual hosting" module NameVirtualHost: - it builds the DocumentRoot from parts of the domain.
The problem was that at the time it parsed the domain on the '.' separators; you could specify domain componets starting at the begining or the end. If every domain is unique, that's fine, www.bob.com and bob.com have different directories. but the boss wanted www.something to be the same as something. And I couldn't just take the last and second to last, because we had both .com and .co.uk customers.
Now, I could have just symlinked /var/www/www.bob.com to /var/www/bob.com and have been done with it, but for some reason that wasn't an acceptable solution. I don't remember why. Anyhow, I went into the mod_vhost_alias source file, and added a new token... this was the whole domain, but with the www stripped off, so it would always go to /var/www/bob.com even if the user asked for www.bob.com.
Our webservers became massively faster, almost instantly.
But the point? Oh yeah, I spent maybe an hour figuring out where to insert my three lines of code, then the better part of a day actually writing the code. which is probably the opposite of how it would have gone for someone who was a programmer, and not a sysadmin.
But yeah, one day of work and our website went from 'dog slow' to 'reasonable' with no hardware outlay. I did something similar to our pop3 sharding redirector; it was using a directory with several million files in it to look up who was on what server. I loaded the data into mysql; again, like five lines of C and pop3 logins went from 30 seconds of waiting down to under 1 second, with no hardware outlays.
I guess my point here is that there are niches for programmers who are slow, or who can read code but can't write complex and large things.
I'm a SysAdmin, and my job is to understand a large and complex system that someone else wrote; to understand it well enough that I can fix it when it breaks. As I become more senior, my job more and more is helping set up the network and operating system side of a large application. It's a valuable niche, but there are some downsides. Generally speaking, as a SysAdmin, you have to carry a pager. As you become more senior, that is less true, but if your underlings can't figure it out and you were unreachable? Yeah, it's going to be bad for you.
Still, the pay is good and as long as you answer your pager, the hours are usually very flexible.
I'm not suggesting you set out to be a SysAdmin. I didn't set out to be a SysAdmin; it just turned out that I was way better at understanding and fixing existing systems; at gluing together building blocks built by others than I was at programming large and complex systems from scratch, so I naturally moved out of the application programmer role and into this new role where I was getting interesting things done.
My suggestion to you? Get a programming job of some stripe. Offer to work for $20/hr if you have to, just get a job. Find your niche; figure out what part of the process you are good at, and move in that direction.
Other people are suggesting doing your own thing... which is a fine thing to do, but if you are like me, building up a new app from scratch is going to be way harder than finding and fixing problems in an existing application... and the latter can be just as valuable to an employer.
The key takaway I'm trying to give you in this giant wall of text is that there are valuable roles at companies for people who can't build an application soup to nuts. It's okay if you only know a small part of the process.
But it's important to figure out what part of the process you can be good at, and I think the best way to do that is to get a job, even if it's a lower-paid job.