In my role as a coach for other presenters I just ran into a common issue. A talented person giving their first talk and hating it. The reason: everything went wrong with stage technology. This lead to a loss of confidence and putting the blame on oneself. The irony was that the talk wasn’t in a place with tech issues, but in San Francisco. The wireless was not at all up to scratch. The presenter had planned for that: using a ServiceWorker powered HTML slide deck – state of the art what we consider bullet proof and highly portable. But there was no way to make the computer display on the big projector as there was no HDMI connection. That’s why they had to use someone else’s computer. None of the demos worked. Lacking experience, the presenter had a hard time describing what people should see. Furthermore, you don’t want to be the person to promise things without proving them.

There is no point in throwing blame. Of course, as a prepared speaker you should be able to do fine without your demos. But often we put a lot of effort into these demos and they excited us to write the talk in the first place. Of course the conference organiser should have all connectors and know about display issues. And of course the wireless should work in the middle of tech bubble central. Often conference organisers don’t control connectivity. They have to rely on venue installations and their promises. Shit happens. Time to learn from that. What can we as presenters expect and how can we prepare ourselves for Gremlins in the machinery?

I collected the following tips and ideas presenting at about 80 conferences in the last 4 years. In about 60 venues spread across the globe. So, if your experience was much better – lucky you. Fact is, that things go wrong all the time and often there is nothing you can do.

Let’s go back a bit. Van Halen required in their band contract to have a bowl of M&Ms in their room with all the brown ones removed. This has become a running joke when the topic is about entitlement and added to the “ridiculously needy rockstar” myth. The interesting part about this is that this rule served a purpose. Van Halen required a intrinsic stage setup to achieve their unique sound. Their rider describes the necessary stage tech in detail. The M&M rule at the end of the rider is a simple way of knowing if the concert organisers read and understood it. When there was no bowl in the room or it had brown M&Ms in it something was wrong. This needed fixing to avoid a disastrous concert.

The main difference between this story and presenting at conferences is that we’re not rockstars. We can’t demand the things they do, and – more importantly – we aren’t as organised as an industry. In far too many cases there is a massive miscommunication between conference organisers and presenters as to what is needed to give your talk. This is when bad things happen.

The perfect scenario: demand your lack of brown M&Ms

If your talk depends on a lot of things going right, be adamant about this in your talk proposal. Add reminders to your communication with the conference organisers. Outline in very easy to understand words what you need, as in: 

• I will present from my own computer, a $machine, which means I will need a connector of type $dongle and a resolution of at least $pixelsbypixels. 
• My slides are in the format of $aspectratio (4:3 or 16:9, you don’t want black bars)
• I will need audio available as my talk contains videos with audio and audio examples. Please provide the necessary cables.

Be there on time to set up and demand a dry run the day before. This could give you insight into issues and you can get them fixed before you go on stage.

Remember that in some cases, the conference organisers are not in charge. Make sure to get to know the venue AV and connectivity people and talk to them. Also make sure to find out which room you’ll be in and who will be there before you so you have time to set up. Connectivity and AV equipment can vary from room to room even in the same conference.

All this sounds like a lot of work – and it is. You made yourself dependent on your technology – it is up to you to ensure things go smooth. We don’t have roadies and riders for that.

Extra measures: know your issues and bring your own materials

As everything can go wrong, it is good to know the quirks and issues of your own hardware. It is prudent to ensure you bring everything you need:

• Power cables and local outlet connectors – especially for the MacBook Air. Older versions have the issue that on battery it uses a less powerful video chip than when connected to a main. This could make the difference of your screen showing up on a long VGA cable or not. You also don’t want your computer go to sleep on stage.
• Network dongle – wireless is likely to fail when used by a lot of people. That’s why conferences offer a wired connection on stage. This one is pretty useless unless you also bring your wired dongle. If you only have one USB port, also bring a splitter/hub.
• Remote control – this is not a need, but they are useful and not every conference has one. You also get a free laser pointer which comes in handy if you encounter kittens.
• Display dongle – this is the big one. Make sure that you have a connector from your computer to all kind of display cables. Smashing conference gave out some great ones as speaker gifts:

Bulletproofing measures: have a fallback

The main thing I learned on my travels is to ensure your talk materials are available.That’s why you need a format that means whatever goes wrong, there is still a way out:

