Add post about lightning talks

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: [email protected]
+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)).