How to present a "Brown Bag" Seminar to Coworkers?

Question

Let's say, hypothetically, you have been chosen to give a presentation to your coworkers on the language about which you are most knowledgeable. How do you make it interesting?

It seems easy enough to write a basic overview: This is what it is used for, and here is some background info on it. You make a slideshow of that material and mix in some examples. But how do you make the examples both interesting and real-world-problem-oriented?

I have done these both in college and in the workplace, unfortunately I am still not good at it. I find that my examples tend to be hit-or-miss, where people will say "that's perfect, I need to do just that!" or "wait.. why would I ever do that?"

So ultimately, my question is: How does one present on a language, keeping it informative, relevant and, most importantly, interesting? What would YOU want to know about a language with which you are only vaguely familiar?

EDIT: How do you create audience interactivity for a programming-related presentation? Is it something of a "how do you think this would work?" Possibly creating code examples that require some audience input?

Answer 1

I've always found presentations that engage the audience to be the most beneficial. My favorite presentations have involved a whiteboard, markers, a few audience members and a problem.

Answer 2

Make sure you show code examples (live demostrations) along with theory, and make the presentation interactive.

Also make sure you understand your audience. You probably dont want to cover more advance topics with begginners without going over the basics. I.E. make sure someone understands the .Net Framework before trying to explain to them what a lamda is...

Answer 3

It depends on your audience but beware of overly technical explanations.

Focus on real life projects where the language is utilized, and explain why the language enables the project to be more efficient/faster/better/stronger etc. Impress people with real world capabilities and implementations.

For instance, if you were to give a presentation on ASP.NET MVC I would focus less on the technical aspects of MVC (read: bare minimum) and more on what sites (stackoverflow.com!) have effectively used the technology to save money/time/expansion costs. If you want you can go back and drive the point home by using another project written with a different language architecture and compare how the language effects how successful the implementation was and why.

The most effective technical presentations I have seen on language have been very general but have always left me googling specifics later that day on my own time. And that's what you want.

If it is a technical audience you can focus a bit more on the nitty gritty; But even then, don't do it too much or your audience will be bored out of their minds.

Also; Try to avoid PowerPoint. If you must use it, study Steve Jobs. Don't crunch a million technical aspects on a single slide. Show simple diagrams and code that won't distract from your lecture.

Answer 4

keeping it informative, relevant and, most importantly, interesting?

Beer. Nothing cheers the good-ol' hacker like a beer.

You may also want to take the simplest of programs, and build on it, challenging your audience before taking the next step. It's great if you can offer a peek into the history/rationale of the feature, how it is linked to VAX PDP-11 and so on.

Answer 5

I have done these both in college and in the workplace, unfortunately I am still not good at it. I find that my examples tend to be hit-or-miss, where people will say "that's perfect, I need to do just that!" or "wait.. why would I ever do that?"

If it's before co-workers, then base the examples on something they can relate to. Make it something that they could experience in their jobs. Don't try to overabstract your examples.

If you dare to do it, and you want the presentation to be a bit more interactive, you can ask them for some examples and solve them together. However, depending on the audience, it may be a good idea to prepare a few yourself, just in case :)

Answer 6

I've given some presentations like this, and a few useful tips I have are:

• You're not trying to teach your audience the language, so don't dwell too long on explaining syntax. For the most part, your audience will be able to infer most elements on their own without your explanation.

• On that note, try to refrain from walking through your program and explaining every line of code.

• If you're presenting a new language, it should be different enough from the language your users are alerady familiar with. What killer feature/framework have that language X have that language Y doesn't? What domain of problems can language X solve that are hard to tackle in language Y?

  • The more different your languages are, the better. For example:
  • It doesn't really do much good to contract VB.NET with C#, since they are roughly identical and solve the same set of problems in equivalent ways.
  • You could compare VB.NET to F# by noting the different coding style and built-in functionality they have.
  • It can be enlightening to contrast VB.NET with Haskell, Erlang, Prolog, or Joy.

