Mark Freedman’s Blog

Archive for the ‘Tutorial’ Category

This post is dedicated to my father, who passed away on 12/5/2009. He was a wonderful father and husband. He made friends with everyone he met. He taught me so much, and always had faith in me. I miss him terribly. I love you dad. You’re in a much better place now.

I wrote my original series on running a code camp after running my first one back in 2007. As of now, I’ve been involved in the running of four code camps, and have learned a lot of lessons over these years, so it’s time for an update.

This first post will list my guidelines for the preparation steps. It assumes you’re already involved in running a user group. I’ll follow up with posts about running things on the day of the event, and then follow-up steps to be done after the event.

 

Pick a Date

Check for other events in your area. Check with user group leaders, local regional directors, local Microsoft Developer Evangelists, other members of the development community, and sites such as Community Megaphone to make sure that your event won’t overlap with others in the area.  Also make sure you pick a date at least a few months out.  You’ll have a lot of work ahead…

Get Help

The number one rule – do not try to do this yourself! There is no way to successfully run a significant event without the help of others. In addition to our core team (including Leo Junquera and James Simon), Leo and I recruited our wives to help, and James brought in help from his staff. In addition, we reached out to some of our members to help on the day of the event.  Make sure you reach out for help at least a few months before the event.

Find Mentors

In addition to getting help, if you’re not very experienced in running a code camp, getting input from experienced facilitators is invaluable. We were fortunate to have the support of Peter Laudati and Bill Zack, who helped run the code camps for the NYC .NET Developer Group. Don Demsak, experienced with his NJ events also provided some valuable insight. I think it also helped that I was present early at some NYC code camps to help a bit with their preparation, and to observe some of the steps they had to take before the events began.

Pick a Venue

If you’re running a user group, you may already have a venue that’s ideal for a code camp. If not, the costs could increase a lot, and you’ll need contributors to make this work. We’re extremely fortunate that we can use the facilities at UCONN. Virtually every room is equipped with projectors and white boards, so the speakers can basically just plug in and power up.

If you are able to get a facility like that, you’ll have one less thing to worry about.  Otherwise, you’ll have to rent or borrow projectors for each track, and would possibly need to find a different location with several rooms to use, preferably large enough to fit a minimum of 25 to 30 attendees each. Try to get at least one room that could fit 50% to 75% of the total expected attendees for the introductory and closing sessions, which you can also use for the anticipated most popular track.

Reserve the rooms several months in advance if your facility books quickly.  We missed out on our favorite room this year because someone already grabbed it.

Create a Website

Obtain a URL for the sole purpose of the code camp. Try to get one with a similar name to your user group site, and definitely cross-link. This is where you should post the original announcement, the "call for speakers" announcement, the eventual the list of speakers / sessions, the session schedule, presentation material, and all other info pertaining to the event.

Although this site doesn’t need to be anything fancy, try to get a basic one up and running at least a few months before the event.

Event Registration Site / Account

For the first couple of code camps, and for all our user group meetings over the first couple of years, we used the Microsoft Group Events site to create invitations. But we were having trouble with the site a couple of months before this year’s event, so I searched out alternatives. I found Eventbrite, which, quite frankly, blew away the Microsoft Group Events site in functionality and usability (hint, hint, Microsoft).

Add the code camp event to your list, and set the enrollment limit up to 50% higher than the amount you can handle (and the limit you may publicly state). We allowed for 215 enrollments this year, and about 140 showed up. The Eventbrite site also makes it easy to generate reminders and follow-up emails to people who registered, and it looks professional. We’ve been setting this up about a month before the code camps, but I think we’ll be setting this up about three months prior to let our user group members get first crack at registration (see next section)…

Make a List

Once you’ve gotten the support in place, make a list of everything you can possibly think of that would be needed – every action step, from beginning to end. You can use these articles as a checklist. Here’s a partial example of the checklist we used. I sent out an updated version of this list on a regular basis up until the day before the event.  You can see that there are plenty of small specific sub-steps that aren’t necessarily obvious from the high-level checklist in this article.

Call for Topics / Internal Announcement

About two months before the event, you may want to ask for community input on the topics they would most like to see. We tried this the first year, but we didn’t make the process as easy as we should have, and didn’t get the feedback we’d hoped for. We’ll likely create a poll for this next year. You can use something like Google Docs, with a multiple choice form over a spreadsheet. Or if you want better control over each person only voting once, you can use a site such as Survey Monkey.  If you’re a developer, you may be tempted in rolling your own for the tools I’m recommending, but you’ll be so busy as it is, I suggest making use of the free tools already out there.  If you still have the itch, roll something after your first couple of code camps to at least get some solid background experience under your belt.

If you do decide to do this “Call for Topics” step for your user group members, you should combine it with the “internal announcement” to give your local community the first shot to enroll before opening it up to the general public. Remember — this is for the community, by the community. Send out a mailing with links to the poll and to the registration site (also done easily with EventBrite).  Post a special announcement on your user group’s website which should already be cross-linked to the code camp website, and announce it at user group meetings.

Call for Speakers

About six weeks before the event (or about two weeks after gathering the “Call for Topics” poll results), send out a “call for speakers” announcement to all the people on your mailing list, known speakers in your area, other user group leaders in your area, local regional directors, and local Developer Evangelists. Blog about it, post the announcements on message forums frequented by your targeted community (if it’s allowed by the forum), tweet it, and ask others to blog about it. In the announcement, if you were able to get community feedback, suggest those topics as “high-interest”. Additionally, suggest topics that reflect current industry interests.

I strongly recommend setting up an input form to capture this data. We’ve done this via email in the past, but no matter what instructions we give, the responses are never consistent. Save yourself some time with something like a Google Docs form (see below). I wanted to do something similar with Microsoft Office Live, but nothing like that was available as of this writing (another hint, Microsoft). Capture the speaker’s name, email, phone, session name, session description (including target audience level and background), and a bio. The phone number is important. I made phone calls to several speakers a couple of days before the events to confirm and make sure there weren’t any unanswered last minute questions. Email is great, but sometimes lost in the shuffle, and when the deadline approaches sometimes a phone call helps close any loops.

Call for Contributors

