Improving Railsconf

How can Railsconf be improved? And by that, I can extend, how can computer tech conferences like this be improved?

To answer that question, you have to back up and ask something more fundamental. Why do people go to conferences? Why are conferences set up to begin with?

I'll start my answer with Railsconf. Railsconf is about Ruby on Rails. To have a conference, especially on a language or platform, and have it every year is a measure of success for the language or conference. In other words, if you can get a bunch of people to show up for it each year, then what the conference represents has some degree of success.

One reason for a conference is to show interest in some field. I suppose there are side benefits. It may make money. It may give face time to key speakers.

But why do the attendees go? That's a more difficult question. When I was thinking of going, I was wondering how experienced people would be with Rails. On the one hand, Rails has been around less than three years, so no one could be that advanced (having said that, people do pick up stuff quickly). On the other hand, how many people would spend several hundred dollars to attend a conference that they didn't do any work in? In other words, how many people are like me?

I'll say I didn't go completely ignorant as if it was something like, oh, say, Erlang. I've heard of Ruby for years now. I've heard of Rails for a year and a half, and even heard Dave Thomas talk about it. Last year, at ETECH, I sat and listened to DHH give a tutorial on Rails. Despite all that, I realized I didn't really follow what Rails was about, and with the conference, I'm gaining a better perspective on it. I finally read a chapter or so of the Agile Development in Rails, the book written by Dave Thomas and DHH.

This brings me to my first suggestion for improvement. First, there's going to be a wide variety of people coming to Railsconf. Sure, not many raw beginners like myself. Someone suggested that there be a beginner's track during the conference, aimed at folks like myself, and I think that's a good idea. The question is how much overhead is involved in running a special track.

Each lecture was maybe 50 minutes long. For some talks, that's just the right length. For others, it's not long enough. Say you want to have something that's more like a tutorial, like digging into code from Scriptaculous. Is 50 minutes enough to get a sense of what's going?

And some stuff, it's almost better to do than to watch. The problem is having the audience keep up. The tutorials are pretty good for that, since they last a few hours. The problem is, even though many people bring their own laptops, not everyone brings the same one (though there were a ton of Apples). It might be too much to expect everyone to set up their computers to run, say, Textmate.

But my real point is that sitting as passive audience members makes the experience less enjoyable. I know, I know. The logistics of having something participative is awful. This is why colleges use lectures too. English discussion groups are tiny, usually having only 20-30 people tops, so that more people have a chance to speak.

Do people want to learn in this fashion? Perhaps this is too much to expect from a conference. Maybe with such a size, it's better to have people hear a bunch of ideas, and take what they can use, even if they can't remember it all. Again, as Ze Frank pointed out, we remember the emotions of a conversation, not the content.

I found the BOFs to be interesting because one thing you don't get it a sense of where everyone is coming from. I sat in a BOF about bioinformatics. There was a sophomore attending Rails! And he was doing something like bio! What the hell was he doing there? Actually, I didn't get a chance to ask him that, but I was curious about why he was there, and this is something I wouldn't have known by sitting in a lecture.

One reason I liked the tutorial was an incredibly short interlude (about 15-20 minutes) where Jim Gay and I worked on his Mac coding up a new tiny feature in Ruby. Neither he nor I were that experienced, but we muddled our way through some of the code, and got something to work. Now, I knew what I did wasn't completely TDD approved. In particular, I made a bunch of changes without testing it right away after each tiny change.

But once we did that, and Dave and Aslak began to do their editing, we could see where our approach differed from theirs, and that was very instructive. I was also able to speak with Jim (the few times I could find him) and Paul (his biz partner) which I'm sure I wouldn't have done if we hadn't done the pair programming.

Other things. Well, the food wasn't that good. We had box lunches each of the several days it was held. By contrast, No Fluff, Just Stuff had food for all of us catered (probably by the hotel). There was chicken, cuts of beef, salad, bread. Very nice. They had coffee at every intermission. Not so many places to sit and rest, and no wireless, so maybe that's the tradeoff.

I'd suggest a few rooms for teaching sessions. There was a comment that the Rails community should give more, especially to beginners, and so this might be one way for people to contribute to others attending the conference. Have pair programming sessions, for different topics, and have people move around to work with various people.

Perhaps there should be a "Ruby" or "Rails" quiz session where puzzles are given to people to work on, and clever solutions are presented.

I'd like to see it more interactive.

Hmm, well, if I think of more ideas, I'll blog about it.