If this is your first visit to my site, welcome. I've written a book called Modern Perl which explains how Perl 5 works and how to program Perl effectively. Electronic versions are free to download and redistribute, and print versions are for sale. I hope the book is useful to you; please tell other people about it.
If you're an employer or recruiter looking for good Perl developers, the whitepaper Where to find a programmer who knows modern Perl may help you. See also How to Identify a Good Perl Programmer.
If you're a programmer yourself, I recommend The Lemon Market of Programming Language Adoption, which explores the economics of why programmer salaries get pushed down in popular fields.
Hiring Great Programmers is Difficult
One of the persistent rationalizations for not creating new software in Perl is that it's difficult to find great Perl developers.
That's half true.
It's difficult to find great developers in almost any language, unless your language community is so small that it's self-selecting against people just in it for a paycheck. (Even in that case, the truly great developers who know Haskell or Smalltalk or Common Lisp tend not to be in want of work for long.)
In another sense, it's difficult to hire great Perl developers because it's so very easy to become a mediocre Perl developer. Despite the repeated myth that Perl is difficult to learn, it's not. It's shockingly easy to learn just enough Perl to build a working system. If you remember the mid to late '90s at all, think back to all of the tiny little form scripts that you could FTP into a cgi-bin directory. Most weren't worth using, due to various limitations, but real people learned just enough Perl to write them.
It's more true to say that Perl programming is easy to learn but not simple to learn well. (This is not unique to Perl; you can explain Smalltalk's syntax to a class of rapt sixth graders armed with only a 3x5 notecard, but said students won't approach Ward Cunningham in ability any time soon.) Perl, like PHP, suffers somewhat from the ease at which you can learn just enough to be productive. In terms of language design, there's no initial turnstile which keeps people out who aren't yet smart or experienced or stubborn enough to figure out how to wrestle with a compiler, or type errors, or the precise alignment of invisible characters, or configuring a web server, or setting up authentication with a database.
There's also nothing in the language which forces people to stop every hundred lines or ten programs or two weeks to push them up the learning curve a little bit more.
The result is a language that lots of people know a little bit. Many people know it well, but the group of people with a little bit of knowledge (likely due to ad hoc experimentation and intuition based on previous familiarity with another programming language or Unix culture or just copy and paste osmosis from a barely-working heap of sticks left by the previous maintainer) dwarfs that smaller group of experienced programmers.
Hiring from this pool of experienced programmers would be easier if the people hiring Perl programmers knew to hire from this pool of experienced programmers—but this problem exacerbates itself. Without a cultural or financial incentive to encourage novices to become adepts, only the most stubborn, the most motivated, the most curious, and the most fortunate realize that tools such as Perl::Critic and Test::More and Moose exist. It's one thing to know about the CPAN and use it when it helps you—that's what a mature programmer will do—but it's far too easy to get by without realizing how many great tools are available. This is a failure of Perl culture and documentation, that the CPAN isn't better publicized.
Then again, too few novices even know how to take advantage of all of the Perl documentation that comes with every complete Perl installation.
One solution, as I see it, has two parts.
Perl Programming Skills
First, if you want to hire great Perl developers, look for people who:
- Know how to use modern Perl tools
- Have used CPAN modules
- Participate in groups such as Perl Mongers, PerlMonks, and YAPCs
- Subscribe to mailing lists for projects of interest
- Own, or have read, great books like Perl Best Practices, Effective Perl Programming, or my own Modern Perl
Perl Programming Promotion
Second, the existing community of Perl developers can expand itself by finding novices and dabblers and encouraging them to continue their education in the ways of Perl. Part of that is evangelism, such as How to turn mediocre Perl code into elegant Perl code or How to take advantage of improvements in Perl. Part of that is spreading the message that discipline and education are the solutions to unmaintainable code. Part of that is expanding the boundaries of the existing Perl community to include the silent majority of people who've programmed Perl to demonstrate how their lives can be easier when their code is shorter, simpler, more robust, safer, more secure, more powerful, and easier to understand and to maintain.
One important step is to promote all of the wonderful language extensions available on the CPAN—not that you must use Moose or Moo or whatever to be a good Perl programmer, but that the tools are available for you to use when they help you.
As with almost every other programming language, Perl is only as difficult as we allow ourselves to make it. I believe the Perl community has done a great job in the past few years helping the world's best Perl programmers become more productive. Now we have the opportunity to spread that outside of that community.
A Word about Programmer Salaries
Of course, if you are trying to hire someone to write software that's essential to your business and you're not willing to compensate developers effectively, you're going to have trouble attracting good developers. You don't necessarily have to break the bank on salary; benefits such as working remotely, profit sharing, contributing to free software, allowing time for refactoring, et cetera may all make your business more attractive to good programmers.
If, on the other hand, you treat programming as if it were assembly line work (as if programming were merely the act of transcribing business requirements into code by rote), you're going to get what you deserve: mediocre software written by low bidders.
Great post..
Okay, lots of dead tree ordered. What's the ETA on epub?
In my experience one of the biggest problem companies trying to find great Perl programmers have is that they don't have any yet, don't understand Perl and thus don't know what is needed for great Perl. This in turn doesn't only mean that they don't know what to look for, but are also unwilling to provide.
The last year i spent looking for work here in germany and most companies had various ideological defects that made me not want to work for them:
- using Perl 5.8.8 or worse, 5.8.6 and NO inclination to update, ever
- flat out lying about CPAN due to ignorance: on phone: "sure, use CPAN!", in situ: "you can install anything that's in the package manager of our 6 year old linux version" and the best one: "no, we won't put a c compiler on these machines, you write perl, don't you?"
- requiring coding styles that mandate copy-pasting code because that's how the company founder worked for 15 years and nobody works faster than him
- unwillingness to admit that their code needs refactoring along with improvement or it's only going to get worse
- zero interest and even outright distrust in automated code quality tools like Perl::Tidy or Perl::Critic
- viewing automated tests as a waste of time
Not Perl-related, but also a problem i encountered often:
- zero willingness to help with relocation or to arrange a remote work situation
A discussion on #perl raised the observation that "if you haven't bothered keeping up with current trends and modern thinking in the last ten years, then no you don't have ten years of Perl experience; you simply have one year ten times over."
So there are people like you chromatic with, 10-15 years of experience who know a few things about Modern Perl as well. For that experience they expect a nice paycheck and even if *they* would be ready to work for a lower salary companies will think they are expensive or that they are "overqualified".
I think part of what many companies are missing are those 25-30 years old people with 2-5 years of real experience with Modern Perl.
To illustrate LeoNerd's point, have a look at the discussion of the post by a published IT author: http://everythingsysadmin.com/2011/01/python-is-better-than-perl6.html
Most of the reasons the puts forwards --while he acknowledges being a Perl fan-- come down to being stuck on Perl from a long time ago...
C
Alternatively - how can I find a good Perl job/contract if live in a small South Pacfic country?
I pretty much agree with the entire article, especially the comment about "... difficult to hire great Perl developers because it's so very easy to become a mediocre Perl developer."
In my experience with Perl (since 1994 and 4.036) there are lots of medium and large systems built by non-expert Perl programmers, and because they were able to achieve so much they never were pressed to become or bring in experts until things get really bad, and in at least two major situations I've seen that point come only when the Perl systems are being end-of-lifed.