The Free Love-, er, Teach-In

[Richard Jolly]

On 12 Mar 2007, at 11:10, Ovid wrote:

> Just a follow-up:
>
> We might have a venue for the teach-in.  I'm working on nailing that
> down now.  Dave Cross has volunteered to teach it.  The main issue is
> that I was envisioning something that would help competent Perl
> programmers -- those who understand packages, references, OO syntax
> (though not necessarily OO) -- become top-notch programmers that
> companies would kill to hire.

Just a vote for this. In my experience there are a large number of perl 
programmers in this category. They know the syntax (though probably 
don't mess with the symbol table much), write tests (but maybe not the 
best ones), use version control, use CPAN modules (but don't write 
them), use OO (but with lots of intermediate procedural bits), etc. But 
is it done well? Are they the right objects? Are the right methods 
implemented? How can you tell? The syntax is there, but not the design 
skills.

I count myself among this group.

> Dave was thinking more along the lines of teaching some basics such as
> strict, warnings, references, etc.
>
> I think both classes would be useful, but on a purely selfish note, I
> want the the former class to be taught because those are the
> programmers we need.  When I've chatted with other companies, that's
> also what they're looking for, but it could easily be a selection bias.

My reasons are selfish as well. I want to learn something - but I also 
see this often enough to think it's a common problem. Also at my $job 
we don't have beginners, so it wouldn't be immediately applicable.

> Is Dave's idea of a class really (beginner to intermediate) more
> important that the (intermediate to expert) idea?  So long as we nail
> that down, everything can move forward.

I'm sure this is useful too. But are there many companies that have 
either a shortage of intermediate perl programmers, or need to train up 
novices? Personally I'd rather see more excellent perl programmers 
rather than more intermediates.

Richard