Ben Scofield

We’re rapidly approaching November, which means that another NaNoWriMo is almost upon us. NaNo’s provided that last little push for tens of thousands of novelists over the past ten years. Given its success, I’m very excited to see that some people are experimenting with the format, and are trying to bring some of that inspiration to other disciplines.

The most recent issue of the Pragmatic Programmers‘ magazine contains one of those experiments: PragProWriMo. Instead of 200k words of a novel, participants in PragProWriMo are asked to commit to writing 80 pages of a technical book. The scope’s a little smaller than NaNo, but it’s still a significant challenge for people willing to undertake it – and it could possibly result in some exciting new technical books down the road.

There’s also been a bit of chatter on Twitter about something like a NaOSSWriMo – starting and releasing a substantial open source project in November. I’m really excited that people might undertake this challenge, as we’ve seen what talented individuals can do in two days before… what more could someone accomplish with thirty days of intense effort on a single project?

So, if you’ve got the time in November, why don’t you rise to the challenge of one of these projects? Or, if you’ve got something else in mind, start posting about it now, since you never know who else might get excited by it and join you for the month.

I’ve seen one particular complaint about Ruby conferences fairly often over the past couple of years – people question why the same speakers tend to show up at every event, often with the same (or only gently modified versions of the same) talk. Having organized an event specifically intended to combat that trend, I’ve got some thoughts on the subject.

Firstly, few people (relative to the size of the community as a whole) submit proposals. When the available speaker pool is small, you’re bound to get a number of repeats over a conference season.

Secondly, many speakers just aren’t very good, which turns selecting talks into something of a crap shoot – some speakers are known to provide good, high-quality talks consistently, but most others are a gamble, with poor content or presentation skills. As a result, the known-good speakers are invited to and accepted for more and more events (which, as a side-effect, allows them to hone their skills and get even better), while the less-known speakers are left to lightning talks and other, more local venues (like user groups).

So, how do we fix this? Here are two suggestions:

Submit! If you’re nervous about speaking at a conference, start small – with a presentation to your co-workers or a local user group. There’s a nice path from local, focused events up to national and international conferences if you just look for it. The more people who submit, the more variety organizers have to choose from.

Get better! This is a natural consequence of the former, but it’s certainly possible to improve as a speaker without having regular opportunities to present. There are a number of resources (books, blogs, etc.) that can help with all aspects of the presentation process. Heck, you could also just ask speakers you respect for their advice – most will be more than happy to provide feedback.

Last weekend, I was out in Boulder, organizing and MCing for our last Developer Day of 2009. It was an exciting conference, bracketed by the first snow of the year for Boulder (and the first snow I’d ever seen in October), but luckily the vast majority of the attendees were able to make it safely into town – we only had one person (that I know of) turn back due to the road conditions.

Those who did make it in were treated to a great set of talks, including Chad Fowler’s keynote on creating a remarkable life, Derek Chen-Becker’s in-depth introduction to Scala, and Jeremy Hinegardner’s exploration of some tools that make it easier to work in a multi-language environment. Jeremy’s presentation in particular was interesting for me, since he discussed several of the databases prominent in the NoSQL movement – and in fact, I gave a lightning talk version of my comic domain modeling talk to add a little more color to the picture he drew.

All in all, this was probably the best Developer Day so far, and I’m very excited to start planning the 2010 series. Look for Developer Day in a city near you next year!

Disclaimer: I’ve said some of the things in this post, as have some of my friends, some of my acquaintances, and some people I don’t like. This is a fairly widespread phenomenon, but it’s one that I’d like to see fade away.

I’ve mentioned a few times that I’m doing a lot more speaking now, so I’ve spent quite some time looking at conferences and the chatter around them. As a result, I’ve seen a ton of people saying that conferences suck, which I find almost universally disappointing. At the very least, all conferences have the potential to be great experiences; what we get out of them is directly related to what we put into them. To see how this works, I’d like to tackle some of the reasons given for conference suckage.

Presentations suck

It might not be immediately obvious how effort-in improves results-out for presentations – after all, it’s generally someone else doing the presenting. That’s the root of the problem, though; the way we improve presentations is by giving them, and giving them better. There are a lot of reasons that the average quality of technical presentations is lower than we’d like, but improvement starts at home. Submit, speak, get better.

And don’t forget the power of constructive criticism. Use whatever feedback mechanisms the conference provides to let the speakers know what they did well and what they should work on. Also consider more general systems, including sites like SpeakerRate (shameless plug!)