Although code camps are traditionally cost-free to the general public, they are not cost-free to run. Your costs will include food (including a speaker dinner, which I strongly recommend), and if you don’t at least feed the attendees a developer’s lunch of pizza and soda during a long day of learning, you’ll have a lot of very grouchy, inattentive techies – not a pretty site . Your costs could also include use of the facility. Although we were lucky enough that CITI at UCONN was willing to let us use the facilities for the most part, in exchange for publicity about their programs and a questionnaire on the back of our evaluation forms, due to the economy we still had to pay for the use of the largest room this year. I don’t see that changing anytime soon.

These costs is where sponsors are your best friend, although due to the nature of code camps, they aren’t really considered sponsors – they’re more like contributors. Local companies can be extremely helpful in this regard.  Reach out to all potential contributors at the same time you send out your “call for speakers” (six weeks prior).  We waited too long this year, and had to really scramble the last few weeks.

Normally, software vendors are great for contributing swag in exchange for posting info about their products on the code camp home page. Several popular and upstart development tool vendors gave us software licenses to raffle off.  But when you need their help to actually fund parts of the event, you may need to offer the opportunity to present their products during lunch.  Telerik was a huge help for us in this regard this year.  You can bring on a vendor for each track (room), if you need to.

Microsoft has also had a generous budget for supporting community events like these, and they’ve basically covered most of our food costs and plenty of swag.  It should go without saying that if your code camp centers around Microsoft technologies, definitely get your regional Microsoft Developer Evangelist involved from the get-go.  If your event focuses on another platform, work closely with the equivalent support teams from those vendors.

One final note on this – developers love books and software, but aren’t crazy about recruiters at such events, so save them as a last resort.

Swag for Raffles

On a related note, try to secure swag to raffle off at the end of the event. We all love books and software, and it’s a lot of fun giving this stuff out. User groups should all be aware of, and make use of a very valuable resource – the User Group Support Services site.  In addition to many other development community services, the UGSS can provide you with regular shipments of swag for your user groups and related events.

In addition to the software the vendors contributed, this year we gave out so many books, we ended up not even raffling the rest off. We just let people dig through the books at the end. Granted, many of the books were a few years old — leftovers from the UGSS overstock. But most of it was still relevant. In exchange for the software we give out, we post vendor info on our code camp website, and hand out promotional material.

Address Security Concerns

If you’re planning to use a secure facility, at least a month prior to the event, make sure that the local security or police department is aware that the facility will be used on a weekend. Arrange to have the facility opened in time (I strongly recommend 1.5 to 2 hours before the opening session) to prepare for the event, and if the doors lock from the outside after a period of time, make sure someone could monitor the doors so nobody gets locked out, or leave a cell phone number so they can call someone to get back in. If there’s a period of time after which the doors are locked, be sure to state this in the information details when people sign up, since people often arrive late.

Public Announcements

About two weeks after the internal announcement (a month before the event), now that your core community has had ample time to register, start publicizing the code camp. Contact other user groups, tell other bloggers, contact community leaders and local publications, and ask people at work to tell their friends about it.

Choose the Sessions

If you can gather input from your membership before the code camp, it will help you narrow your selection, especially if you receive several proposals from multiple speakers. We had 24 sessions and 17 speakers apply this year, several with multiple session proposals. Because we were able to accept all the speakers, we only needed to pick a handful to do two sessions each. When choosing the sessions, we take into account all of the sessions in order to provide a good balance. We try to avoid having anyone speak for three sessions. I think that would burn out anyone by the third session, and you always want to end the day on a high note.

Create Session Tracks and Schedule

This will be the most difficult step of all your pre-event activities.  I can’t stress this next point enough – do not worry about making specific topic tracks. Just don’t. We tried doing it the first couple of years, although Don Demsak warned me against it. Trying to coordinate the schedule is painful as it is. The first couple of years I wanted to make sure we had the right mix in each track, and kept adjusting the track descriptions to keep things even. Trying to do that on top of trying not to have well-known speakers present at the same time as new speakers (to make sure that established speakers weren’t grabbing all the attendees), and trying not to place well-known speakers opposite each other, is just too frustrating. Bottom line — I learned not to worry about it. We always had to adjust the schedule for one reason or another on the day of the event, anyway, which throws some of your precise planning out the window.

It turned out that we never really had anything to worry about. Most sessions were well attended, the balance was pretty even, and I don’t think any speaker felt shortchanged. I guess we initially tried over-architecting this . Don’t forget to schedule breaks in between sessions (10 minutes works well, but it also depends upon your facility layout), as well as an introductory general / breakfast session, a closing session for raffles, and lunch.

Session Scheduling Considerations

This year, I focused more on making sure that anyone who had to do two sessions had a single session break in between. In addition, anyone doing two sessions would do those over a three-session period, limiting how long they had to stay and allowing them to focus on their turn to speak. This gave speakers the flexibility to arrive late or leave early, or to sit in on other sessions. It also gave them time to rest and prepare for their second session, and just to get a "breather" between the two.  Again, that may seem like over-thinking, but I’d put a higher priority on this than on making topical tracks.

You may also consider scheduling a speaker who needs more preparation to have their session right after lunch or first thing in the morning. This will give them an hour or so head start.

Once you create your initial Code Camp Sessions Grid and Code Camp Speakers and Sessions document, email them to all the speakers. You will get requests to shift things around.  This will likely occur up until the last few days. You’ll also probably get updated bios and session abstracts. Always keep the speakers in the loop with updated versions until you have to print them out for the handouts.

Session Length

Speaking of the session schedule, one of our biggest mistakes the first year was the fact that we only allotted an hour to each session, which turned out to be barely adequate. Part of the reason we did this is because we wanted to avoid turning down speakers who volunteered, and wanted to put in as many sessions as was feasible. For the next two code camps, though, we lengthened them to 1:15 each, which seems to be fine. In order to fit an 8:00 AM to 6:00 PM day, we do four tracks of six sessions each, giving us a total of 24 sessions. Including the 15 minute intro session, the 10 minutes between sessions, the half hour lunch, and the half hour closing session with raffles, you can see from the sample grid that this fits 8:00 to 6:00 perfectly.

Call for Presentation Material

