diff --git a/source/_posts/2015-11-02-lightning-talks.md b/source/_posts/2015-11-02-lightning-talks.md new file mode 100644 index 0000000..9739013 --- /dev/null +++ b/source/_posts/2015-11-02-lightning-talks.md @@ -0,0 +1,98 @@ +--- + +layout: post +title: "So you wanna give a lightning talk" +date: 2015-11-02 13:39:25 +0100 +comments: true +author: Denise Yu +author_email: denise@codebar.io +categories: london + +--- + +At the beginning of weekly workshops in London, we encourage our coaches and +students to help kick off the session with a lightning talk. We're not strict +about the topics, but we ask that they be oriented towards programming, since +that's what we're all here to learn. We've had some +awesome lightning talks in the past, on everything from naming variables to +regular expressions to the role of programming in medical technology. + +I encourage everyone, students and coaches alike, to try their hand at +writing and delivering a lightning talk early on in their software development +career. It's one of the best ways to boost your confidence, and codebar is one of +the safest spaces for you to try something new. The process of organising your +thoughts and putting them into a slidedeck is not only great practice if you are +considering speaking at conferences in the future, I believe it also makes you +a more effective communicator and mentor. + +Thanks to Najaf's suggestion on Slack, I've decided to put together a quick +document here on how to get started with giving lightning talks, at codebar or +elsewhere. In general, at codebar we ask that you limit your lightning talk to +*five minutes* of presentation, with a few minutes afterward for questions. +Running over is okay, but we may cut you off if you start to go over 15 +minutes, because we want to give everyone enough time to do some coding! + +This is a loose list of guidelines, not a hard set of rules -- +compiled from my experiences at codebar and from over four years of university +debating. + +#### 1. Determine the scope of your talk. + +Generally, all technical topics are fair game, but some are better than others +for a 5-minute talk. If you're choosing a very broad topic such as "Deploying a +web application" or "CSS", try to narrow it to a specific sub-topic, for +example, "Getting started with the Heroku CLI" or "How CSS floats work". Sometimes +well-intentioned lightning talks run over time, or end up with less +substance than intended, because they are not properly scoped. It is also worth +pointing out that while talks about back-end development and hardware are +definitely welcome, the majority of students will be more experienced with +front-end web development. If you choose to venture away from front-end web +dev, try to err on the side of offering more context and terminology +definitions. + +#### 2. Structure the ideas you want to talk about. + +People often struggle with how to organise ideas for a short talk. If a talk is +disorganised, listeners may become confused or overwhelmed by information. I've +found that in such a short amount of time, there are two formats that tend to +work really well: + +- Explain a problem and a solution. + + Pretty much everything in the tech world is a solution to some problem. The + problem-solution format is a great way to give some context to what you're + about to explain. I find that spending 1 minute on the problem and 4 minutes + on explaining the solution tends to work well. + +- Divide up the talk into 2-3 key points. + + This is especially useful if you choose a very broad topic. For example, if + you are presenting about Sass, it's impossible to explain the entire Sass API + in five minutes, but you could pick your three favorite features and contrast + them to regular CSS. It helps to have some sort of generalisation or tie-in + at the end to give some overall shape to the talk. + +#### 3. Keep it interesting for your audience. + +At codebar, talks that are language-agnostic are much preferred over +presentations on language-specific features or frameworks. Students are at +different levels of familiarity with web development, so while you should not +shy away from presenting advanced topics, try your best to explain things in +plain language. Explain the impacts on end-users and the tech community, if +applicable. As a presenter, it helps me to always be asking the question, "Why +does this matter?" + +#### 4. Don't live-code. + +This is probably the most controversial tip, but please trust me -- live-coding +and "five minute presentation" do not tend to go together. If you want to +demonstrate something, prepare slides with screenshots, and invite students to +try it on their own afterward. Something always goes wrong, and it never winds +up being five minutes... + +Hopefully this provides a useful +jumping-off point for you to start writing your own talk. If you ever need +support, or if you have an idea but want to bounce it around before committing +it to a slidedeck, come on over to codebar's [Slack +channel](codebar.slack.com) (you can sign up +[here](http://codebar-slack.herokuapp.com)).