Listen

This week I spoke at the Midwest JS conference in Minneapolis, Minnesota. It was a lot of fun and I had a chance to meet a lot of smart, talented people. All of the time leading up to my talk, though, was a bit nerve wracking; this was the first “professional” talk I'd ever given.

The talk was based around the idea of how Meteor—the namesake of my work at The Meteor Chef—functions as a 10x multiplier for the skills of front-end developers. To make that concept sink in a little better, I decided to equate the experience of working with Meteor to gaining superpowers, thus, the talk ended up being called “Meteor: Superpowers for JavaScript Developers.” I loved the basic concept and title, but I had next to no idea what to say or how the finished talk would look. More importantly, I struggled to find a conclusion.

As these things tend to work, I left Chicago on Monday with a half-finished talk. The basic pieces were there, but it was lacking a spark. Something that the audience could hang their heads on and send them away excited about Meteor from a different point of view. I was stumped.

The day after arriving in Minneapolis, I was invited by a fellow Meteor developer and TMC reader to hang out and grab a drink or two. It was more or less an opportunity to meet a like-minded developer and unwind a bit after work. He brought along a friend who had also been working with Meteor and after a few drinks and a chance to get to know one another, the topic of conversation switched to what I'd be talking about.

I explained the synopsis I shared above and also explained that I'd tailored the talk to not showcase any code. When I said this, Charlie—the guy who invited me out—uttered in so many words that this was a mistake. The comment bruised my ego a bit, but I listened. He continued, explaining that the coolest thing about Meteor was the code and the simplified process around writing it. I sniffed at the thought a bit and then realized: he was right. Meteor was cool because of how you went about working with it and the results you could achieve with it so quickly.

As we wrapped up and said our goodbyes, I walked to the light rail station (Minneapolis' train system) thinking how I could rewrite the talk around this idea, showing just enough code to make the point Charlie underscored and still keep everything under my time limit. Arriving back at the hotel, I took a look at the talk and started ripping pieces out. When I sat down that night I had nearly 70 slides.

After I spent the next day rewriting major chunks of the talk and working in a quick demo, I was down to ~40 slides. Not only was the timing right, but my talk finally had that flow I was after. It made a point and it made it (fairly) well. Charlie's comment saved my ass and the talk. Had he kept to himself or I chose to ignore him, things wouldn't have worked out nearly as well as they did; the talk went off without a hitch.

The moral, of course, is clear: listen. Hear people out and look at criticism of your ideas carefully. Disagreement is perfectly fine, but don't let that turn into immediate dismissal. Weigh all of the opinions carefully and consider what suggestions might look like in context. Given the right idea, it might just save the day.