Panels suck

OK, so I agree with this one – but panels are hardly the only type of session at a conference, and I’m still guardedly optimistic about the format itself.

Cliques suck

I’ve not noticed this particular complaint as much recently, but it has certainly been a factor at times, with RejectConfs, CabooseConfs, and other events springing up as counter-programming to more “mainstream” events. Every group of any significant size has cliques, and particular ones will usually form around events. Cliques aren’t even necessarily bad, as long as the members are mindful of their culture and are open to the potential of people outside their group. To the extent that particular cliques are exclusive and elitist, that’s a problem, but conferences are at least minimally democratic; if you don’t like how events in your community are run, then start your own, or help others who are already running an alternative.

Venues suck

This was particularly evident when Railsconf 2009 moved to Las Vegas, but I’ve seen it with any number of events – there’s not enough to do near the hotel, or there’s too much, or the city is perceived to be unsafe, or it’s too bland… The litany of complaints about conference venues is nearly endless, and people sometimes get extremely worked up about locations. What confuses me about this problem is that (with few exceptions, like SXSW) the conference isn’t inextricably tied to its location. If you’re unhappy with the city, fine – attend and deal with it or don’t, but don’t assume that conference organizers ought to consult your personal preferences before booking a venue. After all, they’re planning a conference, not a group vacation to some cool city.

Complainers suck

The common thread with all of these reasons is that we as attendees, presenters, and organizers of events need to stay aware of the fact that we make up the conferences we attend. If you’re not getting value out of an event, you have two choices: stop attending it, or work to make it better. Neither of those includes complaining incessantly without doing anything constructive.

http://www.flickr.com/photos/betweenloveandlike/
CC BY-NC-ND 2.0

I’ve been to a lot of events over the past few years, and I’ve drawn a number of conclusions about various sorts of presentations. One of the most universal of these is that panels suck*.

If you’ve been lucky enough to avoid panels in the past, let me enlighten you: a panel consists of a group of people (generally 3-5) who sit up front and answer questions posed by a moderator. The panelists can be united by a number of traits – people who’ve worked in the same domain, dealt with similar situations, competed in the same competition**, etc. The idea behind the panel is that it allows the audience to hear multiple perspectives on that commonality; if your panelists all work in academia, for instance, they’ll be answering questions about the unique characteristics of that environment (“Are university politics different from private sector politics?”)

Embedded in that description is a set of problems that combine to make panels incredibly difficult to do well.

1. Multiple presenters are difficult to handle at the best of times – the flow of a presentation is very easy to disrupt if personal styles differ, and panels make that inevitable. The only way I’ve seen to manage multiple presenters is to have them practice together repeatedly, and that can’t happen with panels, which tend to be more conversational. People step on each others’ sentences, or withdraw entirely and look disinterested in their fellow panelists.
2. There’s no right way to address questions. The moderator could ask each panelist the same question (since the point is to get their different perspectives), but that becomes incredibly boring for the audience – and if you avoid that, then you’re missing the point of those different perspectives.
3. If the topic is broad, then you’re going to get an incomplete view from each panelist. In that case, it would be better if they each gave a full presentation of their own. I’ve never experienced the opposite scenario, where the topic is very narrow and each panelist says his or her piece on it entirely, but at that point the topic might be too narrow to be of any real interest.

So, how do we fix panels? Or do we even bother?

I think that, for the most part, we should strive to eliminate panels of the sort I’ve described from conferences. They’re usually massively unproductive, and contribute mightily to the hallway-trackers (people who say conferences suck and they only go for the hallway conversations). There may be one exception, however: a panel might work if the panelists are all telling the same story. An instance of this would be the founders of a company telling how they got started and grew – or a project team describing their process. This sort of case-study panel would be much more natural, as we’ve all experienced group storytelling (even if it’s just a couple describing their vacation), and so the panelists wouldn’t interfere with each other as much. This could be a multi-subject interview (with a relatively active moderator), though that could run into some of the same problems that the normal panel exposes; it might be better just to eliminate the moderator entirely and let the panelists just tell their story.

Whether that’s a better approach or not, one thing’s for sure: I’m definitely going to avoid your typical panels at events I attend in the future. What about you?

* I’ve been on a panel, and yes – it kind of sucked, too.

** I suppose you could have a panel where there’s even less of a common thread among the panelists, but that’s the stuff of my nightmares.