I'm aware that my blog engine has some problems right now. It's publishing items to the feed twice, and comments aren't appearing. I hope to resolve these problems next week when I have more time. Thanks for the feedback.

I settled in for a relaxing, computer-free Memorial weekend. My wife and I were planning to meet some family in D.C., visit a museum or two and attend a little BBQ. But in a sign of my ever growing nerdery, I found a way to introduce software development.

Late Friday night, I checked out the sessions at the NoVa CodeCamp. Hmm, lots of good speakers. Hmm, we're not meeting people until the afternoon. Methinks this might work. After some cajoling, I get clearance from the wife to attend the camp in the morning, before we meet the relatives. 

So I attended a few sessions, and they were totally worth the effort of leaving CVille at 6:30 AM. 

Intro to Data Warehousing by the lovely and talented Jessica Moss

This was a very  good session; if you're interested in this topic, I recommend seeking her out. Jessica obviously knows her stuff about BI and OLAP, and she can communicate it effectively. My only complaint about this session is that the audience was so into, asking so many questions, that Jessica didn't have time for some of the material that I really cared about, i.e., actually seeing SQL Server 2008 build a cube. I think this session could easily be turned into a full day workshop.

After I master website security, ASP.NET MVC, Ruby, F#, and come up to speed on popular ORMs-- BI is definitely an area where I need some focus, after I bone up on the new parallel paradigms of course.  :) I used to be much more into OLAP and BI than I am now, but I still think a small dose of BI can be differentiator between a system that is good and a system that is mindblowing. Few things will make a business executive love you as much as giving him a solid matrix UI that lets them slice and dice his inventory/sales/calls/facts by the relevant dimensions of his business.

SharePoint and Silverlight by the quick-witted Sahil Malik 

Another great session. Honestly, my interest in SharePoint or Silverlight is best described as obligatory, but when you have an engaging speaker like Sahil, you can't miss that opportunity. And Sahil lived up to his reputation; it was a great, somewhat impromptu, presentation. The presentation was mostly based on a demonstration of a development technique that I'll try to share. I got the gist of it, but some of the SharePoint specifics were lost on me. 

Here are the highlights, as I remember them, but Sahil wrote an article with much of the same content. 

• SharePoint development must be done in a virtual environment, pragmatically speaking, but SharePoint requires a lot of overhead. 
• Silverlight development requires short feedback cycles, with working in VS, working in Blend, deploying and testing, and then repeating.
• The slow SharePoint VM combined with the needs of Silverlight development and the fact that assemblies must be built for Silverlight combined with SharePoint assemblies not being Silverlight compatible all point to the need for an abstraction between SharePoint and Silverlight that lets you develop somewhat independently.
  
• A light WCF service can be used to provide that proxy between Silverlight and SharePoint. You can use the WCF service to provide mock data during initial SL dev, and then with a few tricks, you can deploy your SL application and the WCF service being nearly invisible. 
• Obviously you can dev SL applications in isolation. Sahil's solution is relevant is you're trying to read SP data from your SL app. Read his article for more details; I'm probably misrepresenting something.
  

Fast LINQ by the excellent K. Scott Allen

I also enjoyed this session quite a lot, though I was already familiar with the material. Scott is a great presenter, and I assume that his PluralSight course on LINQ is equally good if you're into this topic.

Main topics covered:

• IQueryable vs IEnumerable

IEnumerable consumes delegates and is better suited for local LINQ providers: LINQ to Objects, LINQ to XML, etc.

IQueryable uses expressions to translate queries and is better suited for remote LINQ provider: LINQ to SQL, LINQ to NHibernate, etc.

• Deferred execution
• Non-obvious optimizations 

 

Justin Etheredge's ongoing series of posts on technical presenting has inspired me to finish this post I've had in limbo for a while. 

Over the last three weeks I've given as many presentations at community events. Overall, I feel they went adequately -- not great but good enough. At this point in my presentation skill continuum, my goal is merely not to fail. If you're not a naturally engaging speaker or storyteller, the journey to giving fantastic presentations will probably be long and overcome only through a lot of practice, and it's not really a state I'm qualified to coach towards. However, I can give advice on not failing miserably. I'm learning there are many subtleties to becoming great, but becoming adequate just takes a little effort and a simple formula.

