bdf> It's not hard to get a Perl job. It's just hard to get one
bdf> where you are probably.
What I've noticed is that jobs tend to fall into a few categories.
Startups founded by business-types who think they can contract out
development usually use something Microsofty, Java, or ColdFusion,
because that's what their highly-paid consultants told them to use.
Startups founded by technical types tend to use whatever language the
developers think gives them the most advantage in the problem domain.
This may not have any correlation with what is actually likely to give
them short- or long-term advantage, and usually is biased in favor of
languages and frameworks the developers already know.
Startups that have become profitable tend to stick with what's worked
for them, because the cost and risk of reimplementation is so high.
Startups that are failing tend to thrash around, and "rebuild the
whole thing from scratch in another technology" is a common move; if
it works, they become profitable, and if it doesn't, they continue
thrashing.
Older companies (and organizations such as universities) for whom
software development is a cost center rather than a primary reason for
existence tend towards whatever's been tested and proven, with a
healthy dose of glossy magazine lore, corporate FUD, and risk
avoidance ("nobody ever got fired for...."). You're likely to find
lots of Java and Microsoft in those companies; if there's any Perl or
open-source Unixlike technology going on at all, it's either because
the CIO doesn't know it's there or because the CIO trusts his
sysadmins even though they're using such a subversive anti-corporate
software stack.
Consultants tend to focus with one of Microsoft, Java/J2EE, or LAMP,
with diverse interpretations of 'L', 'M', and 'P' in that last
acronym. Consulting companies can either specialize in one of the
three or diversify.
So if you want a Perl job, you really have four basic approaches:
1 - Become a founding member of a startup where technical decisions
are made by technical people and not managers, or join such a startup.
2 - Work for a small profitable company that got that way using Perl.
3 - Consult.
4 - Work for a large organization that doesn't necessarily realize
it's using Perl.
Options 1 and 2 require networking; startups don't advertise, and
small companies don't advertise much. Location is also critical here.
Option 3 requires either marketing yourself or joining a reputable
consulting company. Smaller consulting companies have the same issues
as option 2; larger consulting companies have the same issues as option 4.
Option 4 is the most visible one you're likely to see on job sites,
but it's also the one that's likely to be the least satisfying. In
some cases, "Perl" gets thrown into a list of 20-odd languages and
technologies that they consider "nice to have"; other times, they
throw in "Perl" because they think they might want someone webbish
and,hey, Perl is webbish, even though everything else in the company
is Java or Cobol.
(I worked one job where "Perl" was prominently featured in the job
description, and was actually used quite a bit in the company, but the
actual job I was hired for involved PHP - my manager thought they were
the same thing. He displayed a similar level of cluefulness across
the board. And I worked another job at a startup where they were
pouring horrendous amounts of money into trying to get ColdFusion to
do the right thing. I went in thinking, hey, small company, obviously
broken software, they might be amenable to switching platforms; but
they had paid six figures for a bunch of consultants to build the
software, and they had invested another six figures into getting it to
work, and after that level of investment there was no way management
would admit that they had made a mistake, especially in such an
obvious way as changing development platforms.)
Charlton
