There are a few things you can do to keep advancing. The easiest is to pick up some good books about programming that aren't necessarily about a particular language. "Code Complete" and "The Pragmatic Programmer" are two excellent books for that.

Another thing you can do is start learning different types of languages. Learning a more object oriented language like Ruby (or even Java) can do wonders for teaching what OO is really about and can help you better understand why Perl's OO is "bolted on the side". Learning a logic or functional language can also help you learn completely different ways of looking at problems. These will make you a better programmer in the long run.

Cheers,
Ovid

New address of my CGI Course.
Silence is Evil (feel free to copy and distribute widely - note copyright text)

Ovid,
Yes - this is good advice. I recently had the honor of assisting a fellow monk re-write 5 csh (c-shell) scripts that did a single function and took a LONG time to run. I discovered that my shell scripting had magically improved after being on a 6 month hiatus because of Perl.

I will make an earnest effort at the book aproach as well. I do not want to use the excuse "I don't learn from books" or "I only use books as reference" since it isn't a real reason. Being realistic (as opposed to optimistic/pessimistic), I stick with a book until I am bored with it and then it becomes reference. I asked the question and if I am serious about doing it I should buckle down and try.

Thanks - L~R

I'd like to point out Split Scalars and Objects/References into Two Types which explains the "bolted on the side" remark -- it's not a bad read overall ;)

MJD says you can't just make shit up and expect the computer to know what you mean, retardo! I run a Win32 PPM repository for perl 5.6x+5.8x. I take requests. ** The Third rule of perl club is a statement of fact: pod is sexy.

I know how you feel. Sometimes, there are posts at PerlMonks that exhibit an elegance that makes me feel there is a lot to learn still... but I don't know where to start.

I like Ovid's proposal -- try to learn another language, it is really interesting. You could go for Java or C++, or for something more different: Prolog, ML, Lisp, Scheme. (I had these in school, and they helped me to think differently.)

Some people like to occupy themselves with foundational CS books like "Structure and Interpretation of Computer Programs", but I find that I really learn best when tackling projects. (Nothing against the books -- I also use them in my studies, but I belief it might not be the right approach for L~R.) I know this advice has been given on PerlMonks a number of times, but I believe it is still true for your situation. You could choose a topic that really interests you and challenges you to learn something new, rather than applying concepts you already know in new ways. Some ideas:

• Parrot. I'm serious, if you've never done Assembler, this should be real fun. You might even end up creating a few example scripts that help others.
• GUI apps (ie., event-driven programming)
• CS topics like linguistics, artificial intelligence, distributed systems, graphics/sound manipulation, bioinformatics. Choose something that interests you. You'll be surprised to see how much you can do even without formal Computer Science training if your curiosity guides you.

Also, I would recommend participating in a larger open-source project. It is really quite different to do programming in a group, it would teach you a number of new skills.

Note that I don't recommend specific skills that I belief you should learn about. First of all, I don't know your skillset, and second, once you are beyond a basic stage, you really need to pick the skills you want to learn yourself according to where you want to get to. E.g. if you plan to change your career to professional software development in the large some time, you will need different skills than if you plan to spend your future time teaching Perl or building web apps. So after you think about the possible directions that are open to you, pick a goal you want to be at in maybe a years time or two, and learn whatever skills you need to attain that goal.

It may help first to think about what your goals are in a more general sense than directly about what specific bits of information you might want to assimilate. For example, you say that you're not a computer programmer professionally, but do you want to be? If so, one way to think about these issues is first to figure out generally what type of position you would be interested in applying for, and then pursuing and strengthening the requisite skills. For instance, the other day I composed a list of subjects that I'd be less than comfortable discussing in an interview, and so built myself a syllabus of material and a rough timeframe for e.g., basic XML proficiency, review of certain algorithms and O(N) notation, C/C++ review, etc.

If you're not planning to pursue software as a career, perhaps you'd be better off just thinking about the kinds of problems you like to solve. A diligiently curious person -- as you seem to be -- will find it very difficult to exhaust the realm of digital possibilities, so follow your muse.

I think it makes more sense to begin from a more abstract, goal-oriented perspective than to take something like "the 7 stages" too seriously, as the latter assumes that the reader is actually interested in learning the minutia of every aspect of Perl coding. Its ranking doesn't take into account the interests or professional emphasis of the programmer in question. I find that I fit no stage well, but only a vertical sampling from nearly every one.

This at least feels like a primary way that I improve. I start with the sense that there is a better to approach a particular problem, and I start to research and discuss that.

Some things took a lot longer to figure out and sink in. Reading "Code Complete", as mentioned above, has really helped with my understanding of appropriate use of global data. In retrospect, I would have read more books on the theory of programming earlier on. It's easy enough to find a helpful module on CPAN for a particular task. It's harder to find a good resource that discusses the merits of one software design philosophy versus another in a useful way.

Perlmonks is useful, but you aren't likely to get a 15 page response examing the details on how to best name subroutines. :)

Mark

So very true. While I was working at a company that had at least one programmer/designer/etc that was lots better than me, I got better every single day, and often not by little either.

The, on the other hand, I spent over a year at a company where I was by far the best programmer (and probably one of the best computer guys all categories). Not to be taken as that I'm very good. Only compared to those others. It was pure pain most of the time. While it felt good to be able to solve problems for the others, and getting lots of credit and respect, I hardly evolved at all, more likely I lost some skills. The credit doesn't matter all that much when you really don't have to work hard at solving the problems at hand. There were a few times I needed to think hard, but oftenly it was pretty easy stuff.

Furthermore, disliking my situation at that job so much made me lose the interest in doing fun stuff for myself at home as well, becoming quite apathetic for a while. Thank goodness I'm not working there anymore. I'm starting to feel my old self again. :)

---

You have moved into a dark place.
It is pitch black. You are likely to be eaten by a grue.

Dog and Pony,
Thank you so very much. I recently gave my notice at a place where I was in the same perverbial boat as you. I have found the majority of my jobs as not satiating because of this very reason. I know that I am not that good - I find myself in the presence of greatness everytime I log into PerlMonks. I guess I will start looking for a job where I am the least qualified (figuratively speaking) and not the most qualified. Thanks again for putting some perspective on this problem for me.

Cheers - L~R

"Ex libris un peut de tout"

Firstly, I have to admit that I have only skimmed the replies thus far but I truly have ready your question!

My answer to the question is... If you have read the camel book and understood it then you know the language. The camel book is IMHO the definitive description of the language. If you wish to go further or deeper, Advanced Perl Programming (the puma book?) is recommended. Furthermore, we are all in the situation of not knowing what we don't know (in detail anyways!) so if you come across something you didn't know and then come to know it, then you know you are truly making progress on the randomly meandering path to an unknown goal.