Here’s my battle tested recipe for giving amazing technical presentations.
Prelude
Have a Topic / Know Your Topic / Know Your Audience
This recipe assumes that you have something interesting to talk about. It assumes you know your topic, the better the better, but you don’t have to be an expert. Especially, don’t sweat that there might be someone in the audience that knows more. Don’t be afraid to say “I don’t know” to questions, deferring it to looking up the answer.
You are on stage, this is your show.
Performance > Content
Again, you should know your stuff, but more important than stating what you know is how you state what you know. A presentation in front of an audience is 90% performance and 10% content, or 80/20, doesn’t matter really.
You don’t have to be a great entertainer, but people look up to confidence, be bold. If you are not usually bold, assume a stage persona that isn’t actually the frightened you. Put on a masquerade, a show for the masses. It is totally okay for you to be frightened, but the audience need to never know.
And never forget, even the most professional speakers, musicians, anyone on a stage, is frightened and nervous before the gig.
With that out of the way, here’s my recipe for giving kick-ass technical presentations, based on my experience giving and seeing many good and many more bad technical presentations. My thanks to all the speakers that I could learn from and to anyone who has ever given me constructive feedback.
The Recipe
0. Hello
Say hi, introduce yourself, give a bit of a background, say thanks for being let on stage. Build empathy. I am one of you, we share the same problems/goals/values etc. We understand each other.
2 minutes.
1. Scope
WOHA.
Grab your audience’s interest. Make them listen, ask intriguing questions, or make some outlandish statements that you come back to later for clarification. Build enough suspension to keep your audience’s attention.
Manage expectations Here’s what’s going to happen, and this is why it’s relevant to you.
3 minutes.
2. Show & Tell
BOOM.
Blow the audience away. Answer the questions you asked before, back up the outlandish claims you had. Sing, dance, do whatever it takes to get your audience to drop their jaws, two, three times.
If you show off some software, parade it around, try a live demo, or point out important snippets and results. If a demo is hard, pre-record and talk over a video.
Start with your strongest point first.
Make weaker points more relevant by binding them to the previous point or using them as a segue to the next one.
Have a narrative that carries you through your talking points.
End on something concise your audience can tweet.
10 minutes.
3. Details
Yadda, Yadda.
Here is where you get to explain the magic. You get to dive into technical details, you get to explain the design philosophy behind your topic. This is where you win your audience’s hearts.
10 minutes.
4. Thanks
Say thank you. Take a breath, you are done.
5. Q&A
Huh?
The Q&A serves multiple purposes:
-
it gives you feedback on how well the talk went / how relevant the topic was to your audience. The more and the harder the questions, the better.
-
it gives you feedback on what to do better next time. Maybe there is a point you forgot to make, a connection that you didn’t walk the audience through, maybe there is a technical aspect that many are interested in.
-
it gives you an opportunity to do a deep-dive into a topic that you only mentioned briefly, or not at all, before.
5 minutes.
Bonus Material
Know the rules, then break them.
❧
I’ve heard before: What’s the harm? Why not at least try to include ‘Hey there!’ if every little bit helps? Somewhat of a fair point. Using a word does no harm in the same way a daisy does no harm to your front lawn, or a shade of grey does no harm to your shadow.
Here’s where I’ll join the rest in unquantifiable hoodoo: I believe words are aesthetically damaging. I believe a white space free of words is more pleasing to the eye, more easily consumed, and thus more likely to be retweeted (which is a proven way of growing your audience).
Hear, hear.
❧
These are my notes from my Node Dublin talk about “Open Source Communities”. I don’t think I did the title justice in the end, but I’ll keep it for consistency’s sake. The video shows that I was fairly nervous giving the talk and I wasn’t quite happy with the sound engeneer and my snouting into the mic while breathing. For those of you who can’t stand to watch, here are the notes.
Welcome
I am Jan Lehnardt: @janl, Apache CouchDB, mustache.js, JSConf EU.
Open Source Communities
I was gonna look at Node through the lens of other Open Source communities I had been involved in and conclude that by avoiding most of the mistakes it became the most exciting community of all time.
Lukily Isaacs and Mikeal made a way better case for why Node is successful, and why the key success is not yet manifsting itself in dominating anything, but setting us on a trajectory to disrupt all of IT (and if you believe Clay Shirkey— and you should — disrupt society & politics).
To reiterate, Node’s core accomplishments are:
No language war. JavaScript is good enough.
- Small Core.
- Clear Module Abstraction.
- Non-Leadership.
- NPM (I add).
And finally, Node’s whole premise is to be good at building networked servers.
Not be an immersive development environment, like .NET, Java, Cocoa, or frameworks like Rails, Django & the like.
It turns out that the concept of a neworked server is a really good abstraction for building all sorts of software.
So by trying hard to avoid being everybody’s darling, Node focussed on one thing and perfected that thing that makes it everybody’s darling.
(My dayjob is working on Apache CouchDB. It is written in Erlang.
The whole programming paradigm of Erlang revolves around building miniature networked servers that do one simple job for robustness and fault tolerance, easy of reasoning and finally parallel execution, and to put them together in a way that creates bigger software, not just servers.
Many other components of desktop and mobile software can be expressed as being a networked server.
Heck, even the original definition of OOP is independent entities that hold data and have behaviours attached that would send messages to each other to invoke that behaviour.)
World Domination
With the keynotes yesterday morning and after looking at all the fantastic technical talks we saw over the past two days I hope you get a sense not only for how succesful Node is, but also why, and why that is even more important than the current success.
Taking a step back.
We can now build entire systems in pure JavaScript, frontend and backend and this is significant.
We can also control flying quad-copters and robots and power moblie experiences.
We are bridging all fields of computer science from the hardware up to fancy 3D rendering. All in JavaScript.
And all of it is becoming good enough, in the same sense that JavaScript is good enough to be the language of Node, to go out and build everything.
This is where this talk becomes emotional.
We, the people in this room, the ones at the other Node conferences, the JavaScript conferences and the frontend conferences and the people out in the field, we are going to be building the next genration of software, infrastructure, products, everything.
We will be powering the ongoing digitalisation and networkification of the world, of commerce, of governments.
Not the enterprise Java folks, not the PHP people, not Rails. Us.
That isn’t to say the others won’t have their place, but we’ll have lion’s share of things to do.
To invoke Clay Shirky one more time: they are from a time before GitHub.
Social Responsibility
Taking another step back, a couple in fact.
We, the programmers, the designers of the world, we have an incedible gift.
A gift that nobody else has, and many have tried to gain for millennia: We can create gold out of thin air (or, maybe out of thick coffee).
A show of hands, who here in this room considers to be in her or his dream job? We get to dictate the conditions of our employment.
We dictate salary, we dictate working hours and we dictate what we want to work on. Nobody else has that freedom.
Yet, we are relying on a society that “does their job”.
Many of the speakers here have come from far away to share their thoughts with us and to hang out, to have fun.
We came by plane, rode in cabs, staying in hotels, or friend’s houses.
We enjoy coffee and lunch here and in the city, use public transport.
We build upon education, rely on medical service.
All of it built & run by people who do their job, that do not get to dictate salary, working ours or what to they fancy to work on.
We live such abstracted lives that we can concentrate on creating immense value from literally and figratively nothing.
On top of that we get paid ridiculous amounts of money (absolutely and in comparison) to do so.
It is absolutely fabulous, and I love every minute of it. It is an immense privilege that I get to live this life. A life I choose.
But reflecting leaves me with a sense of responsibility towards my fellow people.
Those who don’t get to burn through billions of venture capital money to play table tennis all day.
Not the ones that actually manage to return an investment and make the obscenely rich people even richer.
At the expense of innovation, at the expense of personal freedom, prosperity, security.
Jeff Hammerbacher said: “The best minds of my generation are thinking about how to make people click ads, that sucks.”
I agree and I feel responsible to build a future, technologically and socially that values humanity over profit.
I hope you feel that responsibility as well.
(We Are) The Future
Given the premise that we, the people in this room, are on the verge of setting the stage for the world, what can we do to make sure our reign will be rememberd as a good one?
And given that we accept that through the way things are set up today, that we are in an incredibily privileged position that comes with a social responsibility, what should we do with it?
I’m not here to try to plaster my own agenda over you. Instead, I’m sharing a few points of view to encourage you to actively think about your own.
Take Mozilla.
Where a non-profit organisation owns a for-profit company.
The non-profit keeps to set the goals for the company, while the company uses capitalism, markets & money as a tool to build stuff that benefits everybody.
Firefox, Persona (née BrowserID), Do Not Track. All build expressly against finanical benefits of one single institution.
Why don’t we have more organisations like this?
Nerds imagined and built Mozilla.
We can do, too.
Imageine a mobile carrier, that is set up like Mozilla.
Globally run, with the user in mind, engaging the community for support.
Imagine sane data-plans, free roaming between GSM technologies and community provided wifi.
Net access for everyone, cheaply, not bullshit telcos that just screw over everyone, when their job is administrating a public resource.
Let’s build a mobile carrier like this. You and me, let’s do this.
Better yet, let’s encourage others to do this as well, let’s build ten, or a hundred.
Let’s take this idea and apply it to many many more areas of life.
Or, in Mikeal’s footsteps, defy organisations, just build stuff in losely coupled communities that circumvents and dominates all the current institutions who are set up to exploit, rather than support us.
Let’s hack and fork business models and community patters as freely as we do code.
Let’s work on problems that matter.
Let’s work at a scale that makes an impact.
We are all JavaScript People.
The future is ours.
Thank you.
❧
Slides to go with the headings.
Hi, welcome to CouchDB Conf.
CouchDB means a lot to me and it makes me very happy that you are all here today.
Who am I
My name is Jan Lehnardt and I am the elected project management committee chair of the Apache CouchDB project. If you don’t know what this means, don’t worry, it means I sign up to deal with politics and paperwork voluntarily.
I have been with CouchDB since 2006. My first contribution was the initial UNIX build system to CouchDB. I stuck around ever since.
My main job back then was PHP/MySQL consulting and Open Source work as my own 20% project. In 2007, I started giving talks about CouchDB at user groups and conferences and quickly became addicted. People called me the CouchDB Chief Evangelist, although I don’t really like the title. From 2008 I started getting contracting jobs specifically for CouchDB and things blew up quickly that it became clear soon, that an organisation of some sort was needed to handle this. I eventually joined forces with CouchDB’s original inventor and J Chris Anderson to form the company Couch.io. We initially weren’t keen on taking venture capital, but when the whole NoSQL thing blew up, it was very hard to say no and on January 1st 2010 we were in business.
Couch.io turned into CouchOne and was eventually merged with Membase into Couchbase. Unfortunately, at this point, there isn’t much Couch-y about Couchbase aside from some underlying technology, so the name can be confusing.
I parted ways with Couchbase a week ago in order to concentrate and focus more on Apache CouchDB and related technologies.
CouchDB isn’t Dead
In late 2011 two major supporters of CouchDB withdrew their support: Canonical’s UbuntuOne service, on paper a poster-child use-case for CouchDB and Saucelab’s Selenium platform publicly made clear that they were moving to other technology. It wasn’t a big deal if you looked closely, the one project didn’t have enough resources to integrate with CouchDB the right way and the other diverged so far from the original system design, that CouchDB was no longer a good fit. We were and we remain good friends with the respective developers, so we didn’t feel like pointing that out specifically. The result though was that people who didn’t look closely saw that CouchDB had popular failures where it hadn’t. This wasn’t all bad, but set the stage for another incident a few weeks later.
CouchDB’s original inventor publicly announced that he’d move on from Apache CouchDB to Couchbase fully. That new technology would only go into Couchbase. If you are in the know, this wasn’t a big deal again, he hadn’t contributed to CouchDB in two years, Couchbase was a different thing and he wanted to rally support for that. The casual reader though took away one lesson: “CouchDB is dead”.
With the added confusion of Couchbase’s name, and continuing their CouchConf conferences, things looks dire.
CouchDB 2012
With this in the wild, the active CouchDB committers got together and put out an excellent 1.2.0 release that was accompanied by a new, modern website design. We thought instead of writing counter-statements and start unnecessary he-said-she-said discussions, we’d rather concentrate on shipping good software. 1.2.0 was well received and the whole thing lead the team to come together as a whole in Boston and two weeks later in a smaller group in Dublin in April 2012.
We came up with a long list of of features that we wanted to get into CouchDB. Some work happened over the summer, but I personally took a bit of a break to avoid burn-out from CouchDB. In fall, things started moving faster again when more community members started pushing things along. New contributors came and we finally came up with a way to go forward.
We decided to not be insane. The definition of insanity is trying the same thing over and over again and expecting different results. While it wasn’t all bad in CouchDB land we could do better and to do better we had to change a few things.
CouchDB Reboot
We determined that CouchDB needs a fresh mission statement. I signed up to come up with a few drafts, but nothing happened yet, so this one is still out there cough.
We decided to release more often. With the upcoming 1.3.0 release we will switch to a quarterly release cycle. A new minor version will come out approximately every 90 days, even if it is just a few bug fixes that a small number of people direly need.
CouchDB 1.3.0 will ship with top-notch API documentation right inside of Futon, the built in admin interface.
We will start to set up teams where anyone can sign up to work on a specific thing: docs, our JavaScript components, the Erlang core, the admin interface (built in HTML+JS). We want to make sure anyone who has the right skills can contribute in their area of expertise and not be scared away by the Erlang.
We put some emphasis on QA, automated testing, building binaries and packages for releases as well as in-development versions, so people can try new features before they come out more easily and as a result report issues early.
A few of the core team will put some focus on encouraging contributions rather than coding themselves. We hope to get more people on board with CouchDB development.
We also started doing roughly quarterly in-person meetings (at least as smaller groups) and weekly status meetings on IRC to give everything a little more focus and transparency.
The next few slides show a long list a few features that we’ll be working on. If you think anything is missing, let us know!
The more prominent things are: Merging rcouch, BigCouch, the new Futon, the plugin system and v8/node integration.
rcouch is a cutting edge distribution of CouchDB with many experimental features. A lot of that work is useful for Apache CouchDB and we plan to fold those back into the project.
BigCouch is a industry-strength clustering solution for CouchDB to allow seamless scaling and storing of lots of data. BigCouch is going to be merged into mainline CouchDB as well.
The admin interface Futon is getting a complete refresh with modern web development technologies.
There are many features hidden in some developer’s git repository because, while useful, it wasn’t generally applicable to CouchDB. With the plugin system, we hope that we can fuel a repository of plugins to CouchDB that are easily installed (think browser extensions, right from Futon). For example, you could install GeoCouch with the click of a button.
Finally, we are currently discussing the move from SpiderMonkey and to V8 or even Node. The jury is still out on which one it is going to be, but we hope that this is going to open up a lot more opportunities for CouchDB in terms of features and new contributors.
CouchDB would be nothing without you, the community. People who know little about CouchDB might like it or not, but people who really get to know CouchDB are extremely passionate about it.
CouchDB’s core idea, the promise that data can be anywhere it is needed, to make applications easier, more approachable and effective for people in modern computing environments, that idea is a big one. It’s the one that brings this community together.
Thanks again for coming, you are all awesome. CouchDB means a lot to me and I get a little teary seeing you all here.
If you like any of the above todos, or have some of your own, please help out, get in touch about how.
Friends of CouchDB
The CouchDB ecosystem is full of exciting projects that support CouchDB in one way or another.
PouchDB
PouchDB is the newest project on the scene. PouchDB is a pure JavaScript implementation of CouchDB targeted at the browser.
Let me say that again: CouchDB in JavaScript, for the browser.
PouchDB is the oldest idea, but it took the longest to realise because browsers weren’t ready for it. Now is the time though that we can build and ship a CouchDB compatible data store and replication engine that lives entirely in your browser. If you want to build web apps that can seamlessly synchronise data between a laptop, a phone and a server and not treat one as a “master” and the other as “slaves”, PouchDB is your solution.
TouchDB
TouchDB-iOS and -Android are Objective-C and Java implementations of the same idea, but for mobile phone platforms. They natively integrate into your iOS and Android applications and allow synchronisation between themselves, multiple devices, CouchDB’s on the server and even PouchDB in a browser. Again, a milestone in fulfilling the CouchDB vision: data where it is needed, not on some server, far away over a slow and unreliable or even unavailable connection.
Node.js
This might not be too obvious to people who don’t do Node, but CouchDB is big, if not essential here, too. As any programming language & platform, Node.js comes with a package manager called NPM. As far as package managers go (and I’ve used them all except I think ant) NPM is the one that sucks least, or rather, it is pretty good.
If you are invested in Node.js programming NPM isn’t just a tool you can use, it is essential to the development and deployment workflow of your applications. It is that good.
And here is the kicker: NPM’s (de)-central registry is build on CouchDB. NPM is effectively a CouchApp. The Node elders love CouchDB.
I suggest, and plan to turn this into an opportunity for CouchDB. Say, for example, we need benchmarking tools for CouchDB. The Node folks are great at that. If we were to go and say, “hey, do you want to help make NPM faster? Help us build benchmarking tools, so we can speed up CouchDB for you.” — And that’s just one idea, the potential collaboration is immense. Add to that that we maybe get native Node support inside CouchDB, we can do all sorts of crazy shit like writing core add-ons to CouchDB in JavaScript.
Finally, I’d like to mention Hoodie, a project that Gregor, Alex, I and a few friends have been working on on and of over the past year. It is frontend web app framework that uses Node and CouchDB. We are happy to show that to you on the weekend.
The Node Firm
I am going to mention Node.js one more time. Some of you might know The Node Firm, but for those who don’t, think of it as a company made up of the core contributors to Node.js that come together as a collective of professionals to offer services around Node.js that are complementary to the open source project. Things like consulting, technical vetting, training, things that an open source project rarely can do itself.
The key part for me to like The Node Firm (I joined recently) is that, and I repeat, it is complementary to the open source project. It doesn’t try to extract any value from the project, but merely satisfies demand for services that the project can provide. Finally, proceeds are going right back into the community, in the form of conference support, swag, stickers, t-shirts, and so on.
I think this is a brilliant set up for an open source company and I hope many will fork this model.
With that as a preamble, I am happy to announce that together with Dave Cottlehuber and the preliminary support of a few community members, we are launching The Couch Firm, modelled after The Node Firm.
It is early days for us, but expect the same setup, a business complementary to the open source project.
Conclusion
Above all, Open Source is about transparency and community, and I hope you feel you have an accurate picture of where we’re at right now. We had a hard year, lost our traction, and we still came out on top.
With this, I’ll leave the stage for a day of exciting speakers with all sorts of crazy cool topics.
Thank you all for being here!
❧
On January 25-27th 2013 we ran CouchDB Conf Berlin. A one-day conference and two-day CouchHack event dedicated to the Apache CouchDB community and technology.
Why
CouchDB Conf was born out of the desire to run an Apache CouchDB Technology conference. Couchbase’s CouchConf used to be that, but has moved away, while sadly keeping the name.
The CouchDB community is a busy bunch and any excuse to get together is taken up with enthusiasm. CouchDB Conf was sold out with ~70 participants in a wintery Berlin.
Conferences in general are great for various reasons:
-
the core developers get some face time to have a good time, but also to get neck deep into discussions and hacking that require in-person communication. Lots of future plans can be hashed out quickly as well. We made good use of that.
-
the user community gets to hang out with the core developers, learn about how they work and most importantly, get to ask all the fun, hard, silly and important questions they never dared ask before. We also made good use of that.
-
Everybody gets to show of what they are working on and get everybody else excited about it. We made extensive use of that. Exictement was rampant.
Eventify captured a few good impressions.
Talks
The slides for the talks are all linked up on the conference site.
One common thread through all presentations that CouchDB’s replication feature is most the popular thing CouchDB has to offer. HTTP and JSON are nice and simple, but replication is the one thing all would go out of their way to point out that it is the thing that makes CouchDB most attractive.
CouchDB’s vision early on was to be able to run on small clients, big servers, with lots of data and very little data, mobile phones and really any device that one can carry around, and crazily enough also in the browser. For the longest time though this was a bit of a pipe dream, as the Erlang CouchDB implementation wasn’t really suited to run on low-power devices and definitely not in a browser.
This now changed. BigCouch makes the start, as it handles CouchDB’s BigData and clustering aspirations. It has been around for a while, but is now finally being integrated into Apache CouchDB proper.
Hot on the heels is TouchDB, which comes in two flavours: iOS and Android, or Objective-C and Java respectively. Both are native reimplementations of CouchDB for mobile devices. TouchDB-iOS is production ready (a few apps are already live), the Android version is a little behind and both are open for contributions.
The newest player on the scene is PouchDB, a pure JavaScript implementation of CouchDB targeted at modern desktop and mobile browsers. Albeit being the newest member of the CouchDB family, it has the highest activity and was recently selected to act as a sample project in the Stanford Computer Science course. It is on the verge of being production ready.
All of this finally brings CouchDB’s vision together. Lots of data can live on BigCouch clusters, regular data can live on regular servers, user-data can live on mobile handsets, tablets and even in the browser and data can float freely between all of them. Application developers no longer have to worry about how to get a user’s data in front of them, handle concurrent updates, sync with offline devices and online servers. Even peer-to-peer sync is possible.
Towards the end of the day, when the whole vision inadvertently came together, the energy levels were very high. And nothing fuels developers better than seeing users getting excited.
Shit is getting real, as the kids say.
CouchHack
The following weekend was dedicated to hands on hacking, some more cool show & tell type talks and a Skype-powered video talk from Bangkok.
Among the highlights are:
- CouchDB/rcouch running on the RaspberryPi with Zeroconf auto-networking and everything.
- A preliminary port to BlackBerry 10.
- Wallaby, a native QT-based app framework that uses CouchDB for data storage & sync.
- Hoodie, a pet project of ours.
- CouchDB Operations.
- Hands on hacking with PouchDB.
- Hands on hacking with TouchDB.
- Hands on hacking with PouchDB and TouchDB.
- Clearing out 30+ issues in preparation for the 1.3.0 release.
- Adding GeoCouch functionality to PouchDB.
Use the Time Slider feature to see the topics for all days.
Thanks
As the organiser, I couldn’t be more happy about how CouchDB Conf has turned out. Of course, I couldn’t have it all done by myself, so I’d like to thank the following people and companies:
The Speakers
Katrin Apel, Dale Harvey, David Zuelke, Martin Hilbig, Nuno Job, Volker Mische, Oliver Kurowski, Jason Smith, Robert Newson, Joan Touzet, Stephan Strohmeier, Till Klampaeckel and Randall Leeds.
The Helpers
Gregor Martynus, Dave Cottlehuber and Jan Friedensreich.
The Companies
Co.Up for hosting us, Tito.io for the flawless ticketing, GitHub & Cloudant for the drinks, Nodejitsu, FreshX, Mozilla, EasyBib and IrisCouch for sending people or donating company time.
Next
There are preliminary plans to set up a CouchDB Conf in Seattle later this year. We’ll keep you posted.
Members of the CouchDB Community will be attending the following conferences:
You are welcome to join us and nerd out about CouchDB :)
Thanks!
Jan
❧
❧