One thing we’ve failed at doing was getting the speakers to email us their presentation material a couple of weeks before the event.  We’ll try that going forward to avoid the mad rush of download requests after the event. I don’t expect this to be easy though, because many speakers like to tweak their presentation up until the last minute. They may even need a couple of days after the event to make any corrections, etc. But the more you can get up front, the better.

Another reason I’d recommend this is because it can be very difficult getting some speakers to submit their material after the event.  They’re already on to their next tasks.  If someone could suggest how to make this easier, please let me know.

Speaker Preparation Email

A couple of weeks before the event, I recommend sending out a speaker presentation preparation email, which includes the dinner invitation.  I have to thank Judy Calla, leader of the Central Penn .NET User Group, for many of the speaker recommendations listed in this email.  I also link to an article of tips I wrote a while back.  As I mention in the email, although many of the speakers may be experienced technical presenters, some of the guidelines may still be helpful.  I think they’re great reminders, and worth reviewing before any speaking engagement.

You may want to combine this email with the “call for presentation material” step.

Room Monitor Instructions

As I mentioned earlier, you’re going to need a lot of help on the day of the event.  This year, we recruited a few of our members to help as “room monitors”.  In their role, they help the speakers connect to the projector and the Internet (if needed), and provide them with 15 minute (Q & A time) and 5 minute (wrap up time) warning signs.  They also announce reminders at the end of each session about the evaluation forms and end-of-day raffles, etc., as the attendees walk out.

About a week before the event, send them instructions to print.  You can use a version of the document we used as a template.

Post Schedule and Session Details

About a week before the event, the sessions, speakers and schedule should be pretty close to where they’ll end up, so it’s time to post this info on the website. Create web pages for each, in addition to PDF versions people can download (and what we’d hand out at the registration desk).  Make sure to keep these updated, and specify the “last update time” on the site for each, so attendees know what to expect, and can plan their day.

This is also the time you can start creating and printing the rest of the material you’ll need to post on the walls, and to hand out…

Large Session Schedule Grid

Print a large version of the session schedule that you can hang on a wall near the registration desk. For each session, print the title and speaker on a separate sheet of paper in a large font. Also print row and column headings on their own pages. I recommend painter’s tape for posting these without damaging the walls or leaving residue.  It’s great for all your sign postings, also.

Room / Track Schedules

Print a single sheet for each room to show which sessions will be held at each time period for that room. You should post these outside the door of each room.

Directional Signs / Floor Plan

You should investigate the layout of the venue beforehand, in order to know what signs you’ll need to print for directing people to each of the rooms, the food, and the restrooms.  Bring some blank pieces of paper and some thick markers, in case there are changes on the day of the event (there almost always will be).

If possible, create a map or floor plan for the facility that you can include in your handouts.  We didn’t think about this until the last minute this year, but we’ll start doing this next year.

One final thing that would have helped us tremendously this year – if possible, I strongly recommend posting all these signs the day before the event.  We were running around like chickens without a head trying to post them before the first session began.  We weren’t done until after the second session, and there was already some confusion.

Feedback Evaluation Forms

Design a feedback form to allow the attendees to rate each session over several categories. There should also be a space for comments about the sessions, and the event in general. We also include a questionnaire on the back of the form to capture data to help the facility sponsor. After all, they provide us with the facility to use for the code camp and the user groups. I think this is a good idea in general for any facility you may use. It can be placed on the back of the form so it’s not obtrusive, and almost everyone who handed in the form to us actually answered the mostly yes/no questions. You can download a copy of our evaluation document as an example of such a form, and to use as a starting point for your own. Print out copies to include in the information packets.

You may be wondering about creating an evaluation feedback page on the Web, instead.  I don’t recommend that for a couple of reasons.  First of all, most facilities used for free events such as code camps don’t necessarily have enough publicly available bandwidth to allow people to do this real-time.  Secondly, out of site, out of mind – if you expect people to rate the sessions after they return home, you’ll likely be disappointed.  Nor will they necessarily recall exactly how a session went.  Your best bet is to allow them to fill out a form the old fashioned way, as soon as they possibly can.  It’s not that difficult to tally these afterwards.  I have a pretty good system where I take care of this over a few hours.  I’ll discuss that in part three of this series.

Session Schedule Grid Handouts

Print out copies of the session schedule grid to include in the information packets.

Name Badges / Raffle Tickets

The first couple of years, we printed out badges to hand out to the attendees and speakers as they arrived at the registration desk.  Although I like the idea of name badges for networking purposes, the day is so hectic as it is, and it isn’t worth the cost of the badge holders.  This year, we instead printed out all the attendee names in a badge format that we then cut into raffle tickets, and used them for the end-of-day raffles.  The prior years, we handed out those popular red raffle tickets (keeping one half for the drawing), but it really slowed down the registration desk.

If you use a service like Eventbrite, you can easily print name badges from your attendee list.  I selected the badge style of Avery 74536 – Clip Name Badges (3 x 4 inch) – Page Size 8.5”x11”.

Prepare Information Packets

When preparing packets of information, include the Code Camp Sessions Grid, Code Camp Speakers and Sessions document, and feedback evaluation form, at minimum. If your hosting facility can swing it, I also recommend including a small pad or a few pieces of blank paper for notes, and a pen (all promoting your venue). Also include some promotional material for the venue as a return favor for hosting it. If any speakers want to hand out fliers for some of their services, you may want to consider placing them into the packets also. One year we made fliers available from one of our speakers who happened to be providing some free training, so that was an ideal situation.  Of course, if your contributing vendors supply you with flyers, include those as well.  This year, Telerik not only gave us flyers, they also gave us bags to put these packets into.

Arrange for Food

Always try to supply both breakfast and lunch for everyone. Serving breakfast is also an incentive for people to come to the early sessions. You want the day to get off to a flying start. With the funding support from our contributors, we ordered breakfast from Dunkin’ Donuts the past couple of years (a little over $400 to cover 160 people). I recommend putting together an order list, and to place your order in person at least a few days before the event, leaving the list with them.  Placing such a large order over the phone is doomed to get misinterpreted.  Trust me; it happened last year.

