After some nights of sleep and reflection, I've distilled my lessons learned from the code camp into the following:

1. Make your presentation title simple and clear

My biggest frustration was the session attendees who weren't interested in my session. My second biggest frustration was that I knew a lot of camp attendees were interested in topics I covered but didn't realize I was covering them. Both of those are a reflection of a flaw in my title and topic description, not the attendees' ability to read. Yes, the presentation abstract clearly stated what I was covering. However, people have to understand your title well enough to be motivated to read the abstract. And on the other hand, you can't expect people to read the abstracts. Instead of trying to have a clever title like "Test Smarter: Patterns and tools to blah blah blah", I should have had a simple title like "Unit Test Refactoring: Mocks, Stubs, and Patterns"

2. Keep your focus narrow

My abstract was somewhat vague about exactly what I was presenting. Was it going to cover Dependency Injection? Design patterns? Test driven development?  This is somewhat related to the first point. My abstract was vague in part because when I submitted it, I wasn't exactly sure which frameworks and patterns would be most valuable. I simply wanted to cover the gigantic topic of "things to make writing unit test easier." And I think that's OK as an abstract proposal, but when it came time to actually review the text going into the CodeCamp program, I should have altered the abstract to be very specific about what was being covered. Any 1 hour talk that tries to cover a huge topic will not be able to dive deep enough into any one topic to provide much value. I think people know this instinctively and avoid overly broad survey sessions...unless of course the speaker is Ted Neward.

3. Create an environment appropriate to the space

Another frustration was that the session attendees mostly sat in the back of the room. As I said, there weren't many attendees to begin with; so I felt like I had to shout across the room to talk to them. When I mentioned this to my wife, she asked me why I didn't have the attendees move to the front of the room, and of course, she is right. I should have simply asked people to move to the front. The audience would have naturally become more engaged, and I could have talked to them at a more normal level.  If you're giving a talk to 100 people, that's different; that's a lecture. But if you only have a handful of people in the session, you should take steps to bring them close to create a more intimate dialog. 

4. Be prepared for 800x600

The projector screen resolution was 800x600, and I couldn't make it larger. I think it was possible to make it larger; my laptop just would not do it. My presentation and especially the code demos were not created to be viewed at 800x600. If you're giving a presentation with a projector you've never used, be prepared to deal with funky screen resolutions. Enough said.

 (These next two are lessons I learned while watching Jonathan Cogley's presentation on TDD and mock objects.)

5. Be prepared for rude attendees

I guess a few people got bored or distracted during Jonathan's talk, because there were two people in specific that started talking to each other about halfway through and didn't stop. They were talking quietly, but it was still annoying and extremely rude. I'm not sure if Jonathan noticed, because he was at the front of the room talking, while they were towards the back. But if you're going to give a presentation to a public audience, you need to decide how you're going to handle something like that. I basically decided that I would stop the talk and directly address them, asking them to either contribute to the discussion or leave. It's not rocket science, but if you're unprepared for it, it can be disarming.

6. Know your audience's objectives

Jonathan's abstract said that he'd be covering TDD and mock objects. He did a good job with the TDD portion, but time ran out before he could cover mock objects. From the murmurs amongst the audience, it was clear that many people came explicitly to learn about mock objects in general or Rhino Mocks in specific.  My impression was that a lot of people left the session dissatisfied. I could be wrong, but for me, it definitely underscored the point that you should be adaptive to what your audience wants. In my opinion, the purpose of CodeCamp or user group meetings or any of these free public training sessions is to help educate others in the community and raise the general level of software development. If an overwhelming majority of your audience is mostly interested in a particular facet of your presentation, you need to be prepared to throw your script out the window and shift your focus -- within some common sense limits. If you don't have enough material or expertise to dive deeply into the niche, it's likely that somebody else in the audience will be able to help you. And honestly, if one of my sessions became an interactive group discussion with my role becoming facilitator as much as presenter, I would be delighted. Anyway, this is why I'm a fan of the "poll the audience" technique, in which you ask some basic questions at the beginning of your talk -- it can help you gauge the audience's familiarity and specific interests with your topic.

I think those are the big ones, except for the ever-present STOP PROCRASTINATING and get the presentation completely finished ahead of time instead of waiting until the last minute.