|There's more than one way to do things|
Re: Teaching perl over lunchby chargrill (Parson)
|on Jul 27, 2007 at 14:56 UTC||Need Help??|
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
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.
*** - 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.