The pizza lunch order is a lot easier.  We stick with plain pies to make it simple, and estimate 1.5 to 2 slices per person.  Don’t forget diet as well as regular soda, and some non-carbonated beverages, also.  I’d also place this order at least a few days before the event.

Also, make speaker dinner reservations for your team (for approximately an hour after the event ends, to give you time for cleanup and travel to the restaurant). You can probably assume that about 50% of the speakers would be able to join you afterwards. Definitely take the speakers out for dinner after the event — not only for thanking them for volunteering (remember, without the speakers, there is no code camp), but this is also a phenomenal networking opportunity for everyone involved, and a LOT of fun. These are experts in the field; some well known, and others fairly new to the public speaking arena, and they can share war stories. Not only that, they’ll have a lot of insight into how to improve future events. You’ll probably need a few hundred dollars to cover this.  Try making this reservation at least a week in advance at a decent nearby restaurant (walking distance, if possible).

Microsoft covered the costs of lunch and dinner each year we ran the event, but this is always subject to change depending upon their budget.  So don’t only count on Microsoft for financial support.

Attendee Reminder Email

A couple of days before the event, send a reminder email to the registered attendees, giving final instructions including ticket info, parking info, directions, and links to the schedule and speaker information PDF downloads.  I generated this email through Eventbrite, and some of the header information was automatically generated for me.

Make sure everyone has good directions to the venue, both by car, and by public transit, if available. Don’t forget any special info about parking.  Don’t count on the registration sites’ mapping feature to get the directions right.  They always get our location wrong.  Several people got lost the first year.  This year, we mapped it ourselves, and included the correct map link on our registration page and in the final reminder emails.

Final Confirmation Phone Call / Email

A couple of days before the event, call each speaker to make sure that they’re ready, that they know exactly what time they’ll be presenting, and to remind them to get there early enough to do final preparations. Make sure they have directions, and ask if they’ll be joining you for the speaker dinner afterwards (as your guests). Also ask if they have any final questions. Follow up this phone call with an email to each, along with an attachment of setup instructions.

Always give out organizers’ cell phone numbers to the speakers. It will absolutely be used. A few speakers got a bit lost trying to find the venue, and another would have been locked out of the building because he came late in the day, and security had already locked the doors from the outside.

Summary Checklist

Here’s a summarized checklist, with milestones, of everything I detailed above:

1. Pick a date (at least 3 months prior)
2. Get help (at least 3 months prior)
3. Find mentors (at least 3 months prior)
4. Pick a venue (at least 3 months prior)
5. Create a website (at least 3 months prior)
6. Get an event registration site and account (at least 3 months prior)
7. Make a list (2 months prior)
8. Make a call for topics / internal announcement (2 months prior)
9. Make a call for speakers (6 weeks prior)
10. Make a call for contributors (6 weeks prior)
11. Obtain swag for raffles (1 month prior)
12. Address security concerns (1 month prior)
13. Make public announcements (1 month prior)
14. Choose the sessions (2 weeks prior)
15. Create the session tracks and schedule (2 weeks prior)
16. Make a call for presentation material (2 weeks prior)
17. Send a speaker preparation email (2 weeks prior)
18. Send room monitor instructions (1 week prior)
19. Post schedule and session details (1 week prior)
20. Create a large session schedule grid (1 week prior)
21. Create room / track schedules (1 week prior)
22. Create directional signs and a floor plan (1 week prior)
23. Create feedback evaluation forms (1 week prior)
24. Create session schedule grid handouts (1 week prior)
25. Create name badges / raffle tickets (1 week prior)
26. Prepare information packets (1 week prior)
27. Arrange for food (1 week prior)
28. Send out attendee reminder email (2 days prior)
29. Make final confirmation calls and send final speaker email (2 days prior)

In my next post, I’ll discuss how to handle the day of the event. It can get pretty frenzied, but at least there’s less actual work to do than in the preparation phase. That’s where all this preparation work pays dividends.

Five years ago, I jumped the gun, and declared U2’s “How to Dismantle an Atomic Bomb” a great album, and a potential classic. Looking back now, although it’s still an album full of some amazing pop songs, my susceptibility to hyperbole got the best of me. I let the emotions of unexpected success at the advanced age of my favorite band persuade an over-the-top review.

I intentionally tried to avoid the same situation this time around. I gave myself a couple of weeks after the leak of the album in order to be a little more objective. It was hard. Very, very hard. And I failed… I failed fast. But first, about that leak…

Communal Experience

Actually, I’m not even going to get into a debate on one side or the other about listening to the leak, but as a mass majority, U2 fans pre-order their albums — and usually the “limited edition,” “gold plated,” “signed with Bono’s blood” box sets, anyway. And when the band releases a new album, it absolutely requires a communal listening party. It’s no wonder 100,000 copies were downloaded within hours (if not minutes) of the accidental (?) leak (actually, a premature release) on an Australian online store, Getmusic.au. You cannot keep a U2 fan from this. And the response was deafening.

That’s one of the reasons holding myself back from this review was so incredibly difficult. I was dying to share my judgment of the music beyond mere descriptions and comparisons with earlier works. While my friends and co-fans were freely rating the album, I absolutely refused. There was a single trait about this album, though, that eased the difficulty just a smidge. It required repeated listenings. There was no way to comfortably form an opinion without several run-throughs. And that was a very, very good sign for the album.

But I compressed two weeks of listening into three days. So, I can hold back no longer. But at least I feel so much more comfortable sharing my feelings this time around.

Overall Impressions

I will start out by saying that this is the most diverse set of songs they have ever placed on a single album — and the fact that it makes for a cohesive whole is remarkable. “Achtung Baby” is a classic, but around half of the songs on that sound like they were cut from the same cloth. That just isn’t the case with “No Line”. This album ought to quiet the fans who’ve been clamoring for “something different”. They should be in heaven right about now.

If the album wasn’t a success, I would still give the band major kudos for the simple fact that they had the guts and confidence at the ripe old age of… uh… me, to put out their most daring collection in over a decade. They finally stayed away from safe — and let’s face it — “All That You Can’t Leave Behind” and the “Bomb” are ultimately both very “safe” albums. Remarkable in the fact that they could come back from such a commercial disaster as “Pop”, but safe, nonetheless. I will never, ever again question their ability to continue to produce at such a creative level again. I will not be surprised if they do it again at the age of 60. Far cry from the Rolling Stones, eh? This album makes me feel young.

