While I don't mind talking technical things over lunch, I firmly believe that (en)forcing work-related things over lunch is a bad thing. I think that lunch should be a break from work and hence work-related stuff should only be brought up if it's really important (to you, obviously). You cannot expect the others to care (obviously) and I see the "never seems to go anywhere" underlining that.

If the issue is important to work, people will set aside time outside of lunch for it. You could try to arrange a workshop before lunchtime and then go to lunch together after the workshop to discuss the stuff (making the lunch some perk, like bringing in outside "special" food or even going outside might be something to keep the people together). But I'd try to avoid forcing the mixture of private/personal stuff and work stuff - it will only end in people rejecting the goal (Perl) for the wrong reason (they want to eat when/where they want and talk about what they want).

Corion,
Your comments are exactly the reason why I wrote this meditation. Due to contractual constraints, the exchange could only happen on non-duty hours. This means at lunch or after work. When I have brought it up in the past, there is always expressed interest that never materializes. These folks aren't against perl or learning, they have lives - I get that.

I don't like the idea of making the participation mandatory and when I expressed that to the team lead, he indicated his company would pay for the lunch. I don't see how that makes a difference but on the other hand, I don't want to waste this opportunity either.

I have two options. Refuse to teach while participation is mandatory or try and make it work. I haven't decided - which is why I posted the meditation. Thanks for your input.

Cheers - L~R

The difference to me would seem to be between "You must go to this on your off time" and "You must go to this on what's normally your off time, but we're going to try and make it up by picking up lunch". It's an acknowledgment that they're asking for extra and compensating for it (maybe not completely but at least making the gesture).

My hangup would be that a lunch hour sounds too short a period of time to cover "enough" (but that'd depend of course on how much you're trying to cover as well as how quickly the learnees are on the uptake). I tried a similar "Here's Perl" talk a couple jobs ago at the company meeting, but because of the time constraint it was a few slides of syntax, a couple on modules like LWP or IO::Socket, and then some pointers to where to learn more. But again, that's dependent on what you're trying to cover and they might let you have several sessions so it could be moot (just tossing it out there though).

I don't believe free lunch can lure people into learning Perl. How much does a sandwich lunch cost? It certainly does not worth anyone's private time.

I guess that company is in a regime where people have no basic human right.

The company for which I work has a history of giving "lunch and learn"s - they spring for some free lunch, and people who are interested in the topic watch the presentation, and eat some food. It seems to work well at the home office, where they're so kind as to film these sessions and then send the video to remote offices, including the one where I work. So at my office, we watch these non-interactive videos, and get free lunch. I used to go for the free lunch, but then that started being less exciting.

Having gradually gotten more and more annoyed at the lack of certain best practices here, I decided to do something about it. During my last review, I had one of my goals as "Give presentations to other developers, introducing blah blah blah". My first was getting started with unit testing, functional testing, and how to use this cool module I created to actually make our custom template system* testable. And how to use a VIM plugin I wrote to write out a .t stub file with very basic, yet runnable tests created automatically by just hitting a few keys. My manager seemed excited about the fact that I wanted to do this.

It went pretty well. I think the people in the session were used to the non-interactive filmed variety, so it was a little hard to get them to interact with me, or laugh at the jokes I inserted into the presentation for a little brevity levity**. But afterwards, my manager said she heard lots of great comments, and was otherwise fairly effusive.

Furthermore, the call has gone out that they*** would like to see more of us take some initiative and present on other topics as well. I certainly know I've got a number of topics in my head that I would greatly enjoy sharing with my coworkers. After all, the better code they write, the less time I have to spend reviewing it ;-)

I think the key to doing this successfully is to have management buy-in, and for goodness' sake - have the company foot the bill for the food. It's not that much money and spreads all sorts of good will and team building.

