Another good advice would be: “approach Perl in the greater context of ‘a tool for professional-grade software development.’ ” Your real focus needs to be upon the latter. “A tool for a job,” is not “the job.” (Translation: No matter if you buy me the most dazzling titanium framing-hammer in the known universe, and the most idiot-proof computerized measuring tool, I know to hire a contractor to install a new window. Hand tools are dangerous in my hands, but I make good money as a computer programmer, and with that money I hire people who know what they are doing.)
Perl is “a damn good tool,” yet, it is only one of many.
Programmers on-the-job are constantly confronted with things they don’t know; with incomplete descriptions of failures that are unexplained and poorly described. They are constantly detectives and investigators. They are doing things of profound importance to their employers’ core business, using technology that is remarkably delicate and unforgiving. Hence, their personal traits are as much or more important than whatever their technical competencies may be.
“Study CPAN” is excellent advice, but not only for the code itself: also, for the process by which it got there and stays there. This is peer-reviewed code, constantly cross-checked by tools like CPANTS, widely used as, as it were, a software product. If you can train yourself to produce work at that level, and to be recognized for doing so by your new appreciative end-users (who, by the way, have requested forty-’leven new features...), then you have demonstrated the ability to
do deliver something that is very commercially valuable indeed.