Perl career progression (Was: Perl work at Monash)

[Timothy S. Nelson]

On Tue, 9 Sep 2003, Nathan Bailey wrote:

> Okay, so the common theme appears to be "too narrow" which is good feedback,
> except not specific enough to move forward/improve :-)
> 
> I do think SQL stands on its own, in the sense that you are unlikely to
> write perl *applications* without some kind of database interaction,
> regardless of the webness of it.  And the intention of the progression
> is more towards perl *programming* than perl *scripting*, the later
> which could equally well be done in a combination of sed, awk and grep,
> for example (and would usually not involve writing a new perl module).

	I've only once ever done any database stuff with Perl, and I didn't 
use DBI because at the time, there was no module for Interbase.  I'm a sort of 
half-scripter, part programmer thing.  The main thing I've done in Perl 
recently is the system which generates our invoices.  Here's something that 
*should* have a database on both ends, but unfortunately, the input data is 
logged in a flat text file (which other functions currently depend on), and 
the other end is in a M$ Access DB, and can't be moved away from M$ Access.  
However, I'm recoding the M$ Access DB to have a MySQL backend, and then I 
will finally, for the first time in my life, have a use for DBI :).  

	I think the only simple solution to this argument about what's needed
to be a good Perl programmer is to pick a few items as "core items", and have
the others as a sort of "associated skills, tick the relevant columns" sort of
thing (in which I would put XML and SQL).  For example, none of my Perl in the
last two years has been connected with the Web (or SQL).  I don't know, but I
would assume that the Bioinformatics people don't do the web either (but lots
of DB stuff).

	Versatility probably ought to be "Field knowledge" or something -- 
only the first 2 or 3 seem to be versatility.  

> technologies frequently used in perl be sufficient?  Two good examples
> from David were messaging (IMAP, NNTP, SNMP, Jabber, etc) and
> directories (LDAP et al).  I don't think incorporating LDAP skill

	I think your SQL and XML columns could be "sample extra" columns, and 
you could let other people add their own as necessary.  Otherwise everyone 
will disagree about what needs to be added :).  Perl, being the glue, touches 
just about everything else, but not for everyone :).  

> expectation of medium project being perhaps 6 months long with 3 or 4
> people = 18+ person months?).

	...the mythical person month :).  


Daniel Pittman wrote:
> ....and do you trust the low level programmers to decide what is and
> isn't in that module, and what the public interface is, or do you tell
> them that?

	The smart thing to do is to let them design it on paper, and then 
discuss it with them.  Maybe they've spotted some difficulty that makes their 
way best.  If you discuss it with them afterwards, they might see what they've 
done wrong, and the kind of thinking necessary to do this kind of thing.  
http://www.reciprocality.org/Reciprocality/r0/  (The Programmers Stone).  I 
don't think the Programmers Stone guy is 100% right, but he's got some 
interesting ideas.  

> > Damian once said "Never use XML if you own both ends of the pipe." 
> 
> Damien Moore?  Anyway, that's not a great argument, I think.

	Damien Conway.  What other Damien is there in a Perl context :).  

	:)


---------------------------------------------------------------------
| Name: Tim Nelson                 | Because the Creator is,        |
| E-mail: wayland at smartchat.net.au | I am                           |
---------------------------------------------------------------------

----BEGIN GEEK CODE BLOCK----
Version 3.12
GCS d+ s:- a- C++>++++$ U++ P++ L++ E- W+++ N+ w>--- V- Y+>++ 
PGP->++ R !tv b++ DI++++ D+ G e++>++++ h! y-
-----END GEEK CODE BLOCK-----