Of course, it helps to have topics that are of (or, once they're seen) active, current interest to a number of coworkers, and I think it REALLY helped in my case to have a few items near the end of my presentation that really impressed my coworkers - namely how to write tests for our templates, and how to automate the creation of a test file stub so easily, and how quick and easy it was to flesh out the stubs to make the tests a bit more than superficially meaningful.

I'd recommend against any mention of the word "mandatory", but instead just entice them into attending by picking a topic and a title of the presentation sure to convey how relevant (and especially helpful to their needs) the topic will be.

If you have management buy in, and some positive feedback from the first one or two of these sessions, it can really turn into a great thing in my opinion. I'm certainly hoping it has that effect here.

* - Legacy code, long before my time, would much rather work with something else entirely. But, this is what we've got, so this is what we have to deal with.

** - Oops, a bit of a Freudian slip - I expected the laughing to go on and lengthen the overall time of the presentation. Thanks to Fletch and Limbic~Region for pointing this out.

*** - The powers that be, of course.

Update: While I was updating my poor word choice, I figured that I should mention that one of the best benefits is that I'm going to parlay my $WORK presentation into a Perl Mongers presentation, which I'm fairly excited about.

s**lil*;  $*=join'',sort split q**;  s;.*;grr; &&s+(.(.)).+$2$1+; $; =
qq-$_-;s,.*,ahc,;$,.=chop for split q,,,reverse;print for($,,$;,$*,$/)
[download]

Recently, I have been asked to help out in producing sanitized test data. It turned out to be a perfect opportunity to show of Perl's strengths (parsing and manipulating data). In fact, it has been so successful that the team lead of the Java developers has said that, if I was still willing to teach perl over lunch, he would make it mandatory for his team.

Whoa. Any time a lead says they're gonna make team attendance at some event mandatory, I worry a little. Better would be for you to offer a 20 minute seminar on how you did what you did using Perl, to give them a taste of what the language can do. Doing it over lunch is fine, but I would suggest persuasion would work better.

And at the end of your talk, ask if any of them want to outline how the same thing might have been done in Java. ;)

And at the end of your talk, ask if any of them want to outline how the same thing might have been done in Java. ;)

Oooh, that's really cruel!

CountZero

A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity." - The Tao of Programming, 4.1 - Geoffrey James

While advice over which topics to cover are appreciated, I am more interested in how to deal with the human element.

Kinda mixing the two together. Before you decide what to teach, canvas a few of the Java guys you get on with and ask them what bits of their day to day workload they most dislike. Chances are that there will be some mundane but essential, currently manual administrative tasks they have to do but find to be a PITA. If you're lucky, one or two of these will lend themselves to being automated using Perl.

If you can start your demo by writing something that has immediate benefit to their daily lot, you'll get an immediately enthusiastic audience. If you demonmstrate creating it in realtime, having carefully worked out your solution previously to ensure your demo goes smoothly, so much the better. The real trick here will be winkling out one or two good candidates.

By starting with something that their main language doesn't really lend itself to, you'll avoid coming across like you are telling them "Perl is better than Java". If you can do that, you may avoid some reluctance/resistance.

... having carefully worked out your solution previously to ensure your demo goes smoothly ...

Famous last words . . . :)

(Keep in mind one of the the corollaries to one of to Clarke's Laws: "Any sufficiently advanced technology is indistinguishable from a rigged demo." )

I know my demonstrations won't go smoothly, so I record them as screencasts ahead of time. I still manage to bungle whatever it is i'm trying to do while recording, but a little deft editing makes quick work of silly typos and "duh" moments while I'm trying to figure out why something that ought to work doesn't.


--chargrill

---

s**lil*;  $*=join'',sort split q**;  s;.*;grr; &&s+(.(.)).+$2$1+; $; =
qq-$_-;s,.*,ahc,;$,.=chop for split q,,,reverse;print for($,,$;,$*,$/)
[download]

That and a good free lunch would have me interested
Any room left?

Have you considered getting the boss to make it a weekend course? You can cover things more in depth as well it can be offered as a reward for good work. As well it can give the people in attendence a few extra days of pay.

As the mandatory attendence goes, that is good initiative however unless the manager can convey a positive outlook on the class. People will resist the training more.

I am a firm believer of giving everybody their lunch off. This allows them too cool their jets and recharge for the final shift.

The fact that the company is conducting extra training is an excellent idea. Scheduling it is the expensive part.

zer,
Unfortunately, the environment I work in is not homogenous. There are a number of different government organizations and contracting companies working under the same roof. There is no "boss" that could make the sort of decisions you are implying.

Cheers - L~R

Ya that is understandable.

It is possible but a lot of hard work. I have made it happen within the military. It is a headache of a paper trail

I'd be inclined to a pretty informal walk through of the highlights of the code that catalyzed the "seminar" with an intent of generating a series of "That's cool", and "Neat!". There's not enough time to really introduce the language enough that anyone is going to go off afterwards and write an opus using it, but you can flash enough neat stuff before them to stimulate some interest in following up. Treat it more as a question and answer session with a small number of natty code samples.

And of course when they ask where to find out more, you know where to point them. ;)

free lunch will be incentive

Just because nobody's said it yet... TANSTAAFL! :-)