Archive for September, 2011

Almost a year ago I said I was taking a break for speaking, with the main reason being I wanted to focus on getting out of my comfort zone and learning stuff (which I did, if you’ve been following my posts on Rails, Mac, etc.). In order to help with my learning I also attended to conferences, which was great. In doing so, I’ve also picked up a couple of things *not* to do after analyzing certain things that a couple of speakers tend to do.

Your screen projected out to two big screens

It’s usually a good thing for the speaker to walk around once in a while, and maybe point things on the big screen while doing this presentation. However, if the computer is hooked up to two or more big screens, pointing things out on one of the screens SUCKS for the audience. People on the other side of the room probably can’t read what you’re pointing at, or it’s very likely that you’re standing right in front of the screen and they can’t see a big portion of it at all.

So what’s the solution to that? One option would be to get one of those laser pointers, and use that to point at one screen, and then at the other screen, which you can do from a distance. Or maybe get *two* of those, so you can point to the screens at the same time! If you get a fog machine going, that’ll make you look like the super Geek Jedi! (but then, people may not be able to read the screens anymore).

All joking aside, the real remedy for that couldn’t be simpler: use the mouse pointer, which is *always* showing up on all screens!

Showing slides containing code listings

I’ve seen speakers showing slides that only contain code. That is a good way to present code in the flow that fits your presentation. However, I’ve seen speakers packing so much code in a single slide that people can hardly read what’s on it. Worse still, the speaker talks about what the code does, but the audience has no reference to know where exactly on the screen they should be focusing on.

There are certain things one can do to address that:

Refactor the code so there’s less to be listed on screen! 🙂

For the cases where the code can’t be shortened, make sure you can easily zoom into the sections of the code you’re explaining. That’ll give the audience a reference as to what part of the code you’re talking about, *and*, it’ll make it easier to read due to the bigger fonts.

More tips

A couple of the sessions I’ve attended to recently reminded me of my When the geniuses talk or write… Zzzzzzz… post. I sit there thinking, “you see, that’s already a complex topic, and you’re making it look even harder. Is it because you want you took look smart, or me to look stupid, or you are just oblivious to it?“. I believe that the 80/20 rule applies here: 80% of the people that goes to a session doesn’t know much about the topic and want to learn, and 20% of the people already know something about it and would like deeper knowledge. If the second group isn’t happy for not having in-depth content, they just walk out and go find another session. In my mind, it’s better to lose 20% than 80% of your crowd (the 80% crowd may not walk out on you, but they’re likely to give you a bad rating if they didn’t learn anything from you).

There are plenty of other blog posts our there with tips for presenters. Here are some that I think to be pretty good:

Houston TechFest 2011 is coming up in just about a month from now: October 15th. As usual, it’s free. As usual, there’s a TON of content: 16 separate tracks this year! If you live in Houston, surrounding area, or just feel like coming down for a great event, make sure to register!

I’ll be presenting three sessions there:

Adventures of a .NET developer in Rails land

After several years of working almost exclusively with .NET, I started looking into Ruby on Rails; different language, framework, tools, mindset. In this session I go over the findings that were important to me, the main source of difficulties, what resources were helpful, the things I enjoyed the most, etc. Attendees to this session will learn what they need to know in order to get started developing Rails apps, or at least learn things that might help them approaching things in a different way when doing .NET development.

There are several ways to introduce a feature to a Rails application (or to any app for that matter). In this session we go through one of the ways which we feel works pretty well. It involves discussing the feature, writing feature user stories, creating screen mockups, writing Cucumber tests for application behavior, writing RSpec for object behavior… The whole enchilada, as one would say.

I’m very pumped by all of these sessions. Both the Rails ones are brand new ones. The “introducing a new feature” one I’ll be presenting with my buddy Ben Scheirman (we have started working on it yesterday, and I think it will come out great!).

And last but not least, I’ll do the one on Virtual Brown Bag the same way I did it last year: it’ll be a *live* Virtual Brown Bag meeting, where I quickly explain to people what these meetings are all about, and then we just share a bunch of stuff (tips, tricks, techniques, tools, etc.).

As somebody who’s been a big fan of working with multiple monitors for sometime now, I had my Mac hooked up to one of my big monitors. Given that I also have an iPad, I’ve just recently added it as my third monitor, by using the Air Display app for iPad/iPhone ($10). It works really well! And considering I already owned an iPad, this is the cheapest extra monitor I’ve added to my setup.

The iPad sits on the far left side, and I normally put a Terminal window there, where I’m running my commands, tests, deployment, etc. The screen on the Mac is where I normally have the browser showing the website I’m building, and the monitor to the right of my Mac normally has my IDE. That monitor on the far right is hooked up to my PC, which I use for my music recording, video editing, research, running the Virtual Brown Bag, etc.

I have tried to use Air Display to make my iPhone as yet another monitor (to maybe put small notes or instant message there), but that didn’t work too well for me. But I’m really digging having my iPad there. It’ll also come in handy when I’m on the road.