Ben Scofield

Whew! In case you didn’t know, last weekend was the Rails Rumble – an annual, 48-hour sprint in which teams of 1-4 people build complete, functioning web applications from scratch. I’d competed in the two prior Rumbles (winning the solo division both years </shameless plug>), but this year I participated in a different way: I was one of the expert panelists tasked with judging the submitted applications prior to public voting. Surprisingly, I found judging to be at least as tiring as competing had been the previous years – the overall quality of submissions this year was noticeably higher than it’s been in the past, which made the evaluations that much more difficult.

As a panelist, I made a commitment to providing constructive comments on each of the applications I judged, as well as rating them on design and interface, completeness, innovativeness, and usefulness. I think I did a pretty good job with the comments; I’ve gotten thanks from several of the contestants for the feedback, which is nice. I wanted to clarify my particular approach to the ratings in this post, however, since it’s the most opaque part of the process of judging. Each of us on the panel has a different background, so my interpretation of, say, usefulness might differ dramatically from some other judge’s.

Design and Interface

When deciding what score to give for design and interface, I looked at several factors. Pleasant-looking sites rated higher for me than sloppier ones, and I gave a fair amount of weight to sites that went beyond a simple themed prototype look. Sites that used the standard error pages lost points, because that’s an easy place to customize and make your site friendlier and more usable. I tried to go easy on minor flaws, since those are bound to occur in such a limited time period – but at the same time, I tried to reward sites that put on those finishing touches.

More important than most of those factors, however, was message: if I couldn’t understand what a site was for, then its design failed. I ran across several sites that lacked the appropriate contextual help to get me to the finish line, which was a problem.

Completeness

This is a hard category to judge, because who’s to say if someone fulfilled their vision or not? Sometimes, it was easier – several teams made the mistake of talking about the features they wanted to implement but couldn’t, or pointing out broken functionality. Here’s a tip to future Rumble contestants: if you don’t finish something, don’t call attention to it. Fix it after the competition, but don’t advertise your failures to the judges.

Other applications had obvious problems – broken authentication and links, that sort of thing. Those were easier to pick out, but you always feel bad when that happens. At the same time, there were applications that gave me everything I could want and more.

Innovation

Here’s another tough category, though it’s not quite as bad as completeness. When evaluating innovativeness, I tried to figure out if the site represented something really new (either wholly original or a surprising revision, like putting multiplayer Asteroids on the web), or if it was Yet Another Twitter Filterer. The Rumble’s interesting because there are usually a few categories of application that have four or five entries – this year, it was stuff-tracking apps (I loaned you X, give it back), secret crush apps, and movie night planning apps. I tend to dock points if you end up in one of those categories, or if you’re a standard entry in an already crowded market.

Even if you move into a popular niche, though, you can still score highly on innovation. The key to doing so is trumpeting your differences – why are you better? Too few apps do a good job of that, even when they have something worth marketing.

Usefulness

My primary metric for evaluating usefulness is myself: can I see myself using this app tomorrow? Next week? Frequently? Rarely? Obviously, this doesn’t fit all sites, so when I’m not part of the target audience I try to project how they might feel about the app – and you could have an app that only needs to be used once to prove its helpfulness. This is the category where I’m most flexible in my ratings – partly because of the odd nature of the category, and partly because I feel it somewhat-unfairly penalizes games and other off-the-beaten path sites.

So, that’s how I did it. Hopefully this sheds some light on what can be an anxiety-producing process, and maybe even helps next year’s competitors (who may have me to contend with again – I was very jealous of all the fun that seemed to be happening over the weekend!)

Update

Jim Minatel has also posted his thoughts on being an expert panelist over on the Wrox blog. It’s nice to see how others were thinking, and I agree with a lot of what he said (though I’m of a different mind on the IE support).

http://www.flickr.com/photos/wwworks/ / CC BY 2.0

Practice makes perfect – anonymous

When I was back in school, I did a lot of different things. I played a musical instrument, I programmed computers, I played volleyball, I studied foreign languages – and the key to getting better at each of them, I was told, was practice.

So, I practiced. With some skills, I got better. With others, I didn’t. And because I was young and foolish (as opposed to being older and foolish, which I am now), I thought that there was something about each domain that made it more or less amenable to improvement via practice. Some things, I thought, only get better through performance, not through practice. In those performances, I tended to mess up, but I got better after each one.

What I didn’t realize at the time is that I was just practicing incorrectly – and that was turning my performances into public practice sessions.

People who write about spring training not being necessary have never tried to throw a baseball – Sandy Koufax

If you look for it, you can find a huge amount of literature on practice. It seems cyclical; every few years, another cluster of books hit the shelves and articles hit the newspapers (or, more recently, the blogs). The interesting thing, though, is that there’s no central practice section of the library – people write about it in every sphere. One of my favorite books on the subject is George Leonard’s Mastery, which uses the martial arts as a lens onto the role of practice in the journey to mastery. Chad Fowler’s The Passionate Programmer is more recent, and is also very good – discussing (among other topics) the role of practice in software development.

