Just to share my experience along those lines: I had done some basic generalist programming prior to university but no real server-side web programming and tbh not much programming for real work.

I got really pessimistic about programming after quitting the CS major in university. So for almost a decade afterward I refused to learn more about programming. I just had a bitter taste in my mouth about it. I was embarrassed and unsure about what had gone wrong for me.

Eventually I got into web CMS installation, configuration, and basic maintenance because I could design websites, but my clients really wanted them to be powerful and have tons of features on the back end too.

I worked through WordPress, Joomla, and MODx, got sick of "enterprise-class" anything because the maintenance burden was increasingly annoying and back-end GUIs were even getting annoying. Then I found the Textpattern CMS and saw how lightweight it was, in fact you could even use Textile. This was a couple years after the vendor for one of my favorite Joomla rich text editors literally quit maintaining the plugin, sold my customer data off to a telco firm and I started getting spam for VOIP services.

I bought the book "Textpattern Solutions" and learned TXP's XML tag system. The tags allowed simple if/else logic. I could really easily work with the templating features in a logical and elegant way, and I started to share what I learned online.

Among those templating tags was the TXP:PHP tag, which allows PHP use within the CMS. I thought, "that's funny...I can run PHP scripts inside a blog article?" And did some of that, realizing I'd definitely be getting back into programming more often.

Then there was also a plugin written by Stef Dawson called smd_query, which allowed custom DB queries against the CMS database, within articles, templates, wherever. He also added some helpful conveniences that made everything seem so easy.

So this was all a very quick way to go from "can install a CMS" to "can do CMS templating" to "can do web back-end programming".

But you can pick up so many gaps this way, too. Especially on a deadline.

Pretty soon I was running a wine distributor's network of websites via some back end services that could be managed in the CMS due to the tight integration with various customizations to native features. I was then able to connect other third-party vendors with various corporate sales teams via the back end and everybody got their work done together using the tools. I realized I was being paid for helping the entire company do their work more efficiently--this was a long shot from making a simple website or blog.

(For a time they even used Textile for editing articles, but after a while it got annoying for some specific articles and we moved away to rich text in that case.)

Eventually an organization in the bay area reached out as they had an extremely heavily-customized TXP install running their online purchasing workflow. There was a lot of custom code written by a veteran coder, they gave me access and it was weird to realize--I can understand this and I could maintain it.

Another organization got on the phone and interviewed me about taking over their custom system. Their programmer got on the line and was practically begging me, like "look, this thing is just run by a big CSV file. All it is is some scripts, some CSV, some code here and there," and I started to realize that most of this stuff wasn't the big secret that I thought it was, based on the way I had previously approached my CS studies.

Still, sometimes the old CS principles help even though I've had to ask some embarrassing questions about them along the way.

To fill gaps from there, I found it really helpful to read books that are just below my level. If I'm reading books that are above my level, I have my own way of approaching those if I need to, but I don't read them the normal way usually and I don't personally find it helpful to use the books themselves for early-level learning purposes.

I also learned that I learn about gaps better through anti-patterns and "don't do this" articles so I specifically search for those sometimes.

Finally I pay close attention to remarks by developers of the systems that I build on. If there's an API I use, I try to pay attention to the release notes and things of that nature. Some of them are impossible to track because changes are so frequent and complex, but others are pretty straightforward. I use my own documentation system to track these because release notes and blog posts are almost never part of system documentation (lamentable but true).

Anyway. Just one example, just part of the story in a way, but I hope that helps a bit.