Tips on presenting at a conference

So I stumped up my £95 (+VAT) and decided to go to the Open Source and Finance eXchange. The day had some fairly interesting topics which unfortunately were (more often than not) ruined by poor presentations. This was particularly irritating as this was a paid conference and I expected a minimal level in the quality of speakers.

Of course the great value in going to a conference is always the interaction with the other attendees, but still it was a little disappointing.

So I thought I'd point out some tips for presenting at a conference:

1. Be passionate in your delivery, no-one and I mean no-one is going to care about what you are talking about when you deliver it in a dull monotone.
2. Don't let that screen saver/power saver cut out your presentation!
3. Slow Down - Often people are nervous when they present, which is only natural, but it means that they have a tendency to speak far too quickly.
4. Slow Down part 2 - If the language you are speaking in is not your first language, or if you know you have a strong accent, then again for the sake of clarity, slow down!
5. If you're going to have graphics in your presentation, make sure they are readable when they are projected on the screen.
6. Don't use complicated graphics, keep it simple! If in doubt get a Graphic Designer to take a look for you.
7. Don't just repeat what are on your slides, the audience has already read them and you're adding no value.

Thankfully towards the end of the conference we had some good speakers including probably the best presentation I've ever seen at a conference. If you ever get the chance to see Simon Wardley (from Canonical) speak, then do yourself a favour and go and see him. The podcast of his talk will arrive here soon.

PCGen - An awesome online community

Hi all,

Just a brief note on one of the important points in running a successful Open Source community. A key ingredient is to give immediate feedback to users that post on your forums and mailing lists.

An attitude of 'Go and find it yourself Newb!' is not a particularly healthy way to attract new users to your community. Don't forget that a new user is potentially a new volunteer for your project!

PCGen _excels_ in this area, no question big or small is left to rot on its boards and the responses are always cheery and polite. If you're looking for an example of how to respond to your users, look no further than the various mailing lists that exist under the PCGen banner (you can find them via the website).

The Ubuntu forums are another fames place for this type of attitude and it's certainly helped build their popularity as well.

So here's a public thank you to the tireless volunteers and community users who take the time and effort to continuously reply to the tons of queries we get at PCGen, well done to you all!

How to be a Rock Star Developer

Here is the Google Wave text that was taken down by some helpful community members from my talk at the recent London Java Community Unconference.

I plan to expand greatly on this talk with hard examples of the various points, let me know if you've got any useful examples you'd like to add!

Get the Rock Star attitude

• Be passionate, care about the code
• Be a leader - look at new approaches e.g. BDD, New JVM Languages
• Be personable, stop and listen! - The person who directs a project the most is one that is the most effective communicator
• help newcomers, they give you a fresh perspective - explaining things helps your understanding

Be inspired by the rock gods

• Don't reinvent the wheel, covers are rarely as good
• Read blogs and community sites - stuff that is not part of your every day blogs - e.g. Kathy Sierra - high level thinking
• Stand on the shoulders of giants - smart people have tread that path before, so use their insights

Be part of a band

• dont code in isolation - everyone needs a team - coding in isolation leads to be lost in your own little world - very few ideas / service that you can build that a team can't do better
• Talk to the users early
• The developer who communicate has most influence - many ways to communicate, try do it as clearly as possible to be effective
• Bounce ideas off others - a wider audience can give you a wider range of feedback than your local team

Play a Fender Stratocaster

• Do development on a fast PC
• Use a big tft screen or have several screens
• Make your environment comfortable

Open your mind

• Learn how to look up reference material, trying not to learn api's verbatim
• Read books on development - podcasts, video clubs etc
• Read code by the experts - many references externally and internally
• Learn a different type of language e.g. if you work with an OO language, dabble with a functional language, shell script - avoids the Golden hammer

know your studio

• Learn your ide inside out to be as productive as possible - saves 5,10,30 mins then hours a week
• Run a continuous integration server - early feedback
• Use source control - don't lose those songs - big investment bank lost all source code because of 2 primadonas keeping code locally and had a power glitch.
• Know your OS/Hardware/System Architecture - sockets open, threads, etc

Rehersals

• Go back and enhance your old code - how do you convince the management - discuss financial impact of leaving bugs / features in the system - continuous cycle of self improvement
• Get cold hard feedback - dont be too precious about your code - OSS has the source of a thousand eyes - commits go to a committers mailing list so people know what to review and can give feedback early - using patch files - fisheyes - no one writes perfect code
• At least briefly research yourself before asking others - use google instead of embarassing yourself on a public mailing list
• Run test suites

Polish your songs before the album release

• Keep source code neat and tidy (Checklist) - read The Daily WTF website for examples of bad formatting
• Reduce the simple bugs (PMD, Findbugs and more) - use Find bugs to give you better ways to do things, like an expert on your shoulder
• Comment you public apis (Javadocs) - if you provide an API define at least what to call and what to return, to otherwise people will not want to use it