In 1991, we were pretty shocked when “The Fly” was released as the lead single off of “Achtung Baby”. But that was ok, because it was a grower, and was ultimately a great song, with perhaps the solo highlight of Edge’s career. This time around, they shocked us again, but not in a very good way. Sorry, but “Get On Your Boots” is not a great song, nor will it ever grow to be one. It’s a throwaway, albeit with the best video they’ve produced in ages. But it fits perfectly smack in the middle of this set of songs. As a matter of fact, one of “No Line”’s strengths in its cohesiveness is the track sequencing. It’s one of the best sequencing jobs they’ve ever done.

A Touch of Achtung

Shortly after “Boots” was released, someone leaked the B-side version of the title track. Although most people thought it was a much stronger song than “Boots”, a recurring theme was its “cheesiness”, mid-80’s sound. I wasn’t in that group, but I did understand their reaction to it. But at the same time, I knew from the “leaked” 22 second Wal-Mart clips that the album version would be a lot moodier and stronger. I was right, and it’s a great start to the album. It’s a bit dark, has more minor notes than most U2 songs, and is very driving. And it contains some very “Achtung Baby” guitar licks.

An 80’s Throwback

“Magnificent” has been a potential fan favorite since the infamous “beach clips”, and with good reason — it’s classic U2, with those signature Edge licks. But when I first heard it, I thought it was a bit repetitive. I really love it now, though, because it is so much deeper than that. That’s a general theme throughout this album. Nothing is as it seems on the surface. Much has been said about the “layered” feel to the songs on the album. I think that has a lot to do with the fact that they finished the album. “Pop”, “Zooropa”, and “October” have often been referred to as their “unfinished” albums. “October”, due to the rush to get out a sophomore effort, despite Bono losing his lyric notebook shortly before recording, “Zooropa”, due to the quick expansion from an intended “EP” to a full-blown experimental album between legs of the “Zoo” tour, and “Pop”, due to the early scheduling of that tour. But this was their longest stretch between albums, and they made good use of their time.

Although “Magnificent” is classic U2, it starts like no other. Is that a drum machine? Sort of 80’s, and doesn’t hint at where it’s going to take us. But I can see this intro getting fans excited at a concert. There’s a definite “Where the Streets Have No Name” rhythm throughout, but it’s quite unlike that anthem.

A Second Attempt

The third track, “Moment of Surrender” is U2 finally fixing the cheesy misstep of “Stuck in a Moment”. This is Bono at his most soulful, and is something quite new for U2. At nearly seven and a half minutes, it feels like half that, despite the deliberate, moody rhythm. It’s beautiful in a way that U2 has not expressed beauty before. Again, more minor notes than expected from U2. Listen in a quiet room, or with noise canceling headphones. You’ll hear it differently every time. I’m totally and completely surprised how much I love this song. It’s usually not my speed.

For Some, a Trip… For Others, a “Trip”?

The fourth track, “Unknown Caller” has gotten some extreme reactions amongst fans. Many absolutely love it, while others find it completely annoying for several reasons. I think it’s one of the best things they’ve ever recorded, and at this writing, is my favorite song on the album and the first track I “repeated”. The multiple voice “chant” effect bugs some people, but being an Arcade Fire fan, who absolutely loves “No Cars Go”, I’m a fan of it. You’ll hear more vocal participation on this album than any other before. I’d color this song “The Hands That Build America” meets “I Still Haven’t Found What I’m Looking For” meets The Beatles, taken to a completely new level. And Adam owns this track. It’s over six minutes, and I always wish it never ends. But it does, and that’s ok…

A Taste of Pop — No, not THAT Pop

…because the next track is worth it. There’s a bit of “In A Little While” here, but this is so much stronger, and has single written all over it. It’s a pop song, but a stronger and more substantial pop song than most of what we’ve found on the last two albums. This also contains one of the best and most joyful (although somewhat derivative) bridges on the album. I can see them expanding this bridge live. Corny title, but great pop song, and really the only true pop song on the album.

Strongest Starting Five?

Ok, just about half way there now, and quite possibly the strongest start of any U2 album yet. The Joshua Tree owns the greatest three song start ever (and if they would have just swapped “Bullet the Blue Sky” with “Red Hill Mining Town”, it would have been the best five song start). But the streak ends here — enough has been said about “Get On Your Boots”, the middle track. But despite considering this a mediocre song, I never skip it, because it breaks up the album nicely in two.

Led Zeppelin, on a Hot Summer Night

I’m not a big fan of the style of the next song, “Stand Up Comedy”, which has often been likened to a Led Zep song, but U2 can pull this off better than most. Their range is amazing. I can see this as a surprise hit in the summer. It just seems like a hot summer song. There are some great guitar riffs here, and the chorus is incredibly catchy. The Edge is on fire.

A Successful Experiment

“Fez - Being Born” is “Zooropa”, part two. This is their most Radiohead-ish song, the most experimental of the album, and it flat-out works. The first time I heard it, though, I thought, “well, is that it?” I had heard it was a two-parter, and it just seemed like a blur in one part. But it all makes sense now. Repeated listening required for this one. You’ll hear something different each time. Now I hear “Rejoice”, from October.

Looking for Something Profound

It took me a very long time to get into “White as Snow”. I’m still not fully sold on it. I think it could have been taken to the next level, and the thing that saves it from being too generic is the great music behind it. It sounds like an old cowboy song, which isn’t necessarily a bad thing. It just seems a bit more repetitive than they’ve done in the past. It feels like it’ll take off during the change around the 2:10 mark, but it falls away from that fairly quickly.

I’m not big on lyrics. It only makes much of a difference to me when it’s either completely corny (a LOT the last couple of albums), or profound. I’m looking for profound in “White as Snow” to get by the plainness. But I can’t really complain, because it’s still quality enough where I never skip it. And I can see this still growing on me.

Acrobat for the Masses

