We recently revived the lunch in learns for the programming department in the company I work for. We were all asked if we had any ideas for a session, and if we would be interested in doing a presentation. I've had a few ideas ranging from various topics such as:

How to think like a user when designing UI

or Differences in HTML5

A few coworkers I tossed these ideas around to seem to like them. However, I'd like some more ideas before I dig too far into creating a presentation.

What are some great lunch and learn topics?

  • 4
    Spaghetti code??! [best to be unveiled at an Italian restaurant]
    – mlvljr
    Nov 10, 2010 at 21:57
  • 2
    @mlvljr: I tend to throw my laptop at the wall to see if it will stick when I'm done coding
    – sova
    Nov 10, 2010 at 22:33
  • +1 for usefulness. I'm looking forward to making a list out of this question after it receives more answers.
    – user131
    Nov 11, 2010 at 8:07

8 Answers 8


Some general ones:

  • Test Driven Development
  • Debugging in [IDE of choice] (you can throw in things like remote or virtualised debugging as well)
  • What's new in the latest version of (could be an IDE, an database system, whatever)
  • Design patterns
  • Security factors in [technology of choice]
  • Performance factors in [technology of choice]
  • Continuations & closures (been reading Eric Lippert's fantastic series on this)
  • Overview of [new language or technology of choice]

But remember you don't have to pick general topics, you can do L&L topics on your own work as well. Arguably, this is even more valuable because the audience can get a feel for what you do (rather than assuming it all happens by magic). For example, your install guy could do a topic on how the install works, your QA lead could do a topic on preparing test environments, your build guy could do a topic on the build process, and if your project has an interesting architecture that maybe not everyone's aware of, then do a topic on that.

Also remember that your audience is not necessarily only composed of programmers. You may have QA guys and project managers in there as well, so don't assume that "Design patterns" isn't a valid topic because everyone must know design patterns.

Obviously you can't go into too much detail on some of these (for example, don't engage in a deep analysis of the pros and cons of every single pattern).

  • Debugging: just tell 'em there are some bugs in their meals, and start the lecture ;)
    – mlvljr
    Nov 10, 2010 at 22:41
  • LOL, I think the idea is to encourage people to come to the L&L, not scare them away!
    – JohnL
    Nov 11, 2010 at 10:41

You could play "Spot the Defect".

Go through your bug tracking logs and find some places where people wrote code that was plausible but horribly wrong in some subtle way. Rewrite the code to disguise where it came from but preserve the bug, put it up on the whiteboard, and have people:

  • see if they can find the bug
  • figure out what the fix is
  • describe how the bug could have been found during code review
  • propose changes to the language or tool that would have prevented the bug
  • and so on.

Neal Gafter and I put together a series of six "spot the defect" problems and presented them to the audience at the last Norwegian Developers Conference; it was a lot of fun, and I think people learned a lot.


Inversion of Control and Dependency Injection are powerful ideas that need to be much more widespread than they currently are.

  • 1
    The first one could be splendidly illustrated by making one's boss wash the dishes after. The guys will remember ;)
    – mlvljr
    Nov 10, 2010 at 21:57
  • 2
    @mlvljr: Actually, the idea of IOC is that you still wash the dishes, but now the boss also tells you how.
    – peterchen
    Nov 11, 2010 at 8:51
  • @peterchen Yes, that would be right. The Manager should know better ;)
    – mlvljr
    Nov 11, 2010 at 12:15

I have never participated in an L&L but it seems like you're basically working with:

  • something easily digested over the course of a lunch break
  • something that will help inspire discussion and interactive feedback

I think something like posing a question as to "how do you think we do X" and eventually revealing the current implementation would be interesting and thought-provoking for your listeners. You can abstract all the programming out of the equation so even non-coders could have a whack at it.

You could even abstract a complicated problem that your company faced as a riddle or puzzle. Like if you had to work with a square peg and round hole and eventually just chiseled down the square peg into a circular shape -- changing stock software to suit your company's needs.

I think any introduction that encourages technical thinking automatically opens up interesting conversation.

e.g. Time/Process optimization

How do you speed up your pie-serving waiter's operation? He serves a piece of pie and waits for the person to finish. He grabs their plate and takes it to the kitchen, then serves the next person. How can you satisfy your hungry customers more quickly if you don't care about dishes piling up?

I think simple metaphors to describe paradigms you use at work would be great food for thought while munching on a sandwich.


I suggest agile practices such as:

  • continuous integration
  • pair programming
  • stand up meetings
  • information radiator
  • planning poker

We mostly use our Lunch and Learns to cover new technologies that are coming out of the software stack we currently use.

So currently we are on a .NET 3.5/4, C#, Visual Studio 2010, etc. stack so we're doing some lunch and learns on the following topics:

  • Nu-Get (.NET Package Manager)
  • etc., etc.

Obviously your company may be on a different stack, but you could take the same approach.

This has worked really well for us as far as keeping up with technology, especially since the ASP.NET MVC framework and associated software is growing at a rapid pace.


I enjoy talks that discuss the history of something that I work with, especially talks that go in depth just enough to give me additional insight into my many 'Why is this the way it is?' type of questions.

A lot of people, for instance have no idea that PHP started as a simple set of Perl scripts for management of a (P)ersonal (H)ome (P)age.

If your company uses a lot of free / open source software, there is a rich history to discuss. You'd be surprised how many people think that Linus Torvalds wrote bash (when in fact he only ported it very early on).

You can research and dig up humorous, interesting and often informative anecdotes on almost any technology if you spend enough time doing so.

This has the additional benefit of including people who might not otherwise participate.


Depending on the audience, you could cover some basics and best practices, such as:

  • OO
  • Work through McConnell's "Code Complete"
  • Writing secure code
  • TDD
  • Design Patterns

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