in search of excellent conference presentations
At OSCON this past year, I was a just little surprised by the still-shrinking Perl track. What really surprised me, though, was the entirely absent Ruby track. I tried to figure out what it meant, and whether it meant anything, but I didn’t come to any conclusions. Even if I’d more carefully collected actual data, I’m not sure I could’ve made any really useful conclusions.
Instead, I came to a flimsier, wobblier conclusion: the Perl track could have more, better talks that would appeal to more people, including people from outside of Perl. I spoke to some OSCON regulars about this and nobody told me that I was deluded. When I got home, I asked a few people whether they’d ever considered coming to give a talk at OSCON. I got a few replies something like this:
I hadn’t really, but maybe I should. What would I talk about, though? Talking about stuff I do in Perl wouldn’t make sense, because OSCON isn’t a Perl conference.
OSCON is an interesting conference. It’s ecumenical — or it could and should be. In practice, though, it can be a bit cliquish. I was disappointed when I first saw lunch tables marked as the “Python table” or “JavaScript table.” I was told (and believe) that people asked for this sort of thing as a way to find people with the same interests, but I think that one of the most interesting things about OSCON is the ability to talk shop with people whose shop is quite unlike your own. It leads to interesting discoveries.
This only works, though, if you really talk about what you really do. If I said, “Well, I filter and route email with a lot of Perl and a little C,” nobody’s going to learn anything interesting from me. On the other hand, I could tack on a few more sentences about the specific problems we encounter and how we get past them. “High performance, highly configurable email filtering is stymied by the specific ‘commit’ phases of SMTP, so we’ve had to spend a little time figuring out how to do as much rejecting as early as possible, but everything else as late as possible.” Once you’re talking about specific problems, people can relate, even if they don’t know much about the domain.
Hearing about interesting solutions to problems can often help me think about new possible solutions to my own problems, so what I like is to hear people talk about their specific solutions to specific problems. I seek these talks out. I’ve basically given up on talks like “The Ten Best Things About Go” or “A Quick Intro to Clojure.” They can be interesting, but generally I find them wishy-washy. They’re not compelling enough to get me to commit to doing serious work in a new language, and they don’t discuss any single problem in enough detail to inspire my to rethink things.
So I think that, in general, talks about really specific pieces of software are
the best, and that means talks about software in Perl (or Python or Bash or
Go…) because that shows the actual solution that was made. Most of these
talks, I think, would be interesting to all sorts of people who don’t use the
underlying language or system. If you work on an ORM in Python, would a talk
on DBIx::Class be interesting? Yes, I think it could be. Could a talk on
q.py be useful for just about anybody who debugs code? Yes. And so on.
I’m really hoping to see some interesting real-problem-related talks show up this year, and plan to go to whichever ones look the most concrete. I also hope to give some talks like that. Talks like that are my favorite to give, and I look forward to spending more time talking about solving real problems than talking about abstractions.
OSCON’s call for participation tends to come out in January. That should be plenty of time to think about our most interesting solved problems!