• Be prepared to provide your slides in different aspect ratios — quite often I had to change my slights and both Keynote and Powerpoint make a pig’s ear out of this.
• Don’t use the full screen in your slides — almost every time I presented the projector cut off some part of the screen. Add a large margin around your content and all will be visible.
• Have high contrast and large fonts in your slides — lighting is often a mess at conferences and people need to be able to read even in the back.
• Demos and examples have to work offline and have no online dependencies – if you’re showing off an API, keep cached local results.
• Create screencasts of your demos – it allows you to talk over them without running into connection issues. You won’t have slow loading pauses. You don’t have to type things in / authenticate from a wonky wireless. Make sure to have the videos embedded in your materials but as video files. A few times powerpoint/keynote failed to show the videos, so I used VLC to save the day.
• Put all your materials online – this allows you to reach them in case your hardware goes down. And it means people can get to them later.
• Keep your materials on a USB stick – if you need to use another computer it is a simple way to shift them. Make sure that dependencies you rely on are also on this stick.

Special circumstances: help the conference organisers

Often I found that as a presenter, you have to follow some rules you don’t like when it comes to stage technology. It is up to you to stand your ground and demand what you want to have. Or you could swallow your pride and reach audiences you might not reach otherwise. Here are a few things I encountered that are against my ideas of what I want to do as presenter but made sense:

• Universities needed the slides to be in Powerpoint. They also needed them running from a fixed computer in the lecture hall. The reason was that the machine was Windows XP. The AV was part of the room and the machine recorded and archived all talks.
• International conferences offer live translation. It is much easier for translators to have your slides upfront in a printed format. It allows them to annotate the talk and ensure that they keep technical terms English.
• The last point becomes even more important when there is live sign translation at the event. Signing works by translating the meaning of whole sentences. Not letter by letter or word by word. Having the material upfront makes this much easier.
• Some places don’t allow unverified hardware to access the network or connect to a projector. I’ve had government sites that were on total lockdown.

Leveling up: know your story, have your resources

Do yourself a favour and strive to liberate yourself from your demos and slides as a presenter. You will be able to do much more exciting work when your presentation is your wallpaper. You are the show and the source of information. It is exciting to see technical things going right. Many are hard to repeat for the audience and they are more of a show than an educational moment.

Instead, point to materials, show what they do and how people can use them. Tell the story of the materials and how they can make the life of your audience better. If that is what you convey, even a power cut won’t make a difference. You present and educate, you don’t run a demo.

Lately I’ve been quite immersed in the world of Microsoft to find my way around the new job, and whilst doing so I discovered a few things you might have missed. Especially in the field of accessibility there is some splendid stuff happening.

During the key note of //build last week in San Francisco there were quite a few mind-blowing demos. The video of they keynote is available here (even for download).

For me, it got very interesting 2 hours and five minutes in when Cornelia Carapcea, Senior PM of the Cognitive APIs group shows off some interesting tools:

• A “What’s in this image” demo using the Computer Vision API
• The Caption Bot, which automatically detects content in images and proposes alternative text
• The Custom Recognition Intelligent Service (CRIS), which allows you to train a system to get better results when converting audio to text.

The results of CRIS are impressive. For example, Cornelia showed off how a set of audio files with interviews with children became much more usable. On the right in this screenshot you see the traditional results of speech to text APIs and on the right what CRIS was able to extract after being trained up:

The biggest shock for me was to see my old friend Saqib Shaikh appear on stage showing off his Seeing AI demo app. It pretty much feels like accessibility sci-fi becoming reality:

The Microsoft Cognitive Services: Give Your Apps a Human Side breakout session at build had some more interesting demos:

• Tele2 using the translation API to do live translation of phone calls into other languages. You hear the message in the original language, a beep and then the translation. (34:50 onwards)
• ProDeaf doing the same to translate live audio into sign language across languages. (40:00 onwards)

In Andy Sterland’s F12 Developer Tools talk of Edge Web Summit he covered some very important new accessibility features of developer tools:

• F12 tools for Edge now have not only an accessibility tab in the DOM viewer, but also a live updating Accessibility Tree viewer
• Narrator for Windows will have a developer mode. You can turn this on using “Narrator + Caps Lock + Shift + F12” and it will only read out the app that you chose rather than the whole operating system, including your editor and the things you type in. To avoid the mistake of looking at the screen whilst using a screen reader, it also automatically hides the screen except for the currently read out part.

