SPUG: Job Titles for Perl (and more) Programmers
tallpeak at hotmail.com
Sat Oct 27 13:19:11 PDT 2012
"Database Developer/Reporting" according to my agency.
"Data Analyst" according to my coworker, who's been trying to keep me
I use using Perl and Oracle these past two weeks. (Haven't done much but
setup stuff and complain about how badly written the old perl modules
are and how confusing the database is).
I've been bragging to the best Perl programmer in the area at work (I'm
guessing) that I've not been sure whether I'm a perl-fan so much anymore
these last few years, preferring instead to have a fascination with
functional programming languages (eg. OCaml, F#, Haskell, Haxe, Scala,
maybe Erlang, Clean-language, ATS), but that is a sort of programming
idealism that is hard to explain to people at work. Essentially, I think
software should be as close as possible to "provably-correct" or even
proven-correct (as in the seL4 Linux-like "verified" operating-system
kernel, http://www.ertos.nicta.com.au/research/sel4/ ), and I think
strong-typing and rich type-systems like Haskell's are a step in the
direction of development of such software.
But programming-language idealism aside, Perl is very utilitarian, and
may be the best tool for the job of running ad-hoc and scheduled reports
against databases in a minimal amount of code, so I've been finally
learning some basics that I've ignored in the past, like how to use
packages and modules, and objects. I know, "duh! How could you call
yourself a perl programmer if you don't know those basics?" Well, I
wrote Streetpulse's import system in Perl in 2005, and a couple of
scripts a few hundred lines long with very little to no modularization
were far superior to the old ColdFusion scripts, so it worked well
enough for my needs without knowing/using o-o or packages/modules.
As for o-o perl, the idea of blessing a hashtable to magically turn it
into an object has felt rather foreign to me. Perhaps I should be using
Moose just to give any classes I may create a consistent declaration
I suppose if I want to be a programming-language idealist, I should
install Perl 6 (Rakudo) and start using that. I've installed it, but
probably won't use it in the immediate future. I don't know who is going
to take the plunge and actually adopt Perl6 in a substantial way, but I
suppose it could achieve critical mass sometime in the next few years. I
think it may take either adding a few killer features or developing some
killer libraries that actually need Perl6 features, before serious
adoption begins. For example, some sort of object/relational database
interface, or a language-integrated query like LINQ or perhaps like
HaskellDB. I think important parts of future software will be higher
levels of abstraction and virtualization of services, and the
database-interface should be abstracted-away as much as possible.
I think Haskell might be usable to develop efficient multicore software.
But again, programming-language idealism aside, Perl is very utilitarian
and I'm enjoying getting back to doing a little of it.
Hopefully I'll pick up some speed, and though I have never yet been what
I would term a prolific coder, I'd like to approach that goal now.
Perhaps if I design my vision for a reporting system for my department
completely-enough up-front then I'll have something very usable in a few
months, with a moderately-sized code-base. Maybe I'll even read a few
books (for a change) to help develop some coding styles. I want to use a
combination of functional and some O-O coding styles, and ideally design
a DSL or some high-level perl modules. One thing I think I'll want to
do is abstract away the joins in the database, because it seems to be
overly hard to construct queries due to a set of awkward relationship
Eventually I want to work on ERP and/or workflow software.
implementation and/or integration... this is related to an idea I've had
for over a year, but that's another story...
(I might) Consider Clean-Language's workflow system as a possible model
to imitate or start with.
I was thinking, for example, how when I join a company through an
agency, I may have to use 2 or more time-recording (timesheet) tools,
and how workflow management system and client application could
eliminate that necessity.
On 10/27/2012 8:13 AM, Joshua ben Jore wrote:
> Most places I know just call this sort of beast a "Software Engineer."
> Amazon will stuff it up a bit with "Software Development Engineer."
> On Fri, Oct 26, 2012 at 3:16 PM, Tyler Hardison <tyler at seraph-net.net> wrote:
>> So I'm trying to get a poll of what people's titles are. Particularly
>> if they're primarily working in Perl, SQL, Web, and engineering?
>> Even more helpful if you're forced to work in other languages such as
>> those out of the evil empire®.
>> Mainly I guess I'm trying to define what I do in an all encompassing title:
>> Linux SysAdmin (Only as needed for setting up dev environments)
>> Can compile Perl from scratch as needed.
>> Understands threads.
>> Uses Moose.
>> Can whip up a Dancer app front-ended by nginx for SSL.
>> Can debug a .NET app if I'm help at gunpoint.
>> Can take a spec from a customer and wow them.
>> Understands Agile.
>> Seattle Perl Users Group Mailing List
>> POST TO: spug-list at pm.org
>> SUBSCRIPTION: http://mail.pm.org/mailman/listinfo/spug-list
>> MEETINGS: 3rd Tuesdays
>> WEB PAGE: http://seattleperl.org/
> Seattle Perl Users Group Mailing List
> POST TO: spug-list at pm.org
> SUBSCRIPTION: http://mail.pm.org/mailman/listinfo/spug-list
> MEETINGS: 3rd Tuesdays
> WEB PAGE: http://seattleperl.org/
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 120 bytes
Desc: not available
More information about the spug-list