|P is for Practical|
With deepest respect to the sincerety of your question, my opinion is:
and my reason is as follows:
MCP is a racket. It generates all sorts of revenue for Microsoft, but doesn't mean anything beyond "basic familiarity with MS technology."
Seriously.. how many lines of parsing code do you expect out of a MCP per month? How long does it take an MCP to generate seven function points worth of transaction management software? Does an MCP know how to implement a B-tree or a graph-clustering algorithm? It's an identifier with no attached metric, and exists because managers find certificates reassuring. They don't know what MCP means either, but they figure it has to mean something.
But it doesn't. It can't. The problem space of "computer programming" is way too big, and way too messy, to be carved up in chunks and measured.
Studies have shown that even among programmers with the same training and the same number of years experience working on the same subject.. literally, guys sitting side by side in the same project out in the cube farms .. there's still a 100:1 variation in productivity. What one programmer can write in ten seconds, because he's already encountered this problem in the past, will send another digging through manpages and references for four hours.
Worse yet, there's no standard for measuring real productivity. The person who can crank out 10 KLOC every week without fail may not be a better resource than the one who generates 1 KLOC a month. Sometimes the most productive thing you can do with 10,000 lines of code is reduce it to 3500 lines of code.
The real killer for a PCP, though (that three-letter acronym is what set me off above.. pump enough caffeine in me, and you'd think I was on PCP), is that there's no Big Corporation to make the letters sound important. An MCP means "this person paid Microsoft about $5000," but hey, Microsoft's big and impressive. Anything they charge $5k for must be worthwhile. Perl doesn't have that kind of corporate backing. We'd just be people with self-assigned funny letters after our names.
Instead of worrying about certifications, spend your time building a good code portfolio. Write bunches and bunches of code, organize it well, comment it professionally, hand it off to all sorts of other programmers to find out how easily they can read and understand it. Then make sure you have it stored where you can do live demos when you talk to a prospective employer.
Be aware that the coding standards for portfolio code are trickier than regular production code. Not only do you want to show off the things you can do, you want to show off the pieces that make it possible. Isolate your data storage so you can point to a given script and say, "right here, I'm using a heap to handle the priority queue. In this program over here, I made room for variable behavior by chaining function calls. Over here are some callbacks."
Use each technique in multiple programs, to show that you have a toolset that will let you write all sorts of different software. That will give prospective employers (and even your current one) a better idea of what you can do, and impress them with a sense that you can deliver. And that's what they really want.
In reply to Re: What is your opinion in Perl Certified Professional?