This is most interesting posting and I have enjoyed both the op's post and all of the responses. Some of the response have tried to do what I would call "making the best of an unfortunate or bad situation" while others have offered good, "how it *should* be done" responses. For me, the crux of the difference between those two approaches is, indeed, the availability, or un-availability, of "experts".

I don't have any specific advice, per se, beyond all of the good responses that have already been offered. But I *do* some some experience that I'll share (if the readership can indulge my writing).

We use Perl at work as the centerpiece of our systems integration & testing efforts and also, to a somewhat lessor extent, for actually operating (or automating our operating) of the systems.

However, we only have a few folks (maybe 2 or 3) who would be really considered "seasoned" Perl programmers. They are rarely available to help beginners and generally have not learned or used any more Perl than is the bare minimum to "get by". So even they have no real depth or appreciation of Perl beyond the basics. They are, however, excellent, creative and seasoned programmers so they can make even the basic structures and strategies "sing" in very complex situations. They were essentially not available to help me; so my situation is not too unlike the general situation of the OP.

As the most Senior Chief Systems Engineer, I continually felt like I would be so much more useful and helpful if I understood and used Perl, too. So I undertook to learn it...on my own.

I very quickly realized how very much I wanted, needed, and could benefit from having an "expert" Perl programmer available to answer all sorts of questions that nagged me. Instead, I had hunt the answers down myself.

That was, on the one hand, very valuable as it taught me a lot about the resources that were available and opened up an entire world of expertise that has proven again and again to be "my friend." It also led me to the Monestary; which provided incredible leverage to my learning and has taught me so very much about how to be a good Perl programmer (I have done programming professionally in other languages for several decades); but learning how to tap into the strenths of Perl and how to apply it efficiently and most productively is almost impossible to learn on one's own; hence the Moneastary has transformed me most incredibly as a Perl programmer.

But it also took way, way longer to learn even the basics than it should have. In retrospect, it took me about 3 years of trial-and-error, hunting for answers on my own, and doing many, many coding projects before I began to feel "competent" as a Perl programmer. In retrospect (and comparing my experience with previous experiences learning a new language where I had "experts" available to mentor me) that it should've only taken a few months to maybe a year to reach that same level of competence.

Of course, your mileage may vary (YMMV); I'm not the brightest candle in the candelabra as they say...so my level of inefficiency is probably not very traceable to the capabilities of the programmers that the OP is concerned with.

But that difference in what it "should or could have taken" versus what "it did take" is what I mean, in regards to learning Perl, by "efficiency". And therein lies what I consider to be the single biggest issue, one that I think the OP and the associated organization, need to understand and think about: learning by one's own "bootstraps" is workable, but the efficiency and effectiveness is significantly compromised.

In that vein, I think the posted responses that accept that expertise is not available are useful and excellent, in my opinion, ideas on how to do "better" at efficiency and effectivenes in lieu of having real "expertise" available.

The posts that suggest "you need an expert" are, in my opinion, absolutely correct if you are to have any efficiency or effectiveness in reaching the level of quality that the OP is looking for in a quick way.