Perl career progression
daniel at rimspace.net
Mon Sep 8 20:24:13 CDT 2003
On Tue, 09 Sep 2003, Nathan Bailey wrote:
> Daniel Pittman <daniel at rimspace.net> wrote:
>>Architecture and design are *hard* problems, as evidenced by the
>>majority of modules in CPAN.
> This does, I think, depend on how you factor out your code. We tend to
> factor out any major functions into modules, because then we can have
> test harnesses that unit/integration/regression test the code (cf.
> XP). This means that anyone coding is likely to make a module, just
> like anyone coding is likely to use subroutines.
...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
> Agreed, they will do it to varying levels of effectiveness, but I
> think it's a fair expectation for a graduate to be able to code in
> subroutines and put those subroutines into a module -- possibly the
> use of the word 'architect' here is disingenuous, since (again in our
> context) we tend to have several people involved and its likely
> (expected?) that junior staff will be operating under the direction of
> senior staff (i.e. semi-mentoring relationships, but not formalised in
> any way).
That answers the question: you expect them to be able to write a Perl
module to the specification of a senior person.
>>You expect more management for a "developer" than any company I have
>>worked for, but I think the fault is the title -- your expectations
>>there seem to match more closely a "senior developer" or "team leader"
> I think it's terminology again
*nod* That was my feeling for a lot of this, I guess, and if you want
it to be useful in a broader scope, you are going to need to fix that.
>>You have a few technology specific requirements at the higher levels.
>>It would be quite possible to do everything else at the "senior
>>developer" level without ever having touched HTML::Mason, for example.
> Yup, HTML::Mason is a specificity which I would remove if I was
> publishing this at a broader level (or add "competing" technologies
> such as embperl, HTML::Template, etc).
"Template Engines" or "Content Management Systems" are probably what you
mean here, I think.
>>Likewise, you assume that XML and related technologies are used
>>everywhere, for every job, which is not true. Some places still use
>>other technologies as they remain more appropriate. :)
> 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.
If you need a strongly structured, weakly typed format at both ends, XML
is your best choice.
Something like ASN.1, DCE-RPC or CORBA (despite the respective pains) is
great for strongly structured, strongly typed remote data.
Most things do better with a simple loosely structured, loosely typed
ASCII based, line oriented protocol like SMTP, in my experience.
> I think XML will continue to be relevant because of web services
> (which will be relevant even if you're not "web" programming, e.g. EDI
> kind of stuff), but for anything else, I would rather encourage
> Data::Serialization of hashes or similar approach.
I don't, because it ties you to a single vendor for your solution. That
is very seldom a good thing, because your quick hack IPC method becomes
something that I have to replace with a Java based fizz-bang solution
and that has to unpack your IPC, five years from now. :)
> Perhaps the limitation of a document such as this is that it
> necessarily depends on one's view of what "good" perl programming is,
> and where perl *programming* mostly happens (which in our case, is
> biased toward the web).
Yes, very much so. The document isn't very general. It wouldn't cut it
here at QHRS, for example, because we don't use most of your
technologies or not in the same way you do.
 Well, SGML is, but that is both out of fashion and poorly
reinvented by the XML movement. Oh, well.
 Insert the fashionable technology of the day.
Hocine Bibo Aut In Eum Digitos Insero?
More information about the Melbourne-pm