Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I've watched 50 plus presentations on programming topics, although most have been online; example, Google Tech Talks -- and have ad-hoc experience on what formats work for programmers, or practices to take into account when presenting to a group of programmers.

That said, I'm open to any suggestions, but here's some topic of the top of my head:

  • Programming Jokes, Images, etc.
  • Posting Code for download
  • Contact Info
  • Collecting feedback
  • Presenting Code on Screen

If it matters, in this case -- I'm giving a presentation on using a scripting language to extract, transform and load data to a local user group who's focus is the scripting language; Ruby in this case.

Questions, feedback, requests -- just comment, thanks!!

share|improve this question

marked as duplicate by MichaelT, gnat, Florian Margaine, GlenH7, glenatron Aug 8 '13 at 12:30

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

Are there really techniques specific to the programming audience versus any other audience? –  Mark Canlas Feb 21 '12 at 16:15
@Mark Canlas: Yes, there are, though it seems like you're asking me to answer my own question, are you? –  blunders Feb 21 '12 at 20:39

10 Answers 10

up vote 27 down vote accepted

Don't read exactly what the slides say aloud

There is very few things more tedious than reading what it says, and waiting for the speaker to say exactly what the slide says, and moving on to the next slide. Repeat for 30 slides.

Keep the slides short with headlines, and say much much more than the slides state.

If you need notes, then put them somewhere else than on the slide.


share|improve this answer
crap, i'm attending this kind of presentations often. i'm a quick reader so i'm often bored to death :) –  Nazgob Feb 25 '11 at 23:46
While a great point, it's not "directly" related to the question. That being, practices in giving presentations that are specific to an audience of programmers. If I wanted advice on giving presentation in general, that would likely be off-topic. –  blunders Feb 26 '11 at 0:07
@blunders, the title of the question is "What are best practices when giving a presentation to programmers?". Why is this not a valid answer to that? –  user1249 Feb 26 '11 at 8:24
This is actually good advice for any presentation to any audience. –  ChrisF Feb 26 '11 at 12:47
As ChrisF states, the advice applies to almost all audiences. In thinking about it, the problem is while I do attempt to state the intent of the question in the description, it's not 100% clear in the question itself; which is my fault. As such, I'll just post a new question that's more clear on what I'm looking for... that is, advice that only applies to presentations given to programmers -- problem is, I can't think of a way to state it, any suggestions? Thanks for replying, +2 and selected as the answer. –  blunders Feb 26 '11 at 13:39

A white paper is often the best way to present programming topics. With a paper, you can have full code examples with detailed notes and best practices.

Thus, a decent live presentation would be a short overview of the white papers contents with a focus of what can be achieved with the technology and some live demonstrations. If you distribute the white paper with the presentation invitation, you can suggest it be read ahead of time so you can have an in-depth Q&A portion.

What can break the live presentation is getting mired in technical details. If something gets too particular, defer it to the paper's contents or to a later conversation.

share|improve this answer
+1 Like the white paper idea, I've in fact done that before and it worked well. Thanks for pointing it out, since I really haven't seen any presentation in person that did that. –  blunders Feb 25 '11 at 23:10

Test out your demo before hand. Nothing worst then trying to do a demo and seeing a big error message.

share|improve this answer
Agree, it's sucks to watch, and even more to know someone is wasting your time. There's going to be 50+ ppl there and going to be 40-presentation, 20-Q&A... that's 50-hours worth of people's time, I'm not going to waste it fumbling around trying to get something done. While super great presenters maybe able to wing ad-hoc style presentation, I'm not one of them -- 100% turn-key, bullet-proof, knowing it like the back of my hand; or at left my left hand, since I've got a crazy ass birthmark on it... :-) –  blunders Feb 25 '11 at 23:58
I was recently at a demo for a client and the developers decided to do some last minute changes. The client couldn't see 1/4 of the demo because of the errors. –  Lareau Feb 26 '11 at 0:15
With your topmost boss next to you and the world watching: video.google.com/videoplay?docid=7330891098684984608#. (Windows 98 demo) –  user1249 Feb 26 '11 at 8:49

If you're presenting a scripting language, why not fire your editor and write a small program? Create a small, real world program highlighting the languages strongpoints.

The guys at microsoft gave a great example when they presented F#.

