1. It takes a long time to be a 'good' programmer. The skill sets required are not just mastery of the language and syntax - there are a lot of concepts like algorithms and data structures, testing, analysis and decomposition, abstraction - I could go on.
2. The best way to learn these is to write code and read other peoples code - preferably code written by those recognised by others as excellent coders, but reading really crappy code is illuminating too (from a 'ok, dont do that' perspective)
3. Look for opportunities in your work to solve problems programmatically, rather than using your SA skills - automation, notification, that kind of thing. If opportunities at work for that are limited, read the questions posted here and try to replicate and solve peoples problems. Initially you'll just be able to say 'I can see it doesnt work', but soon that will start to change to 'I can see _why_ it doesnt work'
4. Add general programming texts to your reading list - I'd recommend "Generic Programming and the STL", "Design Patterns", any non-language-specific book on algorithms and data structures (I love Introduction to Algorithms but it is not a simple text - try a college library first to see what appeals to you). If there are any experienced coders at your work, see what they recommend. I love the Dragon book too (Aho,Sethi and Ullman), but it too is not simple
5. The perl books you must have to help you program perl better are the CookBook, Damian's OO Perl, MJD's Higher Order Perl, and from what I've seen, Damian's Perl Best Practice when it finally comes
6. join your local Perl Mongers, if thats practical
7. read some of the general programming mediatations here - brian_d_foy,merlyn,TheDamian,tmoertel,tilly,Juerd,Abilgail-II are names worth focussing on - your own list of knowledable people and trolls will grow over time.

There are many other things you can try - but perhaps a few hours fishing for links here is the best way - you never know what you'll catch - sometimes something good, sometimes bad

The most important thing though - if you find that programming is your passion, pursue it. Whatever your passion is, pursue it. Lifes too short to spend it doing things we're not really interested in.

HTH

update: fixed isbn link

A few replies to your points, most of which are sound ...
1. It takes a considerable chunk of time to become a good programmer. It takes a lot less time to become a competent employable programmer. I'd suggest that syntax is not particularly important. Testing, analysis, decomposition and abstraction should come easily to the OP, given that he is a sysadmin.
2. I got in to perl programming by bugfixing and tweaking stuff from Matt's Script Archive. Fiddling with hideous code is IMO quite a good idea, as it teaches diagnosis skills that you are less likely to exercise when dealing with good code, or even with your own code.
4. Your book recommendations look to be the sorts of things that might be suitable for a CS course or for a more advanced programmer looking to get some theoretical grounding for his practical knowledge, but not for someone just starting out. I recommend Dave Cross's excellent Data Munging With Perl which despite its name is really not about perl at all, it just uses perl for the examples.

On the other hand, once you've shown that you can tackle pretty much whatever's thrown your way, then the walls between different tasks tend to disappear, and you become an experienced "senior" type guy.

On yet another wavelenght, jumping in with both feet and being willing to be "under water" for a while is generally a very good way to learn any task.

-Scott

The basics that everyone who uses Perl more that casual dabbling should know are libraries and modules for code reuse and algorithm standardization. Once you know how to work well with these, you can explore OOP. OOP is more than just package creation for the sake of package creation. OOP gives you rich inheritance capabilities and allows for simplified designs and interfaces which can easily fit into much larger projects. I've seen good OO and I've seen bad OO. When you work with good OO it can make bad OO seem really bad. Of course, this is not to say that everything should be done in OO. Perl is not Java. :-)

That said, learn the advantages and disadvantages of OO design. This subject trancends Perl programming and goes into general programming practices.

Ultimately, what you need to know will really depend on what you want to do. Do you want to head into the world of web programming? You will need to know various templating technologies. Do you want to work on backend data-driven applications? DBI is your friend (and occasional enemy). Define your realm and the tools you need to learn will become apparent.

Good luck with your pursuit into Perl programming. Remember to always think "How can I generalize this just a bit more so that I can re-use it over there, too?" That question can be the difference between enjoying your product and hating it.

If I am proficient in a, b, c am I ready? Or should I be proficient in a, b, c, d, e, f, and g...

Actually, I was reading Effective Perl Programming: Writing Better Programs With Perl, and that author seems to think that d isn't important at all, but e really is.

    -Bryan

Ok, I lied, I never read that book. Unfortunately I haven't actually had the priviledge of reading any of this author's books

I started my IT career in hardware support, moved to Unix OS support (for a vendor), crossed over to doing sysadmin and finally moved into development. I think that my background in support has been extremely valuable. Knowing how to deal with end-users, understanding their problems and building and integrating solutions that are maintainable all flow naturally from that background.

As a sysadmin, I found there were plenty of opportunities to develop solutions that delivered significant time savings both for me and my users. Once I had a few of those under my belt, I felt confident enough to take on a development role. Luckily I found an employer who was prepared to give me the chance to prove myself.

There's no magical level of attainment that you have to reach first. When you feel ready to make the move look for the opportunity. Of course you may need to start in a junior role.

I'd advice you to jump right in, but not before you learn a,b and c. And since you are already using Perl in your current day job, you can set aside some time (not your employer's) for learning essential Perl skills. Next you could apply for a job which would require intermediate Perl skills (are there any out there?) You'll learn on the job. I believe thats one of the best ways to learn something new. Dive right in!

You have 'utilized perl' rather than programming.

I guess I'm not clear on the difference. In my mind, programming is telling the computer to do what I want it to do. Whether that's a system administration task, data munging, web application, or whatever. Not flaming, but where are you drawing the distinction between utilization and programming?

thor

Feel the white light, the light within
Be your own disciple, fan the sparks of will
For all of us waiting, your kingdom will come

I guess I'm not clear on the difference. In my mind, programming is telling the computer to do what I want it to do. Whether that's a system administration task, data munging, web application, or whatever.

I myself make that distinction - I guess its because I am and consider myself a sysadmin and not a programmer, although yes I do program, its not my primary function - maybe once I can get my head around that, I can move on - not necessarily professionally, but functionally.


Ted
--
"That which we persist in doing becomes easier, not that the task itself has become easier, but that our ability to perform it has improved."
  --Ralph Waldo Emerson

Utilization is using something.

Programming is making something, so it can be useable.

--Artist

Become a Guru in something you truly enjoy but be prepared to learn new things in case your area of expertise doesn't get you the happiness it should.