My direct colleage and man of awesome Aaron Gustafson deep dived more into the subject of accessibility and covered a large part of the Inclusive Design Toolkit.

All in all, there is a lot of great stuff happening in the world of accessibility at Microsoft. I had a very easy time researching my talk next week at Funka.

Die letzten drei Tage war ich in Darmstadt auf der BASTA Konferenz, um mich mit Leuten über den Tod von IE, dem Selbstverständnis eines immergrünen Browsers in Windows, des Open Source releases von Chakra und Machine Learning mit Project Oxford zu unterhalten. Neben eines Interviews mit Entwickler TV und kiloweise tollem Essens habe ich dann auch die Keynote gehalten.

Die Slides zum runterladen gibt es auf Slideshare.

Den Screencast gibt es wie immer auf YouTube.

In den etwa 20 minuten habe ich die Basta Seite auseinandergenommen und einige Mythen der Webentwicklung zerlegt. Ausserdem gehts um Rolltreppen und japanische Toiletten.

I just had a journalist ask me to answer a few questions about developer evangelism and I did so on the train ride. Here are the un-edited answers for your perusal.

In your context, what’s a developer evangelist?

As defined quite some time ago in my handbook (http://developer-evangelism.com/):

“A developer evangelist is a spokesperson, mediator and translator between a company and both its technical staff and outside developers.”

This means first and foremost that you are a technical person who is focused on making your products understandable and maintainable.

This includes writing easy to understand code examples, document and help the engineering staff in your company find its voice and get out of the mindset of building things mostly for themselves.
It also means communicating technical needs and requirements to the non-technical staff and in many cases prevent marketing from over-promising or being too focused on your own products.
As a developer evangelist your job is to have the finger on the pulse of the market. This means you need to know about the competition and general trends as much as what your company can offer. Meshing the two is where you shine.

How did you get to become one?

I ran into the classic wall we have in IT: I’ve been a developer for a long time and advanced in my career to lead developer, department lead and architect. In order to advance further, the only path would have been management and discarding development. This is a big issue we have in our market: we seemingly value technical talent above all but we have no career goals to advance to beyond a certain level. Sooner or later you’d have to become something else. In my case, I used to be a radio journalist before being a developer, so I put the skillsets together and proposed the role of developer evangelist to my company. And that’s how it happened.

What are some of your typical day-to-day duties?

• Helping product teams write and document good code examples
• Find, filter, collate and re-distribute relevant news
• Answer pull requests, triage issues and find new code to re-use and analyse
• Help phrasing technical responses to problems with our products
• Keep in contact with influencers and ensure that their requests get answered
• Coach and mentor colleagues to become better communicators
• Prepare articles, presentations and demos
• Conference and travel planning

How often do you code?

As often as I can. Developer Evangelism is a mixture of development and communication. If you don’t build the things you talk about it is very obvious to your audience. You need to be trusted by your technical colleagues to be a good communicator on their behalf, and you can’t be that when all you do is powerpoints and attend meetings. At the same time, you also need to know when not to code and let others shine, giving them your communication skills to get people who don’t understand the technical value of their work to appreciate them more.

What’s the primary benefit enterprises hope to gain by employing developer evangelists?

The main benefit is developer retention and acquisition. Especially in the enterprise it is hard to attract new talent in today’s competitive environment. By showing that you care about your products and that you are committed to giving your technical staff a voice you give prospective hires a future goal that not many companies have for them. Traditional marketing tends to not work well with technical audiences. We have been promised too much too often. People are trusting the voice of people they can relate to. And in the case of a technical audience that is a developer evangelist or advocate (as other companies tend to favour to call it). A secondary benefit is that people start talking about your product on your behalf if they heard about it from someone they trust.

What significant challenges have you met in the course of your developer evangelism?

There is still quite some misunderstanding of the role. Developers keep asking you how much you code, assuming you betrayed the cause and run the danger of becoming yet another marketing shill. Non-technical colleages and management have a hard time measuring your value and expect things to happen very fast. Marketing departments have been very good over the years showing impressive numbers. For a developer evangelist this is tougher as developers hate being measured and don’t want to fill out surveys. The impact of your work is sometimes only obvious weeks or months later. That is an investment that is hard to explain at times. The other big challenge is that companies tend to think of developer evangelism as a new way of marketing and people who used to do that can easily transition into that role by opening a GitHub account. They can’t. It is a technical role and your “street cred” in the developer world is something you need to have earned before you can transition. The same way you keep getting compared to developers and measured by comparing how much code you’ve written. A large part of your job after a while is collecting feedback and measuring the success of your evangelism in terms of technical outcome. You need to show numbers and it is tough to get them as there are only 24 hours in a day.
Another massive issue is that companies expect you to be a massive fan of whatever they do when you are an evangelist there. This is one part, but it is also very important that you are the biggest constructive critic. Your job isn’t to promote a product right or wrong, your job is to challenge your company to build things people want and you can get people excited about without dazzling them.

What significant rewards have you achieved in the course of your developer evangelism?

The biggest win for me is the connections you form and to see people around you grow because you promote them and help them communicate better. One very tangible reward is that you meet exciting people you want to work with and then get a chance to get them hired (which also means a hiring bonus for you).
One main difference I found when transitioning was that when you get the outside excited your own company tends to listen to your input more. As developers we think our code speaks for itself, but seeing that we always get asked to build things we don’t want to should show us that by becoming better communicators we could lead happier lives with more interesting things to create.

What personality traits do you see as being important to being a successful developer evangelist?

You need to be a good communicator. You need to not be arrogant and sure that you and only you can build great things but instead know how to inspire people to work with you and let them take the credit. You need to have a lot of patience and a thick skin. You will get a lot of attacks and you will have to work with misunderstandings and prejudices a lot of times. And you need to be flexible. Things will not always go the way you want to, and you simply can not be publicly grumpy about this. Above all, it is important to be honest and kind. You can’t get away with lies and whilst bad-mouthing the competition will get you immediate results it will tarnish your reputation quickly and burn bridges.

What advice would you give to people who would like to become a developer evangelist?

Start by documenting your work and writing about it. Then get up to speed on your presenting skills. You do that by repetition and by not being afraid of failure. We all hate public speaking, and it is important to get past that fear. Mingle, go to meetups and events and analyse talks and articles of others and see what works for you and is easy for you to repeat and reflect upon. Excitement is the most important part of the job. If you’re not interested, you can’t inspire others.

How do you see the position evolving in the future?

Sooner or later we’ll have to make this an official job term across the market and define the skillset and deliveries better than we do now. Right now there is a boom and far too many people jump on the train and call themselves Developer “Somethings” without being technically savvy in that part of the market at all. There will be a lot of evangelism departments closing down in the nearer future as the honeymoon boom of mobile and apps is over right now. From this we can emerge more focused and cleaner.
A natural way to find evangelists in your company is to support your technical staff to transition into the role. Far too many companies right now try to hire from the outside and get frustrated when the new person is not a runaway success. They can’t be. It is all about trust, not about numbers and advertising.

Today I gave two talks at JFokus in Stockholm, Sweden. This is the one about JavaScript and ChakraCore.

Presentation: Making ES6 available to all with ChakraCore
Christian Heilmann, Microsoft

2015 was a year of massive JavaScript innovation and changes. Lots of great features were added to language, but using them was harder than before as not all features are backwards compatible with older browsers. Now browsers caught on and with the open sourcing of ChakraCore you have a JavaScript runtime to embed in your products and reliable have ECMAScript support. Chris Heilmann of Microsoft tells the story of the language and the evolution of the engine and leaves you with a lot of tips and tricks how to benefit from the new language features in a simple way.

I wrote the talk the night before, and thought I structure it the following way:

• Old issues
• The learning process
• The library/framework issue
• The ES6 buffet
• Standards and interop
• Breaking monopolies

Slides

The Slide Deck is available on Slideshare.

Screencast

A screencast of the talk is on YouTube

Resources:

• Learn ES2015 on BabelJS
• ES6 overview in 350 Bullet Points
• Exploring ES6 by Axel Rauschmayer
• Talk: Dependency Hell Just Froze Over by Stephan Bönnemann (JSConfEU 2015)
• Talk: You should use [insert library/framework], it’s the bestestest! by Paul Lewis (Full Frontal 2015)
• Big Rig
• The Cost of Frameworks
• this and arrow functions
• ECMAScript browser support table
• BabelJS Transpiler
• The Cost of Transpiling ES2015 to ES5
• The ES6 Conundrum
• ChakraCore and Time Travel Debugging
• Submitting ChakraCore to the NodeJS mainline
• Open Sourcing Chakra Core
• ChakraCore on GitHub