“Breathe” is the mainstream version of “Acrobat” — mainstream only in its accessibility. This has the chance of being a huge hit. The crazy time signature of the verses is what most gives it its “Acrobat” feel, and then it breaks into a conventional pace for the brilliant singalong chorus. This is a highlight of the album. You cannot go by the 22 second Wal-Mart clip. It’ll completely throw you off. Even if this doesn’t become a hit, it has “huge fan favorite” written all over it. This is a solid example of how U2 is willing to abandon playing it safe once more.

One Minor Disappointment?

“Cedars of Lebanon” has been the main disappointment for me, but only because I heard amazing things about this from the early listener reviews. The music is tremendous, but the vocals are monotonous. This is the second song I feel could have been so much more. It does get a lot better with repeated listening, so there’s still some hope. But as of now, this closer is a cross of “Grace” (never liked much at all) and “Wake Up Dead Man” (which I grew to love). So it’s somewhere in the middle.

Vocals

Bono’s vocal range hasn’t been this good in over a decade. I hope it remains this strong during the tour. He’ll never reach his “Lovetown Tour” peak again, but if he can be half as successful, we’re in for a treat. What’s very strange is that I’ve seen a few people comment on how he sounds like a tired rock star. I understand how music can be very subjective, but either someone’s voice cracks a lot, or it doesn’t — am I missing or ignoring something? I don’t know. To me, his voice has ALWAYS cracked at times, and I wonder if the comments are due to people comparing his voice to what they’ve always hoped it could be.

And to revisit the vocal chanting — I think it’s great, if only for showing how they’re a complete band, and everyone is getting a chance to sing now. I’m pretty sure Daniel Lanois and Brian Eno are two of the voices in there, too. It sounds like a celebration to me.

This is an exciting album, where hearing the opening bars of a song on the radio could thrill me. I can’t say the same feeling was there for the past two albums.

But Is It a Masterpiece?

Yet, the question remains: will “No Line on the Horizon” be considered a masterpiece? Well, if you consider a masterpiece something that is representative of an entire body of work, yet still unique unto itself… and if you consider that a masterpiece is where each song is strong enough to stand on its own, but the cohesive whole is greater than the sum of its parts… and if you consider that the band is secure enough in its own abilities to invite influences from artists both older and younger, yet still have a strong enough ego to know they can make it their own… and if you can revisit it without tiring of it, and if it can stand the test of time, then it has the potential to be considered a masterpiece. You can only speculate if a new album will eventually be thought of as a masterpiece by the masses. How much time passed before “Achtung Baby” was looked upon as one? “The Joshua Tree”? All the ingredients are there, except for time. That still remains.

4.8/5.0

Update
I’ve updated some of the points below, based on some of the comments I received, including points about when to answer questions, the appropriateness of jokes, and following through after the presentation.

Last night, I attended a terrific Speaker Idol event at the NYC .NET Developer’s Group at the Microsoft office in NYC. It’s one of the formats I mentioned in my post about user group meeting ideas.

This was the first user group meeting I’ve attended since I helped start a couple, and it was really nice to focus more on learning rather than coordinating. I had three main motivations for attending this meeting:

1. I wanted to finally attend a meeting rather than run one.
2. I wanted to see how a Speaker Idol event is run, in order to run one ourselves.
3. I wanted to see what it takes as a speaker, so perhaps I could try it myself one day.

I feel like I met these goals. First of all, attending these in NYC always gives me a rush of energy. I love going to the city, because it’s so amazingly alive and vibrant. It gives me the feeling of being able to accomplish anything. And there’s nothing like a warm summer night in the city that never sleeps.

And the second and third goals were accomplished with flying colors. Although I tried to make this a non-working event, I couldn’t help myself. I spent the entire night taking copious notes. And although this was the first Speaker Idol event I’ve ever attended, and it’s the only one I can base my observations on, I think it came off great. I think it can serve as a model for future events, so I put together a list of guidelines from this experience.

Although I haven’t presented at user groups yet, I’ve had similar experiences. My tips are a combination of those, of comments from last night’s judges, and of my observations from this and other user group meetings.

Great job done by Stephen Forte, Andrew Brust, Peter Laudati, Bill Zach, and all the speakers and judges!

Basic Rules

• Approximately five speakers should present (there were six last night).
• Each speaker gets 10 minutes to do their main presentation.
• There are four judges who are recognized leaders in the community, to give this legitimacy.
• During the presentations, the MC (Stephen Forte, for last night’s event) gives a silent two minute warning signal.
• The MC then gives a cut sign, signaling to the speaker that they have 20 seconds to wrap up.
• Once the presentation is complete, two minutes are alloted for a Q & A session with the audience.
• This is followed by a judge commenting session which lasts from three to five total minutes, rotating through the judges who comment on the presentation style (NOT the content). Sort of like American Idol. For each presenter, the comments are started by the next judge in rotation.
• At the end of the competition, bring all the participants to the front for a final round of applause, and announce the winners.
• There are three winners. At last night’s meeting, first place won an Xbox, second and third place won versions of Windows Vista.

Moderator Tips

A Speaker Idol event is similar to a mini code camp, where you’re pretty much going crazy trying to get equipment set up and tested. It was pretty hectic last night, with people downloading codecs, using borrowed laptops, etc. More about this in the Speaker Tips section, below.

• Have someone else handle the food. You’ll be too busy coordinating everything else with the speakers and judges, so try to get a sponsor to handle that. This was what the group did last night, and all it cost was about 10 minutes of a (deathly dull) sponsor presentation at the start of the session. Once you’ve seen one recruiter presentation, you’ve seen them all. They were sincere, but c’mon recruiters — use a little imagination. I don’t care how many clients and consultants you have. Tell me how you could help my career… anyway, that cries for another post…
• You may need to be the liaison between a speaker and the supplier of a solution if their presentation isn’t working on their own equipment. Set aside some time for this. It was a bit of a scramble last night, so I’d recommend requiring the speakers show up an hour before the session for setup and testing. Things will always get a little crazy, and a bit of luck is always involved, but this will increase the chances of success.
• I’m not sure how the presenter order was decided, but there’s a definite advantage that increases with each speaker. You could either have a random drawing, or use the reverse order of who volunteers to participate. Since most of us are so busy these days, I’d prefer a random selection.
• A quick 20 second intro of each speaker would eliminate the need for them to do more than a ten second "hello" at the beginning of their presentation. Most people are uncomfortable introducing themselves anyway, so it may keep them more at ease to start their presentation if they don’t have to concern themselves with that. They can just display a simple info slide at the start, while they introduce the topic.
• Clarify to the audience and speakers that for these types of presentations, especially with a dedicated Q & A period, almost all questions should be deflected for that period. The only time a question should be addressed during the body of the 10 minute presentation is if it’s critical for the direction of the rest of the presentation.

