When I first started to learn Perl about 11 years ago, I was part of an implementation team, dealing with data migration from a legacy system to a new system. The migration suite we were using was heavily written in Perl, so I thought I might as well try to learn the language to better understand it (I had been a developer and a development team leader for about 10 years before that, so, of course, I had a personal interest with programming).
Anyway, I picked up a 70-page tutorial on the Internet (a fairly good one at the time, but outdated by today's standards), and read it over the course of two weeks on my free time (evenings and weekends, but not very intensely), also making small "baby Perl" test scripts.
After these two weeks, it happened that something was getting wrong in our data migration tests and that we needed to reformat quite heavily some of the data files for the migration tests to succeed. As I was the most development-inclined member of the team, I offered to write a script the remedy the problem, and was thinking at the time to write it in Python, a language that I had been practicing for perhaps 3 to 4 years. Then, when I was going to write this thing, I suddenly thought: "Wait a minute, dude, you've just been trying to learn Perl, why not try to apply this new knowledge to this professional problem." So I tried.
Because I felt that if would not be very fair to my employer to write my first real program in a new language on work time, I did this 300 or 400-line program over the next weekend. It turned out that it did not take me more time than what I was expecting to spend if I were doing in Python, a language that I knew much better at the time. It was fast enough (the data volume was very large), it worked well, and I loved the experience. In brief, I got converted to Perl. I no longer have the code of this program, I am sure that I would be today appalled by the coding quality (no use strict, using the -w flag instead of the better use warnings, poor command of many idiomatic shortcuts, bare-word file handles, limited knowledge of syntax for managing arrays and hashes, of course no idea about references and nested data structures, etc.) if I were to read it today. But it worked, it did what I meant, that was good enough.
So I continued to use Perl (and dropped Python) for some personal uses and for professional uses, but not very intensely, remember I was in an implementation team, not a development team. But I continued to read other tutorials, bought over the months and years a few books (Learning Perl Programming Perl, Perl Pocket Reference, Perl Cookbook, etc.) and continued to slowly improve my command of the language.
In 2010, I joined as a freelance consultant the technical team of a data quality department for a tier-one telecommunication operator (35 million mobile subscribers, about as many land-lines, Internet, TV, etc.). The main reason I was hired was that I had become over the previous 15 years a leading expert on both the functional aspects of the main mobile-phone customers rating and billing application used by this company, and technical expert of the proprietary programming language used by this application. My first task was to improve performance of many programs used on that application that were too slow, and did that quite successfully.
When I became more knowledgeable of the specifics of that department, within about six months, I figured out that a number of the things we were doing in that team could most probably be done better in Perl. I started to do a few things in Perl and quickly convinced most of my colleagues of some of the advantages of using Perl (some of them had been using a bit of Perl, but only for quick one-liners within a shell script, or the like). In one case, I succeeded, by using Perl, to reduce by a factor of 100 the execution time of a program that was way too slow, that made the difference between a program that was just not usable (many days to execute) and a program that runs in an hour or two (perfectly acceptable for our work, given the huge masses of data we are manipulating).
Ever since then, I am writing Perl code quite intensively, more than half of my time (unfortunately, being the expert on the other proprietary language mentioned before, I am spending still a good part of my time on it, but I have developed a strategy where I use it essentially to extract raw data from the database, and reprocess then the extracted files with Perl (this is the way I initially obtained the 100-fold performance improvement described above). I have become the Perl expert of the team, I wrote several relatively advanced modules for the benefits of the other team members, and I think I am truly an expert for the type of work we are doing (heavy data munging), even though I am definitely not one for many other uses of Perl (Web apps, graphical interfaces, network programming, using threads, OO programming, etc.).
Just because this post might seem to lack modesty, I claim to have acquired a fairly good command of the core Perl syntax, including some relatively advanced topics, and to be an expert on some very specific uses of Perl (data munging), but I must clearly state that I know very little or close to nothing on many other aspects. Many many monks here have far more knowledge than I have, when I can give something, I do, but the important point is that I learn a lot everyday from reading PM (and a few other forums).
All this long story to tell you how, despite that fact that development was definitely not my main activity when I picked up Perl, I was able at the time to do quite quickly very useful professional programs. And since I like the language, I constantly tried to (slowly, at the beginning) improve my knowledge of it, and I eventually became quite fluent with the basic syntax. Part of this has been made on my free time, but I certainly do not regret the personal investment. When I had the opportunity to use it more intensively, say early 2011, I quite easily and quite quickly convinced my colleagues of the advantages of Perl for the work we are doing.
Today, I received a mail from a very young colleague (he is still an apprentice, spending about half of his time in university and the other half at workplace) in a remote location, the kind of person that would usually speak only about PHP, JS and Java, saying something like: "I think that this program is too complicated, I suggest that I rewrite it in Perl." It was so sweet to read that mail, I felt like I was eating a spoonful of honey.
Finally, my point is this: if you are working in a high-tech profession (and if this is what you like), I think you sometimes also need to invest some of your own time into your training into new things. Your employer might pay you some training, and take it when you can. But you also need to do your homework, sometimes. Today (as very often in the last 18 months, part of my homework was spent on PM).
OK, this is my vision as a pretty successful free-lance consultant, but I became that only because I invested some personal time into these things long before I became freelance. I am happy I did that, but it is up to you, I am not saying you should take a similar course of action. You might as well invest your time into other things, it is up to you. Having said all that, computing is not my only interest in life, I also practice photography, sailing and a few other things.