If you’ve had a talk proposal accepted or been invited to speak at an event, you’ll usually get a chance to chat with the organizers before you show up to give your talk.
While you probably have a good idea of the topic of your talk (if you don’t, that’s a post for another day!), event organizers can be invaluable in helping you frame a talk that will succeed with their audience. They are on your side and they want you to do great, or they wouldn’t be hosting you at their event.
These are two questions that I always ask the organizers before I speak.
Question 1: Who will be in the audience?
Knowing the basic demographics of the audience is necessary to make sure you’re speaking at the right level and tuning the cultural references and humor for the room. I often speak to audiences of highly technical engineers and to audiences of business folks about the same topics. These are very different talks.
You may already have a good sense of who will be at the event, but getting the organizer to tell you explicitly also tells you which population they are crafting the event to serve. It’s helpful to know who they consider to be the most important people in the room.
Question 2: What does a win for my talk look like to you?
This question prompts the organizers to tell you what they are hoping people in the audience will take away from your talk. Their response gives you more information about how you can successfully fit your talk into the overall event and specific goals.
For example, responses I’ve gotten have ranged from “I want people to feel inspired”, which tells me to emphasize the forward-looking optimistic topics that I plan to talk about, to “I hope they learn one practical trick they can use in their work immediately”, which tells me to focus on clarifying specific techniques, and so on.
The event organizers know their event better than you do, so anything you can learn from them ahead of time will be useful.
Yesterday I asked people on twitter for recommendations for things to read to improve as a programmer. I’m looking mainly for things on the philosophy side of software engineering. I do realize that practice is the most important thing, but sometimes you run into a design question and it’s always helpful to realize that very smart people have, indeed, thought about these things before.
If you see something that you think should be included, please do let me know in the comments and I’ll add it to the list.
The talks are a wide perspective on the interesting work happening around data in New York, and I believe you’ll enjoy all of them!
The New York Times has a story this morning on the growing use of mugshot data for, essentially, extortion. These sites scrape mugshots off of public records databases, use SEO techniques to rank highly in Google searches for people’s names, and then charge those featured in the image to have the pages removed. Many of the people featured were never even convicted of a crime.
What the mugshot story demonstrates but never says explicitly is that data is no longer just private or public, but often exists in an in-between state, where the public-ness of the data is a function of how much work is required to find it.
Let’s say you’re actually doing a background check on someone you are going on a date with (one of the use cases the operators of these sites claim is common). Before online systems, you could physically go to the various records offices, sometimes in each town, to request information about them. Given that there are ~20,000 municipalities in the United States, just doing a check would take the unreasonable investment of days.
Before mugshot sites, you had to actually visit each state’s database, figure out how to query it, and assemble the results. Now we’re looking at an investment of hours, instead of days. It’s possible, but you must be highly motivated.
Now you just search, and this information is there. It is just as public as it was before, but the cost to access has become a matter of seconds, not hours or days, and we could imagine that you might be googling your date to find something else about him and instead stumble on the mugshot image. The cost for accessing the data is so trivial that can come up as part of an adjacent task.
The debate around fixing this problem has focused on whether the data should be removed from the public entirely. I’d like to see this conversation reframed around how we maintain the friction and cost to access technically public data such that it is no longer economically feasible to run these sorts of aggregated extortion sites while still maintaining the ability of journalists and concerned citizens to explore the records as necessary for their work.
It’s easy to use:
b = Beacon() print b.last_record() print b.previous_record() #and so on
There’s also a handy generator for getting a set of n random numbers.
(One of the best gifts I ever got was a copy of 1,000,000 Random Numbers, and I’ve been intrigued ever since.)
Please note that this the randomness beacon is not intended to be a source of cryptographic keys — indeed, it’s a public set of numbers, so I wouldn’t recommend doing anything that could be compromised by someone else having the access to the exact same set of numbers. Rather, this is interesting precisely for the scientific opportunities that are possible when you have a random but public set of inputs.
Everyone does realize that it's not about teaching people to CODE as much as it is about teaching people to THINK … right?
— Hilary Mason (@hmason) September 17, 2013
I’m a huge fan of the movement to teach people, especially kids, to code.
When you learn to code, you’re learning to think precisely and analytically about a quirky world. It doesn’t really matter which particular technology you learn, as long as you are learning to solve the underlying logical problems. If a student becomes a professional engineer, their programming ability will rise above the details of the language, anyway. And if they don’t, they will have learned to reason logically, a skill that’s invaluable no matter what they end up doing.
That you can apparently complete a three month Ruby bootcamp and get a job today is an artifact of a bizarre employment market, and likely unsustainable. But by dedicating three months to learning to think in a logical framework, you’ll also gain an ability that will open opportunities for you for the rest of your life.
My ignite talk from last year’s data-centric Ignite spectacular is finally up! This was about a fun, personal project, where I was playing with NYC menu data.
Registration is open for DataGotham 2013, our second annual New York data community conference, September 12th and 13th. The core of the conference is a series of brilliant data practitioners telling the stories about what they work on. The content is technically-oriented but not all deeply technical, and we really welcome anyone curious about how New York companies and institutions are pushing the boundaries on data to attend.
We have two goals for the conference. The primary goal is to connect people in the greater New York data community who are working on interesting things. If our community is strong and supportive, we will all do better work.
Our second goal is to highlight the amazing working happening here, so that people near and far will realize that New York is the best place in the world to do data science.
Come join us to hear these stories firsthand and meet fellow data-minded practitioners! Register now:
(Readers of this blog can use discount code “IheartNYC” for 10% off, and I hope to see you there!)
This week we welcome a guest contribution. Matthew Trentacoste is a recovering academic and a computer scientist at Adobe, where he writes software to make pretty pictures. He’s constantly curious, often about data, and cooks a lot. You can follow his exploits at @mattttrent.
In Hilary’s last post, she made the point that your slides != your talk. In a well-crafted talk, your message — in the form of the words you say — needs to dominate while the slides need to play a supporting role. Speak the important parts, and use your slides as a backdrop for what you’re saying.
Hilary has provided a valuable strategy in her post, but how should someone approach crafting such a clearly-organized presentation? If you’re just getting started speaking, it can be a real challenge to make a coherent talk and along with slides that add to it rather than distract. This post provides tactics to help you make the most of that advice.
And that advice is… well, more than just advice. Separating the message of your words and your slides is nearly requisite for an engaging talk, and more importantly, absolutely necessary for effective communication. Your listeners are unable to read words and hear words simultaneously. If you put loads of writing on your sildes and speak the whole time, you can guarantee that they’ll miss one or the other. To get an idea of what I mean, try listening to a TV show and reading a book at the same time and observe just how much you remember of either.
I’m not saying that you should never put words on your slides (far from it). You should, however, need to think about how your slides and spoken words relate to each other. Your audience can either listen to you and ignore your slides, or they can read your slides and ignore you. Worse yet, when presented with two simultaneous streams of information, your audience will probably do a half-hearted job of paying attention to both talk and slides, missing much of your point.
Novice speakers often fail to recognize the difference between the talk and their slides. Hopefully this post and the last will have convinced you that they complementary aspects, not one and the same. Even when a speaker recognizes the difference, they often spend too much time on their slides and not enough time on their talk. Behavioral psychology tells us that when faced with an uncomfortable situtaion or task, we usually default to the most familiar aspect of it. If you’re a nerd, chances are your most familiar thing is sitting at your computer, working on the slides.
In reality, “working on the slides” usually translates to messing around with better fonts, better equations, better plots, better cat photos, etc… instead of figuring out whether or not you’re clearly and effectively communicating your point. Also, if you’re new to giving talks, you’ll tend to cram more words onto the slides to assure yourself you won’t forget them while speaking. (Tip: put all your extra reminders in the slide notes, and give the talk with your own laptop to make sure you have presenter view, it’s a life-saver)
To combat this common tendency towards slide-wank, I have one simple rule:
If your talk is N minutes long, you are allowed to work on it for at most 2N minutes before you must practice giving the entire talk again.
In other words, fully one third of the time you spend working on your talk must be spent practicing it. Out loud. From start to finish. For reals.
Let’s say you’re giving a 20 minute talk. This rule means you have 40 minutes, max, that you can work on your slides before you have to stand and present it. This counter starts the minute you open powerpoint/keynote/deck.js. You’ve got 40 minutes to frantically type titles and copy/paste cat photos into your blank slide deck, then you have to stand up and give it.
Yes, that’s 40 minutes to go from blank slides to giving a 20 minute talk to your dog.
Yes, you will be completely unprepared.
Yes, you will forget why at least one slide is there (despite having made it less than an hour before) — then remember 5 slides later, then ruin your train of thought by going back to explain it.
Yes, it is going to be brutally uncomfortable.
Yes, that’s the point.
The point, however, isn’t to be sadistic just for the sake of it. In the end, you won’t be judged on how flashy your slides are, but by how effectively you’ve told your story. If you are unused to speaking, getting up and giving a talk can be really uncomfortable. Even if you are used to it, trying to iron out talking points can still be really frustrating. It’s so much more comfortable to fiddle with fonts and images, so we need hard rules to keep us on the level.
There are two big benefits to this approach. First, it forces you to focus on the speaking. Do your slides (and the ideas that they contain) flow coherently from one to the next? Does one part drag on while another feels rushed? Does that one section even make any sense? When rehearsing your talk, you’ll rapidly identify troublesome portions that you would have never noticed if focused purely on how the slides look. On more than one occasion, I’ve had to delete super-fancy-looking slides because I just couldn’t weave them into my narrative.
Second, this approach forces you to get really good at messing up. It goes without saying that more you practice anything, the better you’ll be at it. Practicing your talk will expose places where you’re likely to mess up, so that you can focus more effort on making it through those sections. Most importantly, all of your practice giving the talk in a highly-unpolished state will teach you to push through any accidental misspeakings. By repeatedly practicing your speaking parts, you’ll have said every part of the talk in a dozen slightly different ways. You will become comfortable with flowing into and out of every point using slightly different words. When you accidentally say something unintended on stage, it won’t be as nearly as stressful. You might not be able to smoothly deliver the entire talk, but you’ll be far more confindent and able to recover from messups much more gracefully than you otherwise would.
The end goal is to stand in front of a room of people and say something that they will find interesting. Your words, your slides, and time spent rehearsing work in service of this goal. We all like to fiddle with stuff on our computers, and it can be hard to keep the narrative in the spotlight when deciding between 16pt and 17pt fonts. Following hard rules when preparing a talk ensures you focus your energy on the scariest part: the speaking.
Slides are the supporting structure for your talk, not the main event. Speak the meaty and informative portion of the presentation out loud and use slides as a backdrop to set either the emotional tone or reinforce the message that you are trying to convey.
For example, I love using this image of Obama in Berlin as a backdrop when I talk about the growth of social data over the last several years. In this image every single person has a device and is generating their own data about their shared social experience. The content of the image supports what is otherwise a fairly abstract statement, and you can feel the excitement of the crowd, boosting the excitement that I want to share about the possibilities of social data.
This is a particular style of slide design will fail for situations where “the Powerpoint” will be shared independently of the talk, and it’s not appropriate for all content, but it is a ton of fun when you can get away with it and uses people’s expectations about what they are going to see (a speaker and some slides) to create a more compelling experience.
This article is part of my series of speaking hacks for introverts and nerds. Read about the motivation here.