the "no good Perl jobs"/"no good Perl programmers" myth

[David Cantrell]

On Sun, Aug 06, 2006 at 11:23:45PM +0100, Nicholas Clark wrote:

> Most of the "developer" jobs that mention Perl as one of the key skills seem
> also to want HTML, CSS and JavaScript.

My impression is that a lot of them want experience in such things,
especially in HTML, but that they don't require them. Nor will the
day-to-day work involve them much if at all.

I imagine that by avoiding such things you are trying to avoid being a
webmonkey.  Which is understandable.  But lots of the time people are
just using HTML and friends as a convenient front-end for their internal
applications.  It's cheaper and easier in a lot of cases to develop for
the HTML platform than for the (eg) Aqua or .net or gtk platforms.

>                                        Most appear to be for small companies
> - either "act as lead on developing/maintaining our company website" or
> "work for our business that makes websites for other people". Making websites
> doesn't really interest me, but that's because I don't like writing user
> interfaces, possibly because they consist of lots of independent simple
> problems.

I don't like writing user interfaces, but I have pretty much always been
happy writing apps which have HTML interfaces.  And if I *do* have to
write a user interface, like, say, a quick mock-up for demoing-to-
manglement purposes, I'd rather do it in HTML than in Aqua or GTK.

>           I like complex problems that resist decomposition.

Likewise, and lots of apps with HTML front-ends are like that.  Take
drawing graphs, for example.  Yes, there's widgets and stuff for
inputting data and defining captions.  But the VAST majority of the work
lies in pulling all that together and spitting out a pretty image.  That
problem very much resists being broken down.

As an aside, it's a damned interesting problem too, and I recommend that
everyone solve it at least once.

>                                                         Small companies
> aren't useful, because I'm interested in the computer technology, rather
> than their line of business, but they make their money from their line of
> business (rather than writing their website in (say) Smalltalk
> ( http://www.seaside.st/ )) Hence to do their job well one needs to be
> excited (or at least sated) by their core business, and one can't expect to
> have an career progression without moving on.

I'm not sure I want to be excited by my employer's business.  That would
lead to me working through the weekend instead of getting sunburnt at
gigs (yay free beach gig last weekend).  I'd rather do the really cool
stuff on my own time, because then I'm under no pressure about *which*
cool stuff I do on any particular weekend.  Provided I don't find the
employer actively annoying (sorry banks, I mean you) I don't particularly
mind what data I'm processing.  It could be to do with health-care (like
it is now) or waste management or farming.  Ultimately, every IT group
everywhere has data coming in, is expected to transmogrify that data to
something else, and to do it in a certain time-scale with certain
constraints.

So I don't really write health-care software, I write data manipulation
software.  I can still spend some work time learning new stuff though,
because my employers always want it faster and with more features.  I
think that by my *not* being excited by health-care my employer
benefits.  I don't get easily side-tracked at work into "ooh, that would
be a shiny medical edge-case to deal with".  Instead I get side-tracked at
home into dealing with all the weird and wonderful ways in which you can
phone your aunt.  I think my employer likes me not getting side-tracked
on his time.

-- 
David "wookie for hire in London" Cantrell