share|improve this answer
+1 I've in fact watched someone do that... and it was super painful to watch... :-) ..Another time I saw someone cut-n-paste pre-written snippets as they were talking, that was less painful. One problem is that just likely posting code on the screen, some people might have problems reading the code. Think if I was going to do it... I'd pre-record a screencast segment for parts of the presentation that required live coding demos, zooming in on the text as I was typing; this way I could focus on the presentation. Thanks for pointing it out though, since it is a great suggestion!! –  blunders Feb 25 '11 at 23:05
Heh, yes. And if someone in the public knows more about the language than you do you might have some problems too. –  Carra Feb 25 '11 at 23:53
@blunders, prerecording the coding part of coding sessions sounds like a very good idea. Avoids having typing errors distract you and the audience, plus you are certain it is right when you go back to live to actually run the code. –  user1249 Feb 26 '11 at 12:17

Read Conference Presentation Judo. It is a presentation on how to give effective presentations given by the highest rated presenter at The Perl Conference. (Which was OSCON before it was called OSCON.) The advice is given in an earthy, direct, fashion. But don't discount it.

share|improve this answer
+1: The presentation "slides" along with the explanatory notes work really well. A great resource. –  user1249 Feb 26 '11 at 12:16
"The advice is given in an earthy, direct, fashion." I would guess this is one of his "presentation do's"? –  Buttons840 Feb 21 '12 at 16:17

One non technical tip. If you have slides, do not fill them with text and then just read the text out.

share|improve this answer
Doesn't directly related to the question -- that being, best practices specific to giving a presentation to programmers. Have any suggestions that directly relate to the question? Thanks! –  blunders Feb 26 '11 at 0:10
+1 After thinking over Thorbjørn Ravn Andersen answer, which is very close to your answer, decided that your answer is on topic. –  blunders Feb 26 '11 at 14:18

Presenting to Programmers? Then don't spend so much time writing code, use code snippets pasted into the editor (unless you're explaining the basics of a language or its syntax). Nothing wastes more time than hand writing code blocks to do tasks, when your focus should probably be on other areas.

share|improve this answer
+1 Agree, doing a live demo with hand coding is not the best use of people's time - and is just asking for a snafu. Code snippets are a step up, but still just a cut-above hand coding in my opinion. That said, really depends on the subject matter and audience in the end. –  blunders Feb 26 '11 at 0:15
Yep, the worst demo is watching someone type more than 5 characters :) –  anon Feb 22 '12 at 0:19

Well, the obvious starting point is always a hello world.

Other than that, I would probably try to organise it into five minute blocks, punctuated by Dilbert or xkcd strips.

Another idea that sounds useful is to keep it simple: developers are usually not very keen on marketing-style spin and buzzwords. You can also use the fact that they probably know how to write code in C/Java/some other common language, so you can start with something that resembles that, then refine the solution to introduce Ruby-specific elements and tricks. (This approach worked a treat when I was taught XSLT: we started out with a procedural-style solution, then worked our way towards the "proper" XSLT approach, highlighting the differences in the required mindset.)

share|improve this answer
+1 ...yeah, main focus of the presentation is going to be concepts of dealing with data processing - in part because I want to cover a lot in a short time, main covering the pros and cons of a given code bases to a given problem. Thanks for the reminder about hello world, Dilbert, xkcd... :-) –  blunders Feb 25 '11 at 23:17

I was going to just add this as a comment, but this talk given by Joel Spolsky is a pretty epic example. I think most people enjoy the misdirection he creates by starting out with Powerpoint and then moving into an actual demo about how easy it is to use the tool (FogBugz).

Honestly, I'd rather watch someone write the code live - even if you have to rehearse writing the code until you do it in your sleep.

I've played around a little bit with Ruby, and as a Pythonista I know that both of the languages are suited for rapid development, and (after writing the same code 3-4 times, just like you'd practice speaking) you should probably be able to write the code in the same time it would take you to talk about it. Then they would see how easy it is to write, read, and/or modify the code.

And since you're talking about loading data somewhere, for bonus points at the end you could modify your script(s) to go ahead and upload your code somewhere.

As a general guide, I highly recommend this book by Roy Underhill.

share|improve this answer

Don't try to tell folks Everything about what you are talking about. Pick one part of the topic and go into depth. Your goal should be to convince folks to want to know more about your subject not tell them every detail about it.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.