If your Perl skill can placed into Amateur, Intermediate and Advanced levels, how would you know where you Perl skill level is? It's probably obvious in some cases but are there indicators to help you determine whether you've progressed beyond the Amaterish level and so forth?

Reading I present to you... Horrible code!, I get the sense that that sort of code is the result of two things: first, not knowing enough Perl ways and second, not knowing enough programming techniques (e.g. refactoring).

There must be some Perl constructs or syntax that is considered more advanced. What are those? OOP is considered an Advanced Topic in Programming Perl, so does not using OOP imply an Amateurish level of Perl knowledge?

Have you advanced past only using scalars and arrays and tried hashes? Have you learned what a reference is, how to create and dereference one? Have you started creating advanced data structures (AoA, AoH, HoA, HoH, etc)? Have you created a module? Used OO? Used AUTOLOAD? Mucked with the symbol table? Discovered B::? Actually used it for something useful? Delved into the perlguts? There are many different ways to measure your growth as a Perl programmer.

I think I'll just always consider myself an amateur, (unless I'm working on my resume, in which case isn't everyone advanced? :)) After all, if theres only three levels, I'll never be just two levels below someone like merlyn no matter what skill set each level encompasses.

Although I don't know or care exactly what level I truly am, I do know that I can look back on code I've written not even a month prior and improve readability/maintainability/elegance etc... based on new concepts I've picked up. This confirms that I'm still learning and that's what matters.

As far as the code in I present to you... Horrible code! that node has almost nothing to do with lack of Perl knowledge and everything to do with lack of general programming knowledge. A complete Perl newbie with a good programming background would never have written such poorly laid out code even if they were his first lines of Perl.

OOP is considered an Advanced Topic in Perl Programming, so does not using OOP imply an Amateurish level of Perl knowledge?

Not using OOP doesn't imply an amateurish level of Perl knowledge at all, trust me I've seen some pretty amateurish OO code. Perhaps not knowing when to use OOP and when not to implies an amateurish knowledge of OOP however.

If you feel the need for rankings, though, you might like Seven Stages of a Perl Programmer, which is intended to be instructive. It needed more than twice the granularity, because Perl is such a large language.

If you feel the need for rankings, though, you might like Seven Stages of a Perl Programmer, which is intended to be instructive. It needed more than twice the granularity, because Perl is such a large language.

kiat, first, great thread. Secondly, it seems that no matter what discipline you are engaged in, the more you know about it, the more you know how much more there is to know (whew!).

When I first starting writing Perl, I wouldn't have recognized good Perl code if it bit me on the butt. But experience, and lurking around the Monastery, have at least helped me to recognize the better practices, even if I'm not there myself. It's a bit like sitting in a plane before take-off. Everything in the distance seems a single horizontal line, but as you climb you realize the depth and complexity of what lies beyond.

—Brad"Don't ever take a fence down until you know the reason it was put up." G. K. Chesterton

That principle is represented in a few Zen koans that I recall from my earlier days. It does seem consistent that every person goes through a period in their learning process where they think they know more than they actually know. They exit that phase towards proper mastery only by realizing they know far less than what there is to know.

In the online world, this "middle category" manifests as the "helper who gets constantly corrected". I think we've seen a few of those here, and certainly on Usenet, and definitely on some of the Perl mailing lists.

I definitely don't think it can be split into three levels... and after a certain point, Perl skill doesn't even fit into coherent levels, as people become specialised in certain areas.

I think the great thing about Perl (and maybe programming in general) is that the more you learn, the more you realise there is to learn. In that sense, the whole 'Monk' analogy is very apt. True mastery takes a lifetime (or more).

OOP is considered an Advanced Topic in Programming Perl, so does not using OOP imply an Amateurish level of Perl knowledge?

No. I think you are confusing Perl knowledge with wisdom. I've been programming for about 30 years and only learned Perl and OOP in the last 5 or so. The first Perl programs I wrote were non-OOP C-like code, with gastly things like global variables (horrors), but strangely enough they worked and they were solid in production. I've learned a lot since then (OOP, Perl idioms, etc), and I don't write Perl code like that anymore, but I wouldn't call non-OOP usage either Amateurish or Novice level.

A novice is someone that uses what they already know to help them in a new field, knowing they will need to learn more, try new things and that they will make mistakes that will need correcting. An amateur is someone who uses the latest shiny tool (e.g. OOP) when it is inappropriate for the problem at hand, and doesn't suspect a thing.

The only true knowledge consists in knowing that you know nothing... (credited to Socrates by Bill and Ted) :-)

I am tempted to expand on what a few already alluded too in that you should not confuse Perl mastery and Programming mastery. A complete and in-depth knowledge of a hammer does not make you a master home builder. The reverse is of course also true, if you decide to switch from that old fashioned hammer to an air powered nail gun. You should give fair warning to those looking to you for guidence to take cover for a few minutes...

However, it depends on your purpose for the ranking. If you want to screen someone for a job the two become (potentially) more closely related since you are wanting to pay someone to make practical use of those tools.

On the other hand (am I up to three hands yet?) you may still be better served to keep the two questions distinct and seperate. Doing so will tell you what training you really need in order to improve your skills. It doesn't do you any good to buy the GoF book on Patterns and let it sit on the shelf for three years (like mine has) if you are not ready for it. But if Perl itself is no longer offering you anything new to learn, perhaps some general books on design and development methodologies might be what gives your code that next big boost.

When putting a smiley right before a closing parenthesis, do you:

Use two parentheses: (Like this: :) )
Use one parenthesis: (Like this: :)
Reverse direction of the smiley: (Like this: (: )
Use angle/square brackets instead of parentheses
Use C-style commenting to set the smiley off from the closing parenthesis
Make the smiley a dunce: (:>
I disapprove of emoticons
Other