On Mon, 28 Feb 2005 17:49:12 -0500, James Linden Rose, III <[EMAIL PROTECTED]> wrote: > From: "James Linden Rose, III" <[EMAIL PROTECTED]> > Date: Mon Feb 28, 2005 5:42:06 PM US/Eastern > To: Adam Turoff <[EMAIL PROTECTED]> > Subject: Re: [Boston.pm] (also) Perl > > On Monday, February 28, 2005, at 12:46 PM, Adam Turoff wrote: > > Another "worst case for certification" is that the community bifurcates > > from those who are rabidly anti-certification, and they take their > > efforts and talents elsewhere. And their patches. And stop > > maintaining > > their modules. > > I don't believe in this perspective. Why would anyone be "rabidly > anti-certification"? That seems terribly irrational. I would call > such a person a certifiphobe to his face. How does one person's > certification offend some other person who doesn't believe in it? Take > their talents where? Where are they fleeing to? Fleeing from what? > The train of logic seems to have episodes of being aeronautical. I > understand that some may think certification is a waist of time, but > how does that offend or discourage that person from upgrading their > module?
What don't you believe? That there are rabidly anti-certification people? That many prominent Perl programmers are among them? If you doubt that, then I'll call you reality-challenged to your face and point you in the general direction of Randal Schwartz. For a sample of what they think and why they think that, read http://use.perl.org/articles/04/01/10/0055227.shtml?tid=9. Speaking personally, what I most dislike about the idea of certifications is the likelyhood that I'd be pushed to waste time and money demonstrating that I know Perl. My time and my money. (Why should an employer who knows that they hired an expert wish to invest their money into enabling me to prove my competence to others?) > > Another "worst case for certification" is the gradual dumbing down of > > the caliber of Perl programmers that Joe Average Manager can hire. I > > could go on. > > The point is that Joe Average Manager ISN'T hiring Perl programmers. > Only his elitist cousin, the savvy manager is. How does increasing the > number of Perl practitioners reduce the potential talent the manager > can hire? The same old self-taught, self proclaimed Perl mongers > remain in the job pool as before. The wise and technology savvy > manager still uses him. The idiot manager who was hiring Java beans > now hires the mediocre Perl plebeian. I'd have to say that, given how many "Perl programmers" are out there who've never seen anything beyong badly written CGI scripts, it would be hard to dumb the job pool down further. You can improve the pool that you see somewhat through advertising on jobs.perl.org rather than by going through a random headhunter. > > - Certification doesn't _prove_ anything. It's mostly a means to > > weed out resumes when you have 1000 applicants for one job. > > When you go to hire Perl programmers it will mean something. As things > are, there are lot of people who claim to be able to use Perl who would > have trouble with any level task. Besides, there's a simple substitute > for certification that is more impressive... which is show me something > you've built with Perl. Generally companies incompetent enough to rely on certifications are not going to take the time to evaluate a complex project. Besides certification is an inferior substitute for the technical interview, which also solves the problem of the certification testing for a different mix of skills than you need. (In every Perl job where I've worked it is more important to, say, understand how WHERE and HAVING differ in SQL than it is to understand the ins and outs of formats. Which would be on a Perl certification?) > > - The point behind certification efforts is generally to "grow the > > pool of Perl programmers". The logic is that a rising tide lifts > > all ships: more jobs for entry level programmers, more jobs for > > gurus, and so on. However: > > - there is no demonstrable evidence that there is a mass of > > programmers ready to use Perl, if only there were a > > certification they could get > > This is a strawman argument. There is no mass of programmers ready to > use Perl because there is no educational forum available to learn and > prove that you have learned the language. Would you, without the > reward of a college degree, take it upon yourself to study Calculus, > Simplex Algorithm, Linear Programming, & Statistics - hoping one day > somebody would come to the idea of granting you a BS in mathematics, or > would you study these fields knowing that you would receive a degree > for your efforts that you could then parley into a job? Without the > promise your certificate holds most would not embark on the course of > formal study. Nice theory. I don't buy it as you're trying to apply it to Perl. My impression is that the language which is making the most inroads on traditional Perl areas is PHP. Is that because of the wonderful certifications that PHP has which Perl doesn't? Or is it because PHP is seen as easier to get started with than Perl? Also PHP has the huge advantage that hosting environments allow it to be used in a shared hosting environment, while mod_perl requires dedicated servers. (That is because PHP is less capable, so it is hard for one site to cause problems for other sites running in the same Apache process.) > > - there is no demonstrable evidence that there is a pool of > > employers that do not use Perl simply because there are no > > certified applicants > > I have personal experience that leads me to believe the contrary. > Besides, the non-savvy manager is going to ask his "certified" employee > for an opinion on what a project should be coded in - and at this time, > that employee is not a Perl monger. Perl is at best viewed as a hobby > without the magic credentials, in the same way you would be viewed as a > smart guy who is nevertheless still too risky to hire if you sat in the > library reading for 4 years outside the context of a degree granting > institution. This, right or wrong, is just the reality of how our > world works, and ignoring this only hurts Perl. Suppose that we try this and it doesn't work. Does the argument then become that we need to get our certification backed by someone prominent because a certification that nobody has heard of is proving to be useless? Also I have a different theory. My theory is that the non-savvy manager is going to ask someone he trusts for an opinion, who is either going to be someone whose competence has been proven (less likely), or is going to be someone else of about the same position and abilities (more likely). In neither case does the existence of a certification enter into the process. > > - there is no demonstrable evidence that simply offering > > "certification" will answer the questions hiring managers > > will ask > > But at least the Perl guy will get his chance to field the question. Hopefully it does not surprise you to learn that I don't subscribe to this theory. > > - Many Perl trainers are vehemently anti-certification. A > > certification without a supporting training curriculum is dead in > > the water. > > I agree. A Perl certificate should come along with a corresponding but > optional educational package. Perhaps the certificate can even come > with a version number so that later numbers are more valuable than > older ones... keep the certification and education constantly improving. So now I need to take an endless stream of training from an approved source? And remember to give the "correct" answer on a test even when I think it is wrong? (Quick: is "our" a good thing? Read http://www.perlmonks.org/?node_id=48379 before answering. Yet as cool feature of the day I'm sure that a certification would have required me to talk up how great it was.) What is in this picture for me? > > - Sure, they could turn around, and sure, other trainers are just > > as vehemently pro-certification. But this difference of > > opinion > > should be resolved before any certification effort moves > > forward, and it's been a complete logjam for years. > > Don't follow how the logjam is created or important. Why would such a > program require the unanimity of the entire Perl using population of > the earth? A certification that has very prominent and vocal opponents within the community is likely to have an uphill battle to acceptance. A certification that didn't have enough support for people to learn what they need to pass it is going to find that the hill is looking more like a cliff. > > - Lots of programmers have a whole litany of excuses as to why they > > avoid using Perl. Ugly code is one. Excessive use of punctuation > > is another. Impenetrable regular expressions a third. "Odd" OOP > > practices a fourth. And so on. Lack of certification options is > > almost never a reason for programmers to not use Perl. > > Don't have any formal training in it is more likely. And I don't see > why a programmer would ask himself about his own certification before > deciding on what language to use. That's not human nature. I've seen the discussions that are being referred to. Trust me, when people go and complain about Perl's shortcomings, they're not likely to complain about ther training (or lack thereof) or certifications. They complain about everything that they dislike about Perl. The only time that I see people talking about the importance of lacking a certification is when they're arguing that Perl needs to have certifications. > > - Another reason why Perl is a minority language is that it's not > > used in academic curricula. Certification will not solve that > > problem, either. We'll still have a glut of VB, Java and C# > > programmers after a certification is done. > > Aside from the fact that I think bio-informatics uses it very > extensively, put yourself in the position of a university department > head. How do you hire a Perl instructor? What certificate is out > their to prove that your candidate professor is qualified to teach the > subject? And I don't think the goal of certification is to wipe out > all other languages from the face of the earth. Nor are academics in > the business of training people in technologies for which they will not > be hired, and again, certification should ease that problem. This argument fails on the observation that most universities did not waste time asking what Java certifications their professors held before switching to teaching in Java. The latter half of it again fails on the observation that many universities teach languages like Scheme despite knowing full well that you're unlikely to be hired using it. Universities are not supposed to be in the business of vocational training. Some academics take that very seriously. > > - One reason why many shops avoid Perl is the lack of vendor > > support. Certification does nothing to address this. > > True. So perhaps the certification process will create the man-power > and climate to form companies that can support Perl. I consider it more likely that the certification process will open divides within the community that leave less energy for people to support Perl. > > - Even with a certification program, the underlying problems with > > Perl still need to be addressed: mod_perl is too hard to manage in > > many situations, applications like RT take entirely too much work > > to install, and so on. [1] > > I have had zero success in modifying my more complex Perl programs > into mod_perl ones. I just wish I had created them as mod_perl from > the start. Maybe if I had to attend a certification class I would have > been told that before wasting 1,000 man hours. And here we see another major pitfall. Perl is used for a lot of different things. Perl tends to be good glue. Which means that you need to understand the things that you're trying to glue together. It will be difficult to impossible to provide a single curriculum that addresses all of the different needs to be useful everywhere from mod_perl to database processing to bioinformatics to system administration. Which of the following topics should be in a certification? In what depth? - OO support - Templating tools (Mason, Template::Toolkit, etc) - database interfaces - XML manipulation tools - Graphics libraries - How to write XS interfaces - interprocess communication - The Win32 API - Complex regular expressions Every one of these matters a lot to a segment of the community. None of them matter to everyone. I'd suspect that few people actually need to understand 2/3 of these topics. Most probably only need to know half of them. But different people need to know different halves. No simple certification is going to address this problem. Regards, Ben _______________________________________________ Boston-pm mailing list [email protected] http://mail.pm.org/mailman/listinfo/boston-pm