• If you're giving a presentation which relies on an external server, HAVE A BACKUP! I attended a small .NET conference where the presenter was describing Ruby on Rails -- what could have been a fascinating presentation turned into a visible and public failure. The presenter relied on several external web servers for his presentation, but none of them were cooperating that night.

• If you're going to show lots of code samples, have them pre-written and readily accessible. Nothing's worse than typing out large amounts of code while your audience twiddles their thumbs waiting to see what it does.

• If you're showing lots of features, keep the code samples small. However, you should have one or two non-trivial applications to demonstrate as well.

• Audiences like GUIs, even where a console app could adequately demonstrate the code you're trying to show.

Answer 7

I've done a few of these brown bags. I was fortunate enough to be invited to do it with a small user group where there was a specific goal, like "show the QA team how to write automated tests with Selenium" or "show the data team how to write a custom CSV processor in ruby".

These are great because you know what you're aiming at and how to keep it relevant.

Programming can be very difficult to teach, so it is really important to bite off a reasonable chunk. It takes a long time to explain just a few concepts, so pick something small to explain.

For a general language presentation though, here's an approach I've found effective in explaining the basic features of a language.

I tell them that there's three features to every real programming language: sequence, selection, and iteration.

You can do every programming task with just these three concepts, and you don't need anything else.

• Sequence - Show how your programming language gets read in sequence, one line at a time. When a function is called, program flow goes to the function, and then returns to the main program flow.
• Selection - If this is true, do this, otherwise do this. Show the if/then logic in your programming language, and the basic idea of boolean decisionmaking. Talk about how all complex business logic ultimately boils down to a bunch of nested boolean decisions.
• Iteration - Loops. Don't show for loops. Show foreach. You have a list of some sort, you work with each item.

I like these three concepts because they're a complete presentation. When someone knows how to do these three things in a programming language... then they can basically program in it.

In your note, you asked, "How do I keep it more interactive?" This is a good question, because it's one of the hardest and most important things. When people are sitting there absorbing programming concepts and struggling with syntax, it's not the best idea to put them on the spot with specific implementation questions. It's much better to ask conceptual questions like, "Ok, so you have a list of data, what's a good way to start turning it into an ordered list?" In a way though, it doesn't matter. They don't have to so much be involved as feel involved.

I hope that helps.

Answer 8

Feel free to make it up if you need to, but sometimes telling a story (interesting, of course) keeps the audience engaged more than just presenting facts.

Answer 9

Rule One: Candy! it's cheep, a little childish, but it works. I have never met a group of Techies that will not get more involved if you start throwing out candy. Use it like a game to get them to ask questions, encourage discussion, etc.

This will force you to interact with your audience and them to interact with you, let's face it we have all sat and listen to some guy go on and on about something, with out interaction we loose interest.

Rule Two: Type as little as possible, use code snippets, pre-written code files, whatever, nothing is worse then tying to type in front of an audience, with the passable exception of watching someone try to type.

Answer 10

I did a brown bag on "Responsibility Driven Design".

1) I took some basic material from books and papers and distilled it down to a few basic points I wanted to get across. Better to get three really important points across than a bungled attempt at ten(!)

This is a bit of a sales pitch - you need to establish in the first slide or two why they should listen. My second slide was titled "why you should care..." Most programmers are enthusiastic enough to learn lots of things themselves - so you just need to present the bits which get their attention.

2) I made slides from those basic points - extracting the key diagrams and charts. (I kept most of the words off the slides - better to say them than have "death by bullet points".)

3) I came up with some examples of refactorings from the codebase the team were working on - I showed "before" and "after" slides of each example so that you could see the points I make in terms of code they dealt with every day.

For a programming language presentation I'd look at some code that they're going to be interested in and try showing it as it is now as a "before" and then show it re-coded in the new language.

4) I came up with a little exercise based on some work we were planning to do soon and got them to break up into groups of 4 or 5 people to work on the problem. (Two groups of 4/5)

You might want to try something simpler with a programming language - try to get them to put together a little program. You supply most of the instructions but they get to put it together.

5) Get them to present their work back to the whole group.

There's two goals here - 1) understand the new material and 2) see how the new material fits into the work at hand.

This formula should provoke enough discussion about how to use the new material on the job.