SPUG: Job Titles for Perl (and more) Programmers

Aaron West 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."
> Josh
> 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.
>> etc.
>> --t
>> _____________________________________________________________
>> 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...
Name: tallpeak.vcf
Type: text/x-vcard
Size: 120 bytes
Desc: not available
URL: <http://mail.pm.org/pipermail/spug-list/attachments/20121027/6b2669e9/attachment.vcf>

More information about the spug-list mailing list