A few years ago when I was getting started on my first decently sized OO application I picked up the Gof book. I was very excited about it and started what I called then "patterns meetings". It was an informal discussion about design patterns that eventually went into many other topic areas including language idioms (mostly C++ at the time), Robert Martin's OO design principles, etc. My employer at the time would buy lunch for us to encourage participation.
Many people turned out for the first meeting; some left when they learned that they had to do additional study on their own, but some stuck with it and the meetings had a small following for several years while I was there. Eventually I left the company, but the meetings continue under the name LunchnLearn, led by EricRunquist.
While I don't consider myself a guru of OO, I know that I started several developers, some more experienced than myself, down the OO path and even mentored them in this area. I feel great satisfaction in having started this culture there.
I want to encourage others at other companies to take up the flag of moving this profession of software development ahead by leading a LunchnLearn at their own companies. I'm convinced you'll find it will be one of the most worthwhile things that you'll do in your software career. Don't worry about being an expert from the start. I've learned a great deal by facilitating these meetings both about software development and about people. I know that I've grown as much or perhaps more than the people that participated in these meetings.
I hope others share similar experiences they've had and perhaps some tips on how to or how not to go about this endeavor.
The Basics
The Lunch-and-Learn program is still going strong. In 2000 we did meetings every other week. In 2001 we shifted to having them every week, more or less. Topics fall into several broad categories:
Keep It Going
I've found that the best goal for organizing Lunch and Learns is to make the continuation of the program the number one goal. In other words, I don't worry about how good or bad a particular meeting is. If I can just keep things going, they will get better over time. So far this strategy has worked. This also adds predictability. People don't have to ponder whether we have a Lunch and Learn this week, because we have one every week.
Web Access
The meeting schedule is on our company Intranet. We have pages with instructions for ordering food, how-to's for preparing a meeting, instructions for setting up conference calls, etc. All materials needed for a meeting are posted on the site by the morning of the presentation. A separate page contains the history of all previous meetings, along with links to the associated handouts, slideshows, etc.
Scheduling
To make the L&L schedule you need triples of (Date,Person,Topic). In 2000 and 2001 I focused on finding the Person and Date first. This consisted of going around the office and personally begging people to put their name on the schedule. They got to decide on the Topic whenever they wanted. This was more of a supply-side scheduling technique (the suppliers being the presenters).
For 2002 I organized things differently. I focused on the Date and Topic first. We had two organization meetings in early January. At the first one we tried to do a "schedule merge sort". We divided up into pairs. Each pair had a blank schedule, a bunch of paper slips containing possible topics, and a glue stick. After each pair finished their schedule, the pairs merged into groups of four, and collaborated to merge their schedules. This repeated until we had one schedule produced from about 20 people in 3 offices. I put this final schedule on a Wiki page on our Intranet. The second organizational meeting consisted of people volunteering themselves, and others as candidates to present each of the items on the schedule. By focusing more on what people want to hear about this is more of a demand-side technique (the consumers being the meeting attendees).
By the way, if you try this "schedule merge sort" technique, give some serious thought to using something other than glue sticks and little slips of paper. It took a lot of work to prepare the little slips, and the glue did not allow the slips to be moved from one schedule to another, as it dried too fast. The format did force people to express what they want, and also got people to talking.
I think this technique of focusing on the demand-side, instead of the supply-side will make my life easier as an organizer. All I have to do is email all the candidates for a given week and let them decide who will do what. We have the entire 2002 year scheduled by mid-January, except for occasional gaps to absorb overflow.
I added a line on the schedule for each date labeled "Meeting Suggestions:". I'm hopeful that people will take advantage of the Wiki-ness of the schedule and add suggestions for the meetings.
-- EricRunquist
No, this page is not about FoodAndDrinks