The Four Rs of Not Failing

1. Research
2. Rehearse
3. Rehearse
4. Relax 

1. Research Your Topic

When giving a technical presentation, few things will get you ticket on the fail train as fast as not really knowing your material. This problem can present itself in various ways. Most important, you need to feel that you're qualified to present the material; if you don't feel confident, your presentation will be doomed as your nervous ticks emerge and the audience starts daydreaming. You need to understand why people care about your topic. (This is the foundation of engaging the audience.) Lastly, you need to be able to anticipate the questions people will have. I don't mean that you need to be the world's foremost expert on your topic, but you need to have a good working knowledge of your topic. You need to understand how people are actually using it in the real world. If you've been using a technology on a real project, you've probably hit most of the pain points; if you haven't, I recommend watching webcasts of how other people are presenting the topic via PDC, Mix, etc.

I'm not going to discuss crafting your presentation. That's a huge topic with lots of good resources.

2. Rehearse

After you're confident with your topic and have a rough draft of your presentation, rehearsing is the next critical step. When giving technical presentations, you have some challenges most slide-only business presentations don't. When you only have slides, you can run through each slide, telling a nice little story with a high degree of certainty about the flow and timing of your presentation. When you start interspersing technical demonstrations, you introduce a heap of variability.

Each demo is a unit of work. It needs to be tested and rehearsed independently, and after you feel good about each one, you must run through all of them in order, i.e., integration tests. I've had numerous problems where a demo worked fine in isolation, but in my real presentation something went wrong: an environmental side effect, forgetting to reset a shared resource, etc. And this isn't even including hardware issues. Demos might suddenly start running much faster or slower than they did when rehearsing; the network might flake out. If things can go wrong, they will -- the more you rehearse, the more likely you are to find those edge case problems.

Ideally, you should have the entire environment for your demo in a virtual machine backed up to removable storage. If something goes very wrong on demo day, you can just use/borrow a different laptop. I don't always do this, but you're taking a risk if you choose not to.

As I rehearse each section of the presentation, I like to make bullet points for each slide and detailed notes for my technical demonstration. I usually end up not looking at any notes, but the act of creation is the important part. Translating your thoughts into concrete words will cement the main points in your memory.

3. REHEARSE

Seriously, you're probably not rehearsing enough. Talking through the micro issues is not enough. Having working demos and a detailed script is not enough. You need to rehearse the entire presentation from start to finish, with no breaks and no edits. This is good for getting a realistic measure of your presentation's running time, important if you're in a timeboxed setting like a CodeCamp. And this is really the only way to see the total flow of your presentation. If you're like most technical presenters, you obsess over the small things, spending hours on getting the code for an 8 minute demonstration perfect, but you neglect the bigger picture. I have to continually remind myself that most people aren't going to care about (or much less remember) the details of the demonstrations; even if you've done a fantastic job, some of the audience might remember a bullet or two about each demo. 

I've started doing a complete rehearsal in a room by myself with a projector and a camera. This probably sounds like overkill to many people, but I've found it to be extremely valuable. You quickly see your nervous ticks, saying "uh" to fill every gap, fiddling with your water bottle or repeatedly using certain phrases. You'll notice if you're talking too fast without enough enunciation. Important to technical demos, you'll get a feel for how you're transitioning between slides and demos.

There's a famous quotation from Maya Angelou:

I've learned that people will forget what you said, people will forget what you did, but people will never forget how you made them feel.

I find profundity in this sentiment, and I think it applies to presentations as well. Everyone will remember the impression you made on them, many will remember the story you told, and a few who care about your topic might actually remember a technical detail or two. If you haven't rehearsed the entire story from front to back, you are skimping on the second most important ingredient. 

4. Relax