Speaker Tips

Do the three "P"s: Prepare, Practice, and Present. I’m sure I’ve heard that phrase before, but I’m not sure who to credit…

Preparation

• Tailor your presentation for 10 minutes (and I’d shoot for 8 to play it safe ).
• Be aware of whether your presentation is more of a discussion topic or a presentation, and prepare the style and flow based upon that. Make sure you structure the presentation to have a strong start, middle, and end. At the start, do the quick hit to get the audience engaged, and tell them what you’ll be talking about. Next, dive in and talk about it. Finally, quickly summarize with a couple of key conclusive points.
• Go for impact from the start, whether it’s through humor or a one liner that clearly sets the stage for the presentation.
• Slides should be minimal, and only used as cue cards for what you’re going to say.
• Since this is a 10 minute presentation, only pick a couple of key points to elaborate on — one positive and one negative, if possible.
• If your presentation calls for a comparison between two or more options, use visuals to compare. In a 10 minute window, you’ll need to get the point across quickly, so visuals work best for this.
• Use a large font size. The obvious reasons go without saying. But less obviously, it turns code into more of a quick-hitting visual.
• Don’t use blue font on a black background. It’s virtually impossible to read without straining. I’d actually recommend sticking with the default white background. A lot of developers seem to favor a black background these days, but although that may work well on your desktop, it doesn’t translate well to the large screen.
• Use very simple demos. If you can get your point across with a single visual, or just a tiny code snippet, then you can succeed in a 10 minute slot. Review your code several times as you prepare, stripping out everything you can, while still making it relevant. This is a common theme for writing, also.
• Plan the Q & A session, anticipating the types of questions you may get. You may need to balance leaving out a point or two in order to open up the possibility of a couple of good questions, but at the same time, don’t leave out critical info during the main presentation which will only leave your audience in a cliffhanger.

Presentation Style

• Project. You don’t want people straining to hear you, especially when you only have 10 minutes to state your case.
• Face the room. If you don’t face the room, your voice will just bounce off the wall behind you, and that ain’t gonna help with projecting.
• Rotate facing each side of the audience. This will help engage the entire audience.
• Don’t read directly from the slides, or repeat them word for word as if memorized. This becomes very robotic.
• Setting the slide show on automatic timer may be a novel way to keep you focused on your flow and time constraints, but it could be a distraction if you have to keep stepping back to a previous slide.
• If you’re natural at it, inject humor, especially at the start. It helps build rapport. Jabs at users are always good for a laugh in front of tech groups. But if it isn’t your normal modus operandi, don’t force it, because it will be obvious that it’s being used as a gimmick.
• Be aware of your audience. As I mentioned above, jokes about users are ok if your audience is a tech group, but don’t joke about topics and subjects that may offend your audience. If you feel any discomfort when about to tell a joke, trust your instinct and play it safe. Very little can take the air completely out of a presentation than a misguided attempt at humor.
• Show enthusiasm for your subject matter. If you can’t show enthusiasm for 10 minutes, you’re speaking on the wrong topic for you.
• When notified of the two minute warning, or 20 second wrap-up, don’t acknowledge it. It ruins the flow, and disengages your audience.
• Avoid silence, but don’t fill it with hemming and hawing ("um"s). Practice in front of mock audiences (or the mirror) is key. If you need to take a few moments to do something on the screen, at least explain what you’re doing while doing it.
• Don’t trail off or mumble when you speak. This is another variation of hemming and hawing, and people begin thinking they may be missing some important info.
• Be energetic. Watch someone like Stephen Forte when he speaks. He can make accounting sound exciting (sorry accountants ). We live in a fast moving, "MTV" world, and it takes a lot of animation to keep our attention.
• Stand in front of the podium. Stepping behind (for reading notes, etc.) only serves to disengage your audience. This is why you need to do the three Ps. You don’t want to sound as if you’re reading from a book. Show us you know your topic. You want to project credibility.
• Make eye contact with the audience. You can pick a handful of people (one from each side of the audience) to feel like you’re speaking one on one. I’ve heard a related recommendation for writing. Imagine that your audience is one person — a friend of yours.
• When things screw up, self deprecation goes a long way. The audience can relate to screw ups.
• Be honest. If you really don’t know the answer to something, say so. Otherwise, you risk the credibility of your entire presentation.

Presentation Content

• Make your intro of yourself and your company extremely short (if needed at all — see moderator tips, above). You can show a simple intro slide while you introduce the topic, in case people really want to know. Don’t be offended that we came here for the topic, and not necessarily for you.
• Explain why you’re presenting the topic, and what business reasons there are for it.
• Asking for a show of hands initiates interaction with the audience, but don’t leave it at that. Otherwise it just seems gimmicky.
• Use personal insight when discussing examples and experiences. This helps the audience identify with you and the topic you’re trying to convey. Otherwise, you may as well be reading facts out of a textbook.
• Never make comments or state opinions without following up with "why". "Why" is really the most important type of question you can answer. And the specific "what" and "how" always follow the "why".
• Have the demos open and ready BEFORE starting the presentation. Nothing leads to those empty spaces more than waiting for Visual Studio or PowerPoint and associated project files to open. You only have 10 minutes, and time always seems to run away quicker while waiting for these to open.
• Get to code as soon as possible. For a technical audience, getting to the meat is key for keeping us engaged.
• Switch to full screen mode when showing code (SHIFT-ALT-ENTER). Popping panels are a major distraction.
• Display your resources slide during your 20 second wrap-up and into the Q & A. The judges mentioned to leave it up there after speaking to it, but I wouldn’t even recommend speaking to it. It wastes valuable time, and your audience expects to see this at the end anyway, so it’s obvious.
• Use the regions feature in your code examples to make it easier to focus on small snippets.
• When discussing unknown technologies, give quick, one-line intros. It may help to show an analogy to technology your audience is familiar with. For example, EJB to .NET Enterprise Services. It may not be exact (like my example?), but it’ll give us the proper context.

