First of all, thanks all who had their valuable time spent on my talk about F# at EMC Conchango.
Thanks to Michelle for beers, to Zi for finding an HDMI cable at the last minute, to Liam for lovely chocolate cakes, to Argos for support, and to everyone for coming…
It was my first talk in England, and as it was a public talk, I was not sure about the content, examples. Even if I am coming from a trainer background, and I know that different level of people had attended my .NET Courses, it was quite hard to decide the depth of the subject, and to deliver the message I want to deliver. Every decision has a drawback, going simple can bore people, whereas going into complicated scenarios can leave some people out.
Rather than taking the challenging option :
– I decided to name the talk as “Intro”, so I thought meeting the expectations would be easier.
– Rather than going theoritical and covering more aspects of F#, I wanted to go over a simple demo, and share the feeling of writing in F# with VS2010.
Thanks God, it was not a disaster, and I got comments to work on, and improve, which is always good.
1. A complete sample:
My presentation was missing a complete sample, as my demos were quite small sized examples. When the seminar finishes, the audience would have felt more satisfied, if I had started and finished an F# project.
I had thought about this beforehand, but was not sure if I could have a project which is “simple” enough so that the audience can follow, “clean” enough so that I do not have to hacks during demo, and “complex” enough so that the audience would take home and work at home. I admit it is hard, but not achivable.
2. The balance of the slides/demo
Interestingly I got a feedback telling that I was better when I was coding during the presentation, and this was quite unusual for user group events; and I got feedbacks telling that I was disconnected from the audience while I was coding, so my mood/excitement was negatively affecting my touch to keyboard, and I was seen more confident while I was doing the talk and answering the questions.
Making everyone happy is impossible of course, but I can take both feedbacks as sensible. After seeing 50 people in the room, [full room, with people sitting on the edge of the window], my confidence has jumped out of the window, instead of myself. I reckon, the less perfection I am, the more communicator I will be.
I love coding, so coding during the whole session would be my pleasure, but there is the other feedback comes into the screen:
3. How well you know your keyboard/touchpad/mouse?
The audience does nothing but sits and watch your coding experience. Little tweaks, multiple corrections to your mistakes does make your audience confused and breaks their focus. Bringing a keyboard/mouse that you daily use is the suggestion and I will try to take this one. Working more on my new laptop is the other option, and is a good alternative obviously, but it would never replace my keyboard used 8-10 hours a day.
What happens is that they may either start to interest into something different or start to sleeping. Worse than that, they may start talking to each other. Talking more about what you do and doing less changes at a time, does keep everyone back on board.
4. Communicating contact details
As the questions can be tricky during the session, you may need to give the answers later. But if you have not included your contact details at the end of the presentation, there is a high probability that, you will forget to tell “I will post the answers to my blog as soon as possible” as I forgot.
If you have anything you want to add, please do!