So a little back story. One day at work I discovered a problem in PHP, so I filed a bug report. I eventually fixed the bug, and my fix was included in PHP 5.3.3 and 5.2.14. I figured, “Hey this would be a great topic for a talk!” So I gave a talk at NYPHP about how to file and fix a bug in PHP. It bombed.
It bombed for a few reasons. So let me turn my bad talk into a hopefully good blog post, about things not to do at a user group talk.
Lesson number one is don’t give an advanced talk at a user group. The problem with advanced talks at user groups is that there is one session and one talk at a user group. Not everyone in the audience is capable of digesting a one hour talk on that particular advanced topic. This is not an insult to anyone’s intelligence, most people at a given user group could eventually be made to understand your topic, most probably lack the prerequisite knowledge. My talk would have gone much better at a multi track PHP conference, because I’d only get people that cared about my topic.
Lesson number two is giving a talk that involves mastery of an “off topic” language or technology at a user group is a bad idea. Note that I say mastery not knowledge or awareness. PHP is written in C. You need to really grok C (read: be able to clean up your pointers) to contribute to PHP. However, most PHP programmers don’t know C. I even stated in my slides “I cannot make you a C programmer in one night.” I really should have known better. To use another example, I’d be very wary about talking about CLR procs at an SQL user group because most DBAs don’t know C#, or another CLR language. You can’t write a useful CLR proc without mastering .NET. Giving a talk on CLR procs to a .NET user group could work because most .NET programmers have a basic understanding of T-SQL. As another example, you can probably give a beginner level powershell talk to a SQL user group. Its pretty easy to get a DBA from never used powershell before to making ADO.NET calls in an hour, especially if you focus on doing it with SQLPSX.
Lesson number three is be careful about a war story inspired talk. You might come off as just ranting, or even worse, like I did. Some people, like Sean McCrown, can rant well. People clamor to hear people like Sean rant. People don’t like to hear me rant. I can’t deliver a rant in a way that makes my audience feel involved like Sean does. I realized this at the time I was preparing for my talk. I said things like “the PHP SOAP module is a pile of crap,” and “the PHP community ignores people who submit actual patches.” However, I tried to do it in a non-ranty Dale Carnigieish way. However, all that emotion lurked below the surface during the talk. When I rant people normally see an angry little nerd getting caught up in some stupid detail that doesn’t matter. In this case I spent my talk actively avoiding going into rant mode, like your friends puppy fresh from obedience school that fidgets anxiously in front of you at a slight distance, obviously wanting in his cute little puppy heart of hearts to jump on you and give you a proper puppy greeting. Since I lacked the time to emotionally distance myself from the BS I had to go through to get this bug fixed, my audience saw an little nerd that was angry about something. They were kinda confused. Lessons learned, if you can rant like Sean, rant away. If you rant like me, make sure you can emotionally distance yourself from the topic at hand.
Could I make this talk work if I tried again? Perhaps, but I am not that interested. I gave a non-technical talk on contributing to MongoDB at MongoDC. (This post is now NoSQL as well as UnSQL. Double Rainbow all the way!!) That was well received, but had a small audience, and one of my audience members felt 10gen wasn’t open source enough. So I guess lesson number four is no one wants to hear a talk about how to contribute to an open source project. If they want to contribute, they will.