A calm, casual composure is the point of all this research and rehearsing. When it is time to give your presentation, you shouldn't even need to think about what you're doing. You're just having a friendly conversation with the audience. When I'm in front of a group of peers, the last thing I want to worry about is sticking to a script or trying to remember interesting things about my topic. I just want to relax, tell a nice story, share some cool nerdy things, and have a good time. For me, over-the-top preparation is the only way to achieve this goal. 

Conclusion

I came upon this formula in part from my experience speaking in front of clients, CodeCamps, and local user groups and in part from watching other speakers and performers.

I'm a software developer. I have received no training to perform in front of people, but you know what, there's a whole profession of people who do this day-in day-out. They're called actors; you might have heard of them. I was recently watching Charlie Rose on PBS, and his guest was Michael Caine. I enjoy Caine's work as an actor, and I really appreciate how he talks about his craft. During this interview he was talking about what he likes in directors.  I've included an excerpt from the interview below: 

MICHAEL CAINE:  What I do is I work, one of the basic principles of 
Stanislavski which is called the method which is not looking at the floor 
and mumbling and scratching your bum.  That’s not the method.  What it is 
the first basic principal of it is the rehearsal is the work and the 
performance is the relaxation.  So I’ve already done everything before you 
say action.  I’ve said that line a thousand times before you ever, you 
know.  And so we rehearse it, obviously rehearse it with other actor to see 
what he’s going to do.  Once I’m ready and I do it, there is a moment -- 
you maybe do two takes or three takes but by that time there is a moment 
when I’ve done it the way I think it should be done and then after that I 
do get a little ticked off if we keep going.

That's a fantastic perspective: rehearsal is the work and the performance is the relaxation. And that's pretty much my whole recipe: research, rehearse, rehearse, relax. This advice is geared towards giving presentations at community events, where the goal is to be informative. If you 're giving a different type of technical presentation, like a sales demo or executive stakeholder demo, YMMV. 

Along with structuring the presentation, I haven't covered many important topics, e.g., knowing your audience, slidedeck design, body language, etc. There are many different ways to approach each of those topics and many recipes for success. But if you're just getting started in the world of presenting, those topics will probably just distract you from the core issues you need to work on.

Technical presentations, especially those with demonstrations, have a mess of complexities and potential risks. I cannot guarantee you'll be a smashing success, but I am confident that if you go through this routine, your presentation will be adequate. You will not fail miserably, and that's a good start. Obviously you can succeed without following this formula; I've seen people give rousing impromptu presentations with zero focused preparation. I've also seen many people fall flat on their face by preparing too little; trust me when I say that adequate (not failing) is better than many presentations I've seen throughout the years.

Please let me know if you use any of the ideas from this post. I'm always looking for ways to mature my thoughts on and approach to presenting. 

Earlier today I stumbled across a TDD/test-first analogy that's worth sharing.

My dishwasher broke a while ago,  and for various reasons, we've been slow in replacing it. This means that my sink often has a few glasses and plates, waiting to hand-washed. Of course, that's gross and makes things look dirty, especially in a kitchen as small as mine. For a while I tried to always wash my dishes immediately after using them, but that proved beyond my discipline. I tried fighting instincts, but after I'm finished preparing and then consuming a meal, I just want to relax -- not spend 15 minutes scrubbing pots and pans. There's not much incentive to wash dishes right then.

But that means that the mess grows and after a few meals, I have to spend an hour or so washing dishes. Washing dishes isn't so awful by itself, but it has a way of permeating the rest of the your activities in the kitchen. For example, I cook a healthy meal at home much less often if there are any dishes waiting to be cleaned. Instead, I'll just have a bowl of canned soup, some crappy microwave dinner, or takeout. Altogether I was pretty unhappy with the situation and looking to expedite the process of getting a dishwasher installed.

So, I  developed a new tactic. When I decide to cook  a meal, I will force myself to wash an amount of dishes equivalent to the amount I'm about to use, i.e., if I'm eating a bowl of cereal, I'll at least wash a bowl/plate/glass and a utensil beforehand. It's been working fairly well.

In general, with wash-first I'm finding:

1. The dishes actually get washed. Putting the incentive after the effort works much better.
2. I often wash dishes immediately after using them, because I'm already in that washing mindset.
3. As I plan out a meal, I try to minize the number of dishes I'll dirty; I keep washability in mind.
   
4. I end up spending less time cleaning overall.
   
5. I'm cooking more at home.
6. My kitchen is cleaner.
   

So, let's tie this back into software. This past Thursday I went to the Meet and Code dinner in Richmond (now Richmond Software Craftsmanship Group). It was a very fun meeting with lots of good discussion about the challenges of the testing legacy code and just software development in general. With that experience lingering in my mind, I woke up this morning in the mood for pancakes. Oh, but that would dirty so many dishes! I set about washing a pan and so on, and I started ruminating that this wash-first methodology was working fairly well. I suddenly realized that I was applying TDD strategies to dishwashing!

In general, with test-first I've found:

1. Tests actually get written. 
2. My code is designed with testability in mind and thus more testable.
3. I end up spending less time writing tests overall.
4. I write more tests. 
5. My code is cleaner.  

I'm not sure if this is a cool cross-domain application of development thought processes or just an amazingly geeky idea -- like my friend using Scrum to plan her wedding (ahem). Regardless, I found it as a nice affirmation that the logic behind TDD is founded in basic human psychology.

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.

I was a little hard on the CodeCamp in my last post. It was a great event. I have huge amounts of respect and appreciation for the organizers, primarily Kevin Hazzard, Kevin Israel, and Andy Leonard, who has not yet left Richmond (good for us, less good for him).

 For somebody like me, who is trying to grow our little community of developers in Charlottesville, it was an inspiration. They were able to organize a top-notch software conference, provide it for free to the community, and then publicize it well enough to have a few hundred people attend.  That's incredible, when you consider these guys have very full day jobs, are working on books/articles, and are also speaking at and running local user groups -- incredible.

 As I said in my last post, my frustrations were 99% my own fault. And those frustrations haven't diminished; I just wanted to clarify my sentiment. The event was phenomenal; my experience at the event was frustrating.

Soooo. The Richmond CodeCamp ended a while ago. I have to admit that my experience this camp was a little frustrating, but it was 99% my fault. I'm hoping to draw up a list of lessons learned in the next few days to help me do better next time. For now, I've made a quick summary below.

Liked:

1. I had a great time at the speakers' dinner on Friday night. The speakers were a fun collection of people. Richmond really has a good .NET community leadership team. (And I got to meet Justin's wife Sara, who was delightful: charming, funny, and most amazingly, not overwhelmed with all of the geeky computer talk going on around her. I would have clammed up in that scenario. I appreciate people who can go into an intimidating situation and have an easygoing, relaxed gregariousness --I'm not talking about bravado or fake buddy-buddy-ness, just a comfortable manner.)
   
2. I was happy with my presentation, moreso the content than the delivery, though I was flustered.
3. My discussion with Sixto and some guy I recognize from Ric user groups about testing and architecture.
4. The bed at Spring Hill Suites, despite using it far less than I would have preferred.
5. Seeing Travis, Jordan, and Justin and all of my friends/acquaintances in the Ric user group community.

Disliked:

1. I got almost no value from any of the presentations I attended.  It was mostly me, not them, although I do have some critiques to make later.
2. I worked my ass off to get the presentation in a very good state, and it was completely wasted on almost everyone at my talk. 
3. Apparently several people thought my talk was about how to test software better at the system level...like how "testers" can work smarter. Of course, they didn't really get that excited by my talk full of coding samples to improve how developers can write unit tests better and easier.
4. I knew it was a possibility that only a few people would show at my talk, especially considering the super celebrity Amanda Laucher was speaking at the same time. And I had fears that the few people who did come would already know most of the things I was presenting. However, I didn't foresee the majority attendees to my session having zero interest in what I had to say. I just don't understand people who spend a full Saturdy on CodeCamp, but have no passion or curiosity for software development. 
5.  And the <10 people who did show sat mostly in the back row; so with the presentation booth in a fixed location, I'm screaming to talk to them 
   
6. AHHHHHG Not getting much sleep the last several night, compounding my other gripes.