After the Presentation

Many people attend these presentation for the educational value, in order to keep up with what’s happening in their field, and they make a significant time commitment to attend your presentation. Whatever your motivation for speaking, the reputation you earn is based upon more than your session. How you follow through also counts in a big way.

• For speakers of any type of presentation: please try to make yourself available, at least through email, for any follow-up questions attendees may have. Due to the nature of presentations, there are almost always outstanding questions that cannot necessarily be answered or even anticipated during the presentation, so you should always expect questions after the event.
• It’s also a good idea to provide the organizers of these events with presentation material and supplements to post on the organization’s website, to help with the follow-on.

I anticipated such an event to be a lot of fun, and it exceeded my expectations. I’m sure it was nerve wracking for the speakers and the moderators, but like my experience with the code camp, I’m sure it was well worth it. I’ll use this post as a guideline for when my group runs a similar event, and hopefully others will find this useful, even though I’m basing it upon limited personal experience. If you have anything to add or suggest, please comment.

John Zablocki was one of the presenters at the our first ever code camp. He’s written a related article about presenting at code camps, with the story behind his preparation and presentation. This article serves as a cousin post to my posts about running a code camp. Ok, maybe it’s a sister post. Or a brother post. Oh, brother — you get the idea…

Also, since he recently presented at our .NET user group, he’s written a related article about presenting at user groups. He had a fairly unique experience, thanks to the fact that the Microsoft Visual Studio 2008 Installfest was happening (to his surprise) on the same evening. We did that just for you, John! Serves you right for taking a long vacation during the announcement.

As soon as I gather enough courage to speak at one of these things myself one day, I’ll be sure to re-read these. In the meantime, I’ll continue to help organize these, and occasionally participate from the audience. But I will speak one day! I will! The more presentations I see, the more confidence I have that I can do it well.

Of course, when that day comes, you can be sure I’ll be whimpering on the floor in a pool of sweat…

In my previous two posts, I discussed guidelines for the preparation of running a code camp, and then I went through all the tasks for handling the actual day of the event. Here, I’ll be discussing the things you should do after the event is done — after you’ve given yourself a few hours (minutes?) to bask in its afterglow.

Evaluation Feedback
Tally the feedback forms as soon as possible after the session. I experienced an interesting phenomenon at the end of the day, after the attendees had all left and the speakers were waiting to go out to dinner. They were all over the evaluation sheet box, checking ratings and feedback. The visual is quite an experience, and in my bewilderment, Melissa Demcsak (who didn’t speak at this event, but has done so at others) observed that I must be new to this, because it’s a common occurrence. I certainly understand it though.

I gathered all the ratings and averages for each category, sending it along with comments specific to each speaker’s session, and also the general comments about the code camp. You can download a copy of our eval document as a starting point for your own.

I’m sure you’re thinking there must be a high-tech way of handling this, but for gathering feedback while the sessions are still fresh in attendees’ minds, I’m not sure there is. Even if we had set up kiosks, forcing people to line up at a few really isn’t an attractive option. The goal is to make it as friction-free as possible. It’s the facilitators’ job to deal with the work involved afterwards. Yes, it was a pain manually tallying all the sheets, but I got into a rhythm, and was able to push through it in decent time. It was pretty interesting reading the comments, and quite a challenge deciphering the handwriting. And, yes, even some normally detail-oriented developers still have trouble following directions .

I created a spreadsheet with a worksheet for each speaker, one for general comments, and one for tallying results from the venue-specific questions. Here, you’ll find a semi-fictionalized sample (the names and ratings have been changed to protect the innocent). I then split each speaker’s worksheet into its own spreadsheet, which I emailed (along with the General worksheet) to each speaker.

Follow-Up Communication with the Speakers
Of course, don’t forget follow up with the speakers right after the event to thank them for volunteering their time and effort, not to mention their sheer courage for speaking in front of a crowd for at least an hour straight. Like I said before, without the speakers, there is no code camp (no user groups, no education, no growth and no interest in the field — nothing). These people deserve all the credit in the world for making all of this possible. This would also be a good time to remind them to send you their presentation slides, etc., if they hadn’t already. You probably already have attendees bugging you for these.

Post the Session Presentation Material
Shortly after the event is complete (by the following Monday, if possible), try to post all the material you’ve received up until that point. We placed a session list on the home page of the code camp for easy access, with links on each square leading to a zip file of the material. Also, if a speaker has a web page, link their name to that page. And if you happen to take photos and/or videos of a session, also create a link to it from within that box. Keep these up-to-date as you continue to receive material. I created a standard naming convention to easily create and update the links. In the future, I plan on making this data-driven. For this code camp, I’ve been updating a simple table, but it’s still error prone.

Final Call for Presentation Material
You don’t want to be too annoying (I’m known to be a bit annoying ), but a week or so after the event, you may want to send out one last reminder for presentation material. As top members of our field, the speakers are probably all very busy, so sometimes a little nudge will help give them a chance to refocus for a few minutes to gather up their material.

Plan the Next Event
What? Already? You bet. You don’t want to lose the momentum. I’d wait a few weeks, but not much more than a month after the event to follow up with both the speakers and the attendees. We haven’t done this quite yet, but we’ll be sending out an email shortly, asking everyone about the topics they’d want to see next time, and ask the speakers if they’d be interested in presenting follow-up topics in either our next code camp (around May, if we do these semi-annually), or if they’d want to expand upon their topics at a user group meeting in 2008.

Wow, there were a lot of guidelines, but this is a big undertaking — much larger than I had realized. But it was well worth it! It’s definitely not something that you’d want to take on more than a couple of times a year. With solid planning, dedication, and some seasoned guidance, you can do this, and it’s an experience you’ll not soon forget.

Please let me know if I missed any important points. I hope these guidelines prove useful, and I’ll keep these posts updated as a reference for anyone who wants to run a code camp or similar event in their community.