There are a few books that investigate the role of practice more generally. One of my favorites of these is Talent Is Overrated, by Geoff Colvin, which has the benefit of bringing in stories of the power of practice across many domains (be sure to read the section about Ben Franklin and his wonderful, obsessive practicing of the art of writing).

The common thread among the best of the books that deal with practice is the concept of deliberate practice. This, it turns out, was what I’d failed to appreciate in school.

Practice is the best of all instructors – Pubilius Syrus

Deliberate practice is as different from indifferent practice as cross-country running is from walking. The key is twofold: choice of practice materials, and attention. If you’re exclusively practicing things you already know how to do, you’re not practicing deliberately. If you’re not paying attention and actively striving to learn from your practice sessions, you’re again not practicing deliberately. The goal is to stretch during practice – attempt to do something new, and pay close attention to your performance so that you can see where you fall short. You should come out of a practice session tired, because intense focus is exhausting. You shouldn’t succeed at everything you attempt during practice, because that means you haven’t been practicing the right things – or your standards are too low.

Practicing the right way is hard – which only makes sense; if it were easy, everyone would do it, and we’d see a lot more excellence in every field. Nevertheless, for many of us, it’s worth it. Excellence (or mastery) in a field is one of the finest goals we can aim for, and practice is really the only way to achieve it.

I’ve noticed a bit of a trend among some conferences lately – they’re outsourcing/crowdsourcing talk selection to (usually, but not always) the attendees. The most recent example was Ignite Raleigh, but the precedent for all of these is, of course, SXSW. For the last several years, SXSW interactive (and, starting this year, SXSW music and film) has allowed anyone to vote on submitted panels for inclusion in the conference.

One of the effects of the panelpicker process is that submitters flood the internet with pleas for votes – and I’m no exception. I’ve submitted two panels:

• Mind Control: Psychology for the Web – This will be a much-expanded version of the talk I gave at Ignite, in which I describe the heuristics we use to make our way through the world, how they both work and fail in the online environment, and how we (as designers and developers) can use that knowledge to get people to do what we want them to do.
• Difficult Domains: Alternative Databases for the Web – This will be the updated version of my “Comics” Is Hard talk, which I’ve presented at several events. It’s fun to continue speaking about this topic, because the state of the field is changing very quickly. New key-value stores are popping up daily, it seems, and there are dramatic changes afoot in the document-oriented database realm. Heck, Neo4J just released a new version, as did MongoDB! Exciting times, my friends…

So, there’s my call to action. Go, vote ‘em up! And while you’re there, the other Viget proposals would like some love, too.

This past weekend was exciting, because it was the first instance of Developer Day held away from Viget’s and Relevance’s home territory – we took the show on the road up to Boston, with a lot of help from thoughtbot and the Microsoft NERD Center (which, incidentally, is an astounding space). It was both a lot of work and a lot of fun (at least for the half I was able to see; a minor emergency forced me to leave after lunch, so I missed the excellent afternoon talks), and I’m excited to continue taking Developer Day to places where smart people are doing good work.

I’ve posted a general recap over on Viget Extend, with comments from some of the attendees, so I’ll spend the remainder of this post recapping my talk: “Comics” Is Hard: Alternative Databases. I gave this talk at RubyNation a few months ago, and thanks to the feedback I got there, I was able to shift the focus a bit more towards what people wanted to see, with some great results (based on the SpeakerRate response). I’m very excited to see the talk continue to evolve, as I’ll be giving it again in Chicago in a little less than a month – and beyond that, hopefully it’ll inspire people to take a look (or another look) at alternatives to the traditional relational database model. There’s a ton of exciting work going on with key-value stores, document-oriented databases, and more, and I think they’re much more generally useful than the mainstream currently appreciates.

And with all that said, here are the slides!

As I mentioned before, I’m thinking a lot about technical presentations and speaking more generally now. As part of that, I’ve had some fun discussions with friends about the different kinds (both content and format) of presentations, about practice, and about related topics, and something interesting has emerged from those talks: the presenter’s pentathlon.

The basic idea would be to bring together five or six presenters and run them through a series of events designed to test their speaking prowess. The events might include things like:

• A fifteen-minute prepared session on a topic of their choosing,
• A five-minute Ignite-style presentation, again on a topic of their choosing,
• A five-minute session of presentation karaoke, where they’re given one of the other presenter’s slide decks to speak from,
• A ten-minute talk without slides on one of a set of topics, provided twenty minutes or so before they hit the stage, and
• A ten-minute presentation done with a predetermined set of slides, provided an hour before they hit the stage.

We could spice it up by designating one of the talks as adaptability challenges, making something go wrong partway through (projector dies, persistent heckler in the audience, etc.) I think it’d be a lot of fun, for both the speakers and the audience (who’d be judging the performances – perhaps with a live-feedback system à la televised political debates?)

So, who’s with me? Let’s get ready to rumble!