Perl career progression (Was: Perl work at Monash)
Nathan.Bailey at its.monash.edu
Mon Sep 8 20:03:37 CDT 2003
Daniel Pittman <daniel at rimspace.net> wrote:
>Architecture and design are *hard* problems, as evidenced by the
>majority of modules in CPAN.
*grin* Yes, well...! :P
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.
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). Perhaps it is all this subliminal context that makes the
document less useful for others, but then that's why I find this
discussion very constructive and hope to improve the document :-)
>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 -- depends on who the 'key stakeholders'
are -- in this case, rarely likely to be the ultimate business owners,
and more likely to be a mostly internal audience, it's really more a
measure of autonomy -- you are able to ensure the project is
successfully completed and contact the necessary people to ensure it
is. The other ambiguity is in scale of projects, perhaps I should add
a glossary at the end that defines these, since I expect my definitions
are much smaller than most would expect (I'm guessing industry
expectation of medium project being perhaps 6 months long with 3 or 4
people = 18+ person months?).
>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).
>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." 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.
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).
More information about the Melbourne-pm