I'll lay out what I did and what's happening to me and offer advice. This is of course just me and my experience and there are numerous paths to follow with none of them being guaranteed.
I was teaching and needed to earn a higher wage and so began to hit programming (related) books. I studied python and C and Assembly and networking and read and re-read and spent no time at all doing exercises. A couple of years back I got a job doing software support for development shop with a couple of substantial products with a small number of important clients. In addition to the prosaic bug-hunting and describing, I had cause to write python scripts to interface with our system api's and had cause to learn t-sql to acquire data-sets or perform operations for clients not accommodated by our user interface. I do a good job. Increasingly, I spent my time learning basics -- like assembly -- not doing exercises just reading and rereading, not to write code in assembly -- i don't think i'll ever have to do that-- but rather to understand what's going underneath the high level abstractions. This is critical. I don't know if it will be useful me, but it makes me comfortable, when working with higher level abstraction tools. That's important. Because the more useful the work you do professionally the higher level of abstraction you will be working at, and the higher level abstraction you are working at, the less likely you will be to understand the details underpinning the operations -- indeed this perhaps it the greatest productivity enhancement brought on by the OOP paradigm. But you can still feel comfortably oriented if you have a good basic understanding of what *must* be going on under the hood. And for me at least, that comfort helps me to forge forward at high levels of abstraction, because otherwise I'd always have a gnawing feeling that I'm floating on air and do not understand anything and that I need to go back to basics, the over-focusing on which would likely lead farther away from gainful employment in the industry.
So what's the upshot? Learn basics -- to facilitate your life's work in the abstraction domain. You'll be happier, more productive, and more fulfilled in your work.
Next point.
After a couple of years my manager turns to me and gives me my long awaited access to the source code, and gives me a mandate to learn up on particular framework (a JSF implementation for the record.) So now I'm reading core java and core java server faces like a madman, but am still employed in my support role facing little pressure to 'produce' which is key. Also, trust me, you cannot compare learning Java and JSF while staring into the belly of real life enterprise application code wading through source files with a modern IDE (navigable!!) trying to figure things out. It's night and day different from tutorial land learning. I cannot overstate that -- night and day.
At the same time, I do not believe, as a rule, that you can self-teach yourself these frameworks to get yourself hired as an entry level learn on the job programmer, because I do not believe there are such positions. Programmers are paid well, and companies dish out that type of money because they have things they need done and they've no need to train.
But, once your in, your in. Which means that if you can get yourself into a software support role and learn basics and work your self into source code access and then study the relevant technologies -- then that, I believe, is a reliable way into the field, because 1. by the time you get access, they know you are competent and that they like you and 2. by the time you get access, you will already be providing value to the company proportional to your wage, and 3. while you are learning the technologies (and it's not 'rocket science' if you know the basics) you will have a real life application before your eyes to study, and 4. (an not least, at all) this real life application you are studying you will already know outside in, because you have become an support expert in it.