Ben Scofield

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!

I create (or at least start) a lot of microapplications – my “Ideas – Dev” list in Evernote is huge, and I try to pick off a new one every few weeks (at least), so I’m usually working on something newish. This fact on its own isn’t particularly interesting, but what this practice has done is allow me to experiment with new things regularly and on a real project.

As an example, I’ve been using MongoDB as the persistence layer for several of these apps. Where before I’d have relied on MySQL (or, more rarely, SQLite), I’m now making Mongo the default – when I start up a new project, I yank out ActiveRecord and drop in MongoMapper. This has resulted in two important benefits:

• I’ve learned a lot more about how Mongo (and, by extension, other document-oriented database) work.
• I’m better at figuring out where a document-oriented database does and doesn’t work – I’ve had to replace Mongo on one application because it just wasn’t a good fit for the domain.

The exact same process happened when I started replacing Prototype and Scriptaculous with jQuery – I was able to dig down into the benefits and problems with it, and eventually make an informed decision about which library I wanted to use.

If you’re starting a new project, give a thought to changing one of your default settings. At worst, you’ll have to revert that change later if you realize that the original worked better, but even then you’ll have learned something valuable – and the chance to discover something new that works better is a huge win.

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.

There’s something very strange about the concept of follow-through. Ask a physicist, and they’ll tell you that nothing you do with the club after you hit a golf ball, or with a bat after you make contact with a baseball, has any real effect on the path of the ball. Nevertheless, coaches always emphasize the follow-through – often to the extent of downplaying the moment of contact. What’s going on?

The secret to follow-through isn’t that there’s some magic in the motion after the point of contact. The secret is that concentrating on the aftermath – making sure you get into the right position at the end of your movement – is the easiest way to ensure that you’re in the correct position at the crucial moment. As it turns out, it’s just too difficult to focus on all the factors in play at the moment of impact; the only way to reliably, successfully manage them is to focus on later moments, and rely on the laws of physics to get you from point A to point C through point B with all the right factors in place.

Interestingly, we do this in all sorts of domains, but the principle doesn’t always hold. When it breaks down, we end up focusing on the wrong things, thinking they’ll get us to our underlying goal. For instance, I recently read a blog post on ways to obtain speaking gigs. There’s nothing intrinsically wrong with wanting to speak at events, but I don’t know that anyone has it as the core goal for their life. We want to be famous, or to be respected, or to share our knowledge with the world – but we end up focusing on the speaking instead of that more fundamental aim.

Happily, the solution is simple: be mindful. When you’re writing our your goals, be they resolutions in January or things to do today, make sure you evaluate them against your fundamental aims. How does doing this or that contribute to your overarching vision? Are you locked in on an end for itself, or for some benefit you think it might bring along the way? And if it’s the latter, is the follow-through principle really the best method for achieving that benefit?