Developer Relations revelations: travel is hard work

This is part of a series of posts about the life as a DevRel person and how not all is unicorns and roses. You can read the introduction and the other parts of the series here.

So, today, let’s talk about traveling.

Sleeping on a plane

When I worked for the Red Cross with elderly people one thing became pretty obvious to me. People who traveled in their lives were not only more interesting, but also aged much better. They had more energy, showed more excitement about new things and generally felt more alive.

Traveling as a DevRel person isn’t like that. It can easily be the exact opposite.

Coming from a low-end working class family traveling around the world always was a dream for me. Each holiday was cramming the family in a car and driving 14 hours to Italy to go camping. To the same place every year. And yet, I made the best of it. I loved going to highway stops seeing cars and trucks from all kind of countries. I deliberately chose to work on the web as it meant I can connect to people from all over. Getting to know them, finding out our differences and maybe – if I every get really lucky – visit them in real life.

From this point of view my job right now seems a dream come true. It seems that I get paid to travel the world. I have Gold status with one airline affiliate group for three years running. I have Silver and Gold status with a few hotel chains. My travel history is pretty impressive:

My travel statistics, 965369 miles traveled, 1931 hours in the air, 27 countries and 48 destinations

My Android location history
My Android location history See yours here

Here’s the thing though: travel for work is not at all like being on a holiday. It is taxing. It takes a toll on your health, it takes a heavy toll on your relationships and it is very easy to overdo it. You need to be happy with being on your own and being the only person to rely on. You also need to ensure that all your creature comforts get covered. This is often at odds with the budget of conferences or your company’s expense policies.

Faux Jet-Set

There is a strange disconnect in business travel. You are part of the jet set but you almost never have time to enjoy it. On paper it feels great to have travelled to all these cool destinations. In reality all you see is the airport, some means of transport, your hotel room and the event venues. This can be depressing. You constantly have this carrot of world traveler excitement in front of you. To experience it you would need to sacrifice free time. The days before and after an event are crucial for our jobs and it is hard to tack on a few in each direction.

A constant “do I deserve this” feeling

Lonely meals and nondescript rooms are much less fun when you didn’t hang out with people you know. And you don’t want to add yourself to other groups or ask people to dine with you as that would be work. And you need to ensure you have some time off to re-charge. Interestingly enough, the fancier the accommodation is the worse I feel. When I am in a really cool hotel and have no time to use the facilities other than crashing for a few hours I feel weird. I spend other people’s money without reaping the rewards. Trying the hotel out for a holiday later is not as common as they tend to be costly or optimised for business travel.

It is important to be on the road. A two minute face-to-face conversation is often worth weeks of emails, chats or calls. Meeting people where they are can open great opportunities for you and your company. So, here are a few tips that helped me on the way and still make it much easier for me.

Find an airline alliance to collect points and status with.

That means things that don’t sound much but will add a lot to your well-being.

  • You do not have to worry about luggage restrictions.
  • You get priority boarding, which means you can book a cheaper seat and still get on the plane first. You can store your hand luggage above instead of having to keep it at your feet.
  • It is imperative that sooner or later you get lounge access. This turns a layover caused by a missed plane from a nightmare to an opportunity to get some work out of the way. Then you can sleep or relax on the plane.
  • You are also more likely to get upgrades if you have status with an airline. Conferences or your company can book you an economy ticket and yet you travel in comfort.

All hotel loyalty systems are pants

Hotel loyalty systems only give you proper benefits when you book on their web sites or in their apps. With your own, personal credit card. If, like me, you have a corporate card, the most you get is a free bottle of water on check-in (yay?) and late check-outs. There is not much point to be loyal in this case. Something else is much more important when it comes to hotels.

Your hotel matters

Your hotel on a company trip can either be a place to crash at night or your base of operations. I try to make sure I can do the latter. That means the most important part is that it is close to where I need to be. You don’t want to spend a lot of time in transit between hotel and event, carrying a lot of swag and hardware with you. If that means you stay in a cheaper, but closer, hotel, this is a good thing. If it means the conference or your company needs to pay more, so be it. Most trips I do are short which means I will spend most of my time at the event. Having a fancy hotel isn’t useful when you have no time to enjoy it. The most important bits are that the place is clean, has fast connectivity in your room, and is easy to reach.

Stay active – or your health will suffer

If you can, try to find a hotel with a gym – no matter how basic. It is the best thing to fight jetlag and to clear your head. It is also important. When you travel, you sit a lot and you don’t move on a plane. That’s bad for you. You also consume a lot of food and drink on planes and you don’t give your body a challenge to burn it. I found that going to the gym before and after events allowed me to be much more energetic. Look after yourself – nobody else does.

If you’re tired or sick, your work will suffer

Jetlag is a pain and will turn you into a liability. You can not be in a stressful environment when you are not awake and relaxed. You will make mistakes, you will say things you can regret online later and you won’t be able to take in as much as you need. So look after yourself and get sleep when you can. You don’t need to be part of every social activity of an event and should sneak out for a kip whenever you can. Try to get enough time to deal with jetlag and look at what you eat and drink. You can not get sick. And believe me, this is a full-time job. Time differences, over-zealous air conditioning, pressurised aircraft and unknown food all mess with your body. Everyone I know working in DevRel carries a bag of medication. Acid reflux, indigestion, unwanted bowel movements and sore throats and runny noses. All commonplace enough to prepare for them.

Adding to that is that being on the road and constantly having to adapt does things to you. In Pattern Recognition William Gibson describes jetlag as “your soul trying to catch up with you” and that is pretty accurate. Being more emotional without planning to is common on planes. There is a lot of research into Why people cry on planes and I also find myself doing that.

Take care of yourself, please.

Point-to-point annoyances

One thing I am adamant about is that a conference or office makes it as easy as possible for me to get from the airport to where I need to go. I don’t want to deal with pushy unlicensed cabbies. It is also not fun to try to use public transport in a place you don’t know after 30 hours in the air. This may sound whiny and “first world problem”-ish but any minute wasted on the road isn’t doing you any favours. At least demand a good explanation what to do to get there from the people who invited you.

Expenses sound fun, but aren’t

Living on expenses sounds great, right? It is, to a degree, and it would be much harder – and silly – to spend your own money to do your job. But it also means that you need to be diligent about keeping receipts, and note down who you ate with, what and when. You often also have a company card unknown or unsafe to use in a certain place. Then you need to get money out. And you need to explain your company why you didn’t pay by card, suffering twice from the lack of support. It is important to do your expenses on the spot after your trip. Otherwise you end up delayed and get fined. It has become much easier to file expenses digitally now. I remember typing in all receipts, staple them to a piece of paper and mailing them to a different office. Yet, often you wait for weeks for things to get sorted out even now.

Summary: DevRel travel is lost time

When you travel as a DevRel, travel is not a gift any longer. It is a necessary part of your job. Where it is OK to rough it for a holiday, you shouldn’t sell yourself short when it comes to travel for work. It adds to the stress of your job. It takes up a lot of time you could be doing things to diminish the workload you already have. Whilst you can work in a lounge and on a plane I find it not that fruitful. Often I am tired, or euphoric about a certain topic and write a lot of things that sound lucid but are a write-off later on. One exception is going through emails on a plane. Being offline is a great opportunity to take time answering them without distractions. Traveling as a Developer Relations person is a lot of time a matter of good negotiation. Don’t try to be nice by allowing people to put you on a cheap flight and the wrong hotel. You don’t do them any favours as they would get a grumpy, non-effective you rather than the person they invited.

View full post on Christian Heilmann

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Coding after work Podcast featured me talking about PWAs, Open Source and AI

Back in March, the coding after work podcast interviewed me at the Techdays in Finland.

Today they released the podcast

In about 45 minutes I cover Progressive Web Apps, Microsoft and Open Source and the rise of AI as a technology for us to care about. Hope you enjoy it as much as I did recording it. Thank you to Jimmy and Jessica Engstrom for having me!

View full post on Christian Heilmann

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Panel discussion at “We are Developers”: The Potentials and Pitfalls of Machine Learning

Back in March I was at We are Developers in Vienna, Austria, gave a two hour workshop on using AI on the web, a talk about code not being the answer to everything and MCed on the main stage on the third day. Another fun thing to do was this panel discussion on the Pitfalls of Machine Learning talking about the ethics and the false definitions of AI we have to battle.

I want to thank all people involved:

Moderator:
Jan Mendling ( @janmendling ), Full Professor at Vienna University of Economics and Business

Panelists:
Charlotte Han ( @sunsiren ) , Deep Learning Marketing Manager at NVIDIA
Tuomas Syrjänen ( @TuomasSyrjanen ), CEO of Futurice
Christian Heilmann, Sr. Program Manager at Microsoft
Rainer Steffl, CIO at Mondi Group

If you want to hear more about this topic and learn how to deal with it, I have a Skillshare course out there :

Chris Heilmann giving his course

“Introduction to Machine Learning: Using Artificial Intelligence” is about an hour of materials to get you familiar with the topic of AI.

View full post on Christian Heilmann

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Different views on view-source

View source

Over on Jonathan Snook’s blog we have a pretty good debate about a controversial tweet by Tom Dale:

In essence, Jonathan points out that whilst web development has become much more complex, that isn’t a reason to disregard a human readable source:

The increasing complexity of tools doesn’t negate the need for those earlier, simpler tools, though.

In other words, horses for courses. A simple web site doesn’t need complex tools and benefits from view-source. Other, more complex web products are not as interesting to look at as a simple HTML display.

Tom also points out that he doesn’t mean that you shouldn’t be able to peek under the hood of a site, but that as simple view-source isn’t the correct tool.

And you know what? I tend to agree. There is no doubt that view-source was what made the web great. It drove business owners crazy that all their code was readily visible and copy-able in the browser. For developers it was great, though. Almost all learned by looking at what other people do. And by copying and pasting. And this is where it breaks apart.

I want to emphasise this: it used to be great to hit cmd+u and look at a web site in “text mode”. It was even better when the “view-source:” pseudo protocol became a thing. Browsers added colour coding and later on Firefox even highlighted syntax errors in your markup as bold and red.

For a simple web site with everything in one document or a few linked scripts and stylesheets, that was enough.

I don’t think it is any longer though. Even navigating simple source code of a web site is much more fun in developer tools rather than a huge text block. We can right-click on an element these days and go directly to it. We see how the cascade works when looking at its CSS and we even can see attached events and hover states.

Sure, developer tools are harder to learn than looking at a document, but you also learn so much more from them. The beauty of view-source was that it came for free with a browser. This made it a tool of choice for anyone becoming a web developer. There was no need to download and learn an IDE – your development environment was the consumption environment.

Well, that’s exactly what developer tools are these days. They are free, they come with the browser, and they are not impossible to understand. If anything, I like the fact that they give you more insights into what the code does rather than what it is.

The big proponents of view-source tout its usefulness and simplicity. But we can also start thinking about the problems it has:

  • Except for a few purist web sites out there, what you see in your current device isn’t the code of the web site. We shouldn’t ship the same code down the wire for a low-end mobile device than for a retina screen, fast connectivity device. View source is thus giving us a false impression.
  • Code sent to the web is often minimised and bundled. Developer tools give you options to pretty-print those and thus make them much more understandable.
  • Of course it is great that there is no barrier to entry if you want to know how something works. But the forgiving nature of HTML and CSS can also lead to problems. When we released Edge, we found that thousands of web sites defined a text encoding of utf8 instead of utf-8. We needed to fix this in the browser. Clearly people copied and pasted without thinking or validating. And that’s where unexplained code like in a view-source environment fails.

A lot of the fight for view-source stems from a nostalgic view of the internet and how people build for it. Our excitement of learning the web this way is still lingering and we don’t want the next generation to miss out.

But maybe it is time to move on and understand that by sticking to old methods we deprive new developers. When we started, view-source was all we had and resources about what these things mean were scarce. Even worse, they were tinted with corporate needs, rather than following a standard. You learned the Microsoft web from Microsoft, the Netscape web from Netscape and standards when you had the time or listened to those Opera freaks.

I wrote about this back in 2011 in my Lynx would not be impressed – on semantics and HTML post. And now, seven years later, I still think it should be up to the current generation of developers to choose what makes most sense for them. Our nostalgia might actually be hurting the cause.

Snook’s right: we have no right to dismiss or actively block view-source as a means to access code and learn from it. But I don’t think that in today’s development world this is enough and it makes so much more sense to delve deeper into the tool stack we have.

Just consider the amazing tools we have at our disposal for new developers to learn about web development rather than looking at other people’s code in the browser:

  • The MDN Web Docs are an editable resource of everything web, maintained by all the browser makers and with help from many of the large web companies
  • Can I Use gives you detailed information about what works in what browser, links to the standards and explains implementation quirks
  • GitHub is the home of the source-code of many web projects with a whole history of commit messages and explanations how the code works and where and why people added hacks you shouldn’t copy
  • JSBin , Codepen, Glitch and many other interactive development environments help you get started coding things without the pain of setting up all your preprocessors. Something that proponents of a simpler web always bring up as a huge barrier to entry to the web.
  • Browser developer tools aren’t just “look at code” any more. They are fully fledged development environments that give you amazing insight into what’s going on and how things work. They even audit your code and tell you where things go wrong.

All in all I love view source and what it has done to the web. But I also think that in order to build great products these days we should find ways for newcomers to learn about becoming a developer. Not someone who copies and pastes. Learning about code editors, learning about version control, and learning where and how to ask for help are much more important skills.

I believe deeply that free, open source tooling and systems like GitHub and the abovementioned editors are a much better way to teach people to get started with the web than view-source is in 2018. We already live in a more complex world, and we have tools to make that easier.

This is the main topic of my Skillshare class about JavaScript and how to deal with the changes it went through. It is not only about JavaScript, but about the resources I talked about and what tools to use to make your live easier.

I wrote this to make myself more content and happy in this demanding world, and I hope it helps you, too. Old-school developers will find things to try out and new developers should get a sensible way to enter the JavaScript world. Beyond View-Source but without having to be a Webpack expert before you write your first line of HTML.

View full post on Christian Heilmann

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Developer Relations revelations: workshops are a lot of communication work

This is part of a series of posts about the life as a DevRel person and how not all is unicorns and roses. You can read the introduction and the other parts of the series here.

So, today, let’s talk about giving workshops.

Giving a workshop is very different to presenting and needs a different skillset. Whilst preparing a great talk already takes a lot of time, workshops are a different beast. As a rule of thumb, a good trainer spends eight hours research and preparation for each hour of a workshop.

Workshops are where you can’t fake anything. It is not enough to know the subject matter inside-out. You also need to deal with the attendees. Their requests, different speeds and knowledge levels. You need to lead the group and guide it. And you can’t do that if you don’t feel confident about the material or know much about the group you will teach.

Workshops are much less forgiving than presentations. Only a few people will complain about a bad presenter at a conference. It doesn’t feel like a waste of money to get the conference ticket when there was one dud. Workshops are much more expensive and more personal, that’s why criticism is harsher.

Conference organisers like having workshop days as they are much more profitable. Most of the ticket money of events needs to get into venue, catering, speaker fees and travel. Workshop ticket sales get shared with the teacher with a higher profit margin. Venues are often sponsored by companies. For freelance speakers this is great, as it means more money.

For a DevRel person it is trickier, as you represent a company and you have a different agenda. You need not to get people excited about your knowledge but also about the things you represent. That’s why it is also tougher to sell and fill a workshop as a DevRel person. Your workshops are seen as something that should be free and it is OK to put not as much effort in as an attendee. That doesn’t mean though that they are easier to create and run. At all.

With this increased pressure, it is tough to feel great about your workshops as a DevRel person. Your company will most likely want you to create a generic course. One that shows off the benefits of your products.

This makes sense, as it is an upfront investment of time and money. A lot of the products I worked with benefitted from workshops. You find gaps in the documentation, you see where people get lost, and what technical difficulties come up. All great opportunities to improve your product.

The great thing about generic courses is that they are reusable and measurable. The bad thing about them is that they make for disappointing workshops. You might as well have them online as a course with offline participation instead.

I feel a lot of worry about delivering workshops as they are important. Teaching is a tough job and a bad teacher can utterly mess up a subject. Remember school? All the topics taught by a great teacher are things I still love. All the topics run by a lackluster by-the-book teacher I had to re-learn later in life.

A workshop is much higher stress for you. Your passion, your excitement, your fearlessness to play make the course. It is uncommon to have “bad attendees” as they have a much bigger stake in the workshop than listening to a talk.

Your mistakes, your lack of passion, your sloppiness multiplies with the attendees. That’s why you need to be on your toes for the whole duration of the workshop.

The fun bit about teaching is to find out how people tick and what they need to understand something. It is not about telling them a lot of information and hope things stick. Humans keep information they found out on their own much more than those they had to memorise.

That’s why I want a workshop to be a real workshop. I want to know who will come, what their levels of knowledge are and have them set up their computers in advance. I might as well want X-Ray vision, as the sad fact is that often you need to face the following issues:

  • People who hired you expect you to give a five hour presentation showing a lot of technical demos for people to maybe take part in
  • You have no idea how many people and who will show up to your workshop
  • You face a room full of 50 people – no way you can help them individually or even pair them up to help each other
  • Half the people don’t come back after a break as their boss called them out to do “something important”
  • A large part of the group didn’t bring a computer or didn’t expect having to do anything
  • You end up being helpdesk for faulty computer configurations of the attendees’ computers
  • You end up being offline when most of your materials need a connection or are a download to start with

To run a successful workshop you need to prepare for these. That’s why it is much more important to be clear and demanding in your communication. People who invite you to give a workshop often want a detailed outline of it. Make sure that this also contains detailed information about the needs you have. Setup of the room, the machines of the attendees, detailed timing and attendance demands. It may feel bad to be such a stickler for details, but anything you leave to interpretation will come back to haunt you and cost time. Time you can’t use to help attendees reach the goal of the workshop. Time you need to work with individuals whilst you lose the group.

Don’t be the bad teacher that messed up a subject for you. Workshops have detailed outcomes and you need to measure at the end of them if people learned something. This might be hard to swallow when it didn’t work, but it really helps being excited about your job when it does.

View full post on Christian Heilmann

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Want to speak at an event? Fork and change my cheatsheet for organisers!

Presenting at conferences is a lot of work, but it kind of pales in comparison to organizing conferences. For years, conference organisers thanked me for making their lives easier by having all my presenter information in one place, a “presenter cheatsheet”.

Presenting

Today I spend some time to convert this to a markdown document on GitHub, so you can fork it and change it to your needs.

I covered all the basics:

  • Presenter information, bio and headshots
  • What kind of presentations you want to cover
  • What topics you can cover
  • Show stoppers (when you will not present)
  • Your deliveries
  • Your setup
  • Your expectations
  • Money matters
  • What when things go wrong.

So go to https://github.com/codepo8/presenter-terms and change what you need. Conference organisers will thank you.

View full post on Christian Heilmann

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Is the new world of JavaScript confusing or intimidating? I thought so, and recorded a video course how to feel better

Chris Heilmann smiling behind his laptop as the course is finished

JavaScript used to be easy. Misunderstood, but easy. All you had to do was take a text editor and add some code to an HTML document in a SCRIPT element to enhance it. After a few years of confusion, we standardised the DOM. JavaScript became more predictable. AJAX was the next hype and it wasn’t quite as defined as we’d like it to be. Then we had jQuery because the DOM was too convoluted. Then we got dozens of other libraries and frameworks to make things “easier”. When Node came to be we moved server side with JavaScript. And these days we replaced the DOM with a virtual one. JavaScript has types, classes and convenience methods.

JavaScript is everywhere and it is the hottest topic. This can be confusing and overwhelming for new and old developers. “JavaScript fatigue” is a common term for that and it can make us feel bad about our knowledge. Am I outdated? Am I too slow to keep up? Which one of the dozens of things JavaScript can do is my job? What if I don’t understand them or have no fun doing them?

It is easy to be the grumpy old developer that discards everything new and shiny as unreliable. And it is far too often that we keep talking about the good old days. I wanted to find a way to get excited about what’s happening. I see how happy new, unencumbered developers are playing with hot new tech. I remembered that I was like that.

That’s why I recorded a Skillshare class about JavaScript and how to deal with the changes it went through.

In about an hour of videos you learn what JavaScript is these days, how to deal with the hype and – more importantly – what great advances happened to the language and the ecosystem.

Here’s me explaining what we’ll cover:

The videos are the following. We deliberately kept them short. A huge benefit of this course is to discover your own best way of working whilst watching them. It is a “try things out while you watch” kind of scenario:

  • Introduction (01:46) – introducing you to the course, explaining what we will cover and who it is for.
  • JavaScript today (08:41) – JavaScript isn’t writing a few lines of code to make websites snazzier any longer. It became a huge platform for all kinds of development.
  • Uses for JavaScript (06:25) – a more detailed view on what JavaScript does these days. And how the different uses come with different best practices and tooling.
  • Finding JavaScript Zen (04:15) – how can you stay calm in this new JavaScript world where everything is “amazing”? How can you find out what makes sense to you and what is hype?
  • Evolved Development Environments (10:22) – all you need to write JavaScript is a text editor and all to run it a browser. But that’s also limiting you more than you think.
  • Benefits of Good Editors (12:34) – by using a good editor, people who know JavaScript can become much more effective. New users of JavaScript avoid making mistakes that aren’t helpful to their learning.
  • Version Control (09:15) – using version control means you write understandable code. And it has never been easier to use Git.
  • Debugging to Linting (06:01) – debugging has been the first thing to get right to make JavaScript a success. But why find out why something went wrong when you can avoid making the mistake?
  • Keeping Current in JavaScript (05:11) – JavaScript moves fast and it can be tricky to keep up with that is happening. It can also be a real time-sink to fall for things that sound amazing but have no life-span.
  • Finding the JavaScript Community (03:59) – it is great that you know how to write JavaScript. Becoming part of a community is a lot more rewarding though.
  • Asking for Help (05:47) – gone are the days of writing posts explaining what your coding problem is. By using interactive tools you can give and get help much faster.
  • Final Thoughts (01:11) – thanks for taking the course, how may we help you further?

I wrote this to make myself more content and happy in this demanding world, and I hope it helps you, too. Old-school developers will find things to try out and new developers should get a sensible way to enter the JavaScript world.

View full post on Christian Heilmann

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Developer Relations revelations: presenting at a conference is much more than your talk

This is part of a series of posts about the life as a DevRel person and how not all is unicorns and roses. You can read the introduction and the other parts of the series here.

So, today, let’s talk about giving presentations.

Chris and unicorn in oil
Artistic impression by Anke Mehlert (@larryandanke) what it looks like when I present

As this is a “warts and all” series of posts, I’ll cover the following aspects:

  • Preparing your presentation for various audiences
  • Frustrations and annoyances to prepare for – things that always go wrong
  • Getting ready to be on stage
  • Things to avoid on stage
  • Planning the follow-up
  • The weirdness of making it measurable

Public speaking is tough

Me, presenting

Giving a presentation, or even having to speak in front of a group is the stuff of nightmares for a lot of people. There are so many things that can go wrong and you have nowhere to hide as you are the centre of attention.

It is not easy, and it shouldn’t be. I’ve been presenting at hundreds of meetings and events over the last decade. Every time I go up on stage, I am scared, worried and my tummy imitates the sounds of a dying whale. I also hope against hope that I won’t mess up. This is normal, this is healthy, and it keeps me humble and – hopefully – interesting. Sure, it gets a bit easier, but the voice in your head telling you that it is not normal that people care for what you have to say will never go away. So that’s something to prepare for.

Now, there is a lot of information out there about becoming a great presenter. A lot of it is about the right way to speak, breathe and move. You can even cheat yourself into appearing more confident using Power Poses.

I am coaching people on public speaking. And I found out pretty early that “being a great presenter” is a very personal thing. The techniques needed differ from person to person. There is no silver bullet for you to instantly become a great presenter. It is up to you to find your voice and way of presenting that makes you most confident. Your confidence and excitement is what makes a presentation successful. To a degree this happens in equal measures.

It is great to see presenters admitting not being experts but sharing what got them excited about the topic they cover. Much better than someone faking confidence or repeating tired old truths that can’t be disagreed with.

When you look around on the web for presentation tips there is a lot of thinly veiled advertising for a course, workshop or books. Once you become a known presenter, you don’t even have to look. You get spam mail offering you magical products to give awesome presentations. Others offer you to create materials for your talks and style your slides.

Here’s the thing: none of that is making that much of a difference. Your slides and their form are not that important. They should be wallpaper for your presentation. In the end, you have to carry the message and captivate the audience, not read a deck out to them.

Except, it does make a difference. Not for your talk, but for everyone else involved in it.

Players two, three and four have entered the game

Now, as I already hammered home in the last post, as a DevRel person you are not representing yourself, but also a group or company. That means, that you have a lot more work to prepare a presentation. You need to juggle demands of:

  • Your company and colleagues
  • The conference organisers
  • The audience
  • People who later on will watch the video of the talk
  • Those peering over the social media fence to add their ideas to fragments of information regardless of context

Seperating from your company is tough but needed

Here’s the biggest issue. Technical audiences hate sales pitches. They also hate marketing. They go to a tech event to hear from peers and to listen to people they look up to.

As soon as you represent a company there is already a sense of dread that they’ll find a shill wasting their time. This gets worse the bigger your company is and the older it is. People have a preconception of your company. This could be beneficial “Cool, there is a NASA speaker at that event”. Or it could be a constant struggle for you having to explain that things your company did or other departments do aren’t your fault. It could also be a struggle for you when all you have from your company is marketing messages. Messages that are groan-worthy for technical people but sound great in the press.

Do yourself a favour and be adamant that you own your presentations. You don’t want to get into the stress of presenting a peer-reviewed “reusable slide deck” of your company.

Be proactive in writing and owning your talks. Make sure your company knows what you do and why your talk is a great thing for them. You are on the clock and you are spending their money. That’s why you can’t use presenting only to further your personal brand – something needs to come out of it. That, of course, is tricky to get right, but there are some ways to make it worth while – more on that later.

Helping conference organisers

Conference organisers have a tough job. They don’t only need to wrangle the demands of the audience and locations. They also are responsible for everything that happens on stage. Thus it is understandble that they want to know as much as possible about your talk before it happens. This can get weird.

I often get asked for insipirational, cutting edge talks. In the same sentence I’m asked to deliver the slides months in advance. This is impossible unless you keep the talk very meta. Blue-sky, meta talks don’t help your company or your product. They advocate yourself as a visionary and an important voice in the market, which is good for the company. But tough to explain to the product teams how it affects their work.

In any case, it is a great idea to make the lives of conference organisers easier by having things ready for them. These include:

  • A great title and description of your talk
  • A description of the skill level you expect from the audience
  • An up-to-date bio to add to their materials
  • A few good photos of you
  • Your name, job description, company
  • Ways to connect to you on social media
  • Things you published or resources you maintain

These make it easier for the conference to drum up excitement about your talk and yourself. This can mean the difference between speaking to an empty or full room at the event.

Many events will want slides in advance. I tend to not do that as it limits me and often I get inspiration on the flight there. The only exception is if the event offers translation and especially sign translation. Then I provide slides, extensive notes that I will stick to and a list of special terms and what they mean. It is not fun when you talk about databases and the audience looks confused as the translator talks about kitchen tables.

Making it easier for the audience

I am a firm believer that you should separate yourself from your slides to deliver a great talk. I also realised that this often is wishful thinking.

You will hear a lot of “best practices” about slides and not having much text on them but set the mood instead. That’s true, but there is also a benefit to words on slides. Of course, you shouldn’t read your slides, but having a few keywords to aid your story help. They help you in your presentation flow. They also help an audience that doesn’t speak your language and miss out some of the nuances you add to your talk.

If your slides make at least some sort of sense without your narration you can reach more people. Most conferences will make the slides available. Every single time I present the first question of the audience is if they can get the slides. Most conferences record you and your slides. A sensible deck makes the video recording easier to understand.

When you considered all this, you can go on stage and give the audience what they are looking for. The next thing to tackle is stage technology.

Things that go wrong on stage

Ok, here comes trouble. Stage technology is still our enemy. Expect everything to go wrong.

  • Bring your own power adaptor, remote and connectors but don’t expect there to be a power plug.
  • Don’t expect dongles to work with long cables on stage
  • Don’t expect to be able to use the resolution of your computer
  • Learn about fixing resolution and display issues yourself – often the stage technicians don’t know your OS/device
  • Expect to show a 16:9 presentation in 4:3 and vice versa
  • Expect nothing to look on the projector like it does on your computer
  • Use slide decks and editors/terminals with large fonts and high contrast.
  • Don’t expect videos and audio to play; be prepared to explain them instead
  • Do not expect to be online without having a fallback solution available.
  • Expect your computer to do random annoying things as soon as you go on stage.
  • Reboot your machine before going up there
  • Turn off all notifications and ways for the audiences to hijack your screen
  • Make sure you have a profile only for presenting that has the least amount of apps installed.
  • Expect your microphone to stop working at any time or to fall off your head getting entangled in your hair/earrings/glasses/beard
  • Expect to not see the audience because of bright lights in your eyes
  • Expect to have terrible sound and hearing random things in the background and/or other presentations in adjacent rooms
  • Expect any of your demos to catch fire instead of doing what they are supposed to do
  • Have a lot of stuff on memory sticks – even when your machine dies you still have them. Be sure to format the stick to work across operating systems
  • Expect to not have the time you thought you had for your talk. I normally plan for a 10 minute difference in each direction

I’ve given up on trying high-tech presentations because too much goes wrong. I’ve tried Mac/Keynote, PC/Powerpoint, HTML Slides and PDFs and still things went wrong. I started prefering to have my slides shown on a conference computer instead of mine. At least then I have someone else to blame.

My main trick is that I have my slides as PowerPoint with all the fonts I used on a memory stick. I also have them as a PDF with all animations as single slides if even that will not work out. Be prepaired for everything to fail. And if it does, deal with it swiftly and honestly.

Getting ready to be on stage

Before going on stage there are a few things to do:

  • Announce on social media where and when you are presenting and that it is soon
  • Tell your colleagues/friends at the event where you present and that people may come and talk to them right after
  • Take some time out, go to a place where people don’t pester you and go through your talk in your head
  • Take a bio break, crossing your legs on stage is not a good plan
  • Check that your oufit has no malfunctions, drink some water, make sure your voice is clear (lozenges are a good idea)
  • Take some extra time to get to the room you present. I normally tend to sit in the talk before and use the break in between presentations to set up
  • Stock up on swag/cards and other things to immediately give to people after the talk.
  • Breathe, calm down, you’re ready, you got this

DevRel stage etiquette

Congratulations you made it. You’re on stage and the show must go on. There are a lot of things not to say on stage, and I wrote a whole post on the subject some time ago . In this current context of DevRel there are a few things that apply besides the obvious ones:

  • Don’t over-promise. Your job is to get people excited, but your technical integrity is your biggest asset
  • Don’t bad-mouth the competition. Nothing good comes from that
  • Don’t leave people wondering. Start with where the slides are available and how to contact you. Explain if you will be at the event and where to chat to you
  • Turn off all your notifications on your phone and your computer. You don’t want any sensitive information to show up on screen or some prankster in the audience post something offensive
  • Have a clean setup, people shouldn’t see personal files or weirdly named folders
  • Don’t have any slides that cause controversy without your explanations. It is a very tempting rhetoric device to show something out-of-context and describe the oddity of it. The problem is these days people post a photo of your slide. People without the context but a tendency to cause drama on social media then comment on this. You don’t want to get off stage, open your phone and drown in controversy. Not worth it.
  • Make it obvious who you work for. As mentioned earlier, this can be a problem, but you are there for this reason.
  • Show that you are part of the event by mentioning other, fitting talks on subjects you mention. This is a great way to help the organisers and help other presenters
  • Don’t get distracted when things go wrong. Admit the error, move on swiftly. It is annoying to witness several attempts of a tech demo.
  • If there is a video recording, make sure it makes sense. Don’t react to audience interjections without repeating what the context was. Don’t talk about things people on the video can’t see. When I spoke at TEDx the main message was that you talk more for the recording than the people in the room. And that applies to any multi-track conference.
  • Make sure to advocate the official communication channels of the products and teams you talk about. These are great ways to collect measureable impact information about your talk.

Things that happen after your talk

Once your done, there will be a lot of immediate requests by people. So make sure you have enough energy for that. I’m almost spent right after my talks and wished there were breaks, but you won’t get them.

Other things on your plate:

  • Use social media to thank people who went to your talk and to post a link to your slides using the conference hashtag.
  • Collect immediate social media reactions for your conference report
  • Tell people if and where you will be (probably your booth) for the rest of the conference
  • Find some calm and peace to re-charge. You’ve done good, and you should sit down, have a coffee or water and something to eat. I can’t eat before my talks, so I am famished right after

How do you know you were a success?

From a DevRel point of view it is hard to measure the success of presentations. Sure, you have impressive photos of rooms full of people. You also have some very posititive tweets by attendees and influencers as immediate feedback tends to be polarised. But what did you really achieve? How did your talk help the team and your product?

This is a real problem to answer. I always feel a high when on stage and at the event but a day later I wonder if it mattered to anyone. Sometimes you get lucky. People contact you weeks after telling you how much you inspired them. Sometimes they even show what they did with the information you told them. These are magical moments and they make it all worth while.

Feedback collected by the conference is to be taken with a grain of salt. Often there is a massive polarisation. As an example, I often have to deal with “Not technical enough” and “Too technical” at the same time. Tough to use this feedback.

One trick to make it worth while for your company and measurable is to have short-URLs in your slides. The statistics on those with the date attached can give you an idea that you made a difference.

Fact is that somehow you need to make it measurable. Going to an event and presenting is a large investment. In time, in money and also in emotional efforts. It is a great feeling to be on stage. But also remember how much time and effort you put into it. Time you could have spent on more re-usable and measurable DevRel efforts.

View full post on Christian Heilmann

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Developer Relations revelations: Conferences are a lot of work

This is part of a series of posts about the life as a DevRel person and how not all is unicorns and roses. You can read the introduction and the other parts of the series here.

So, today, let’s talk about conferences and attending them as a DevRel person.

Lanyards on my door

As an attendee conferences are amazing. You watch great talks, you can vote with your feet which ones to support. You can network and meet like-minded people. And – at good conferences – you have enough to eat, drink and you even might catch a cool party. It is a great way to get out of the office, be proud of your work or get inspired to do better. It is a welcome distraction from the daily grind and thus you love putting a lot of time into it.

Conferences for DevRel folk aren’t time-out – at all

As a DevRel person, conferences aren’t a distraction. They are part of your job. Whilst other people put extra effort in to enjoy them the fullest, you need to make sure you pace yourself not to burn out. Having a four hour sleep following an after-party is a lot less fun when you have to be on stage next morning or run a booth.

As a DevRel person conferences means 100% work. Of course, you might give a talk or workshop – I will cover that in the next post. You also might have booth duty. And even if that’s not the case, your job is to represent your company and to keep your eyes open for opportunities.

These could be

  • Covering the conference on social media. It is a nice thing to do for the conference organisers and it is a great idea to be part of the buzz
  • Conversations with influencers.
  • Talking to interesting company representatives to get workshop or collaboration opportunites.
  • Watching a talk by a colleague or friend to give them feedback.
  • Checking what the competiton is doing .
  • Eavesdropping on conversations and what currently makes your audience tick.
  • Taking notes and photos and collecting leads to add to your conference report
  • Talking shop with peers and competitors.
  • Shooting videos with interesting people
  • Showing demos on your computer
  • Helping people with problems with your products on their computers
  • Explaining people how to play with your systems
  • Dis-spell myths about your products or your competitors’
  • Give out swag and collect cool swag from others to add to your laptop

This all takes time, and effort, and a lot of concentration. You don’t sit back and enjoy the show – you are reporting on it and are part of it.

Here’s the thing: you get paid to be there. So you need to make it count for the people who sent you and make it measurable.

And that can be exhausting. It is especially exhausting when you don’t want to come across as pushy and on the clock, but be an attendee instead.

Loose lips cause Twitter Drama

Conferences are a chance for attendees to let their hair down and have fun with like-minded peers. Of course, the same can apply to you and it makes sense to be part of the fun crowd. But, whatever you say and how you behave is very much on the record. You’re not at an event – you are in the limelight.

Again: as a DevRel person at an event you are never off the record.

And the record spans much further than the event you are currently at. The bigger and more important your company is, the better headlines any of your mistakes make. We love to throw dirt at successful companies and people – that’s what all gossip magazines are about. And tech magazines beholden to clicks as revenue are not far from those.

A glib remark, a tasteless joke, some banter about your competition – easy to do at an event. And fun to do – everyone does it. But you aren’t everyone and you are not a stand-up comedian who succeeds with witty public outrage.

Fact is, as a person working at the event, you can not be part of indiscretions like that. It probably is even up to you to call these things out – in person, right at the event.

The reason – aside from the obvious – is that as a DevRel person of a hot company or product people repeat what you say. A lot of people are far too enthusiastic to do so. And what happens is that context gets lost. What was good natured fun at an event or a joke on your slides can turn nasty on Twitter for weeks after. You will be misquoted as attacking a competitor. You will come across as badmouthing your company. In a time where tech news outlets get away with quoting tweets quoting you as a source, that can last for years. Every time I am quoted as a “Microsoft engineer on Twitter” I get a small freak-out.

You have to watch how you behave and what you say as how you come across reflects on your company. And context does not protect you.

A classic trick interviewers love to do is an agreement trap. They trying to get you to agree with them when they say something bad or unproven about your competition. You need to be on your toes to not agree. Instead be adamant explaining that you don’t know about this and have nothing to add.

You do represent your company – for better or worse

People also love to bait you to get information that is speculation about your company. They bring up things your company has done in the past or does in departments far away from your influence.

They ask for very simple, true-ish, statements. Statements that make great soundbites. You need to be on your guard to deflect these arguments and not fall into the trap of being recorded as making assumptions. This would mean colleagues of yours will not only have to deal with accusations. They will have to deal with accusations backed up by a company representative. It is very tempting to shut aggressive people up my telling them what they want to hear. But there are consequences. As a DevRel person it is not uncommon that you have to prove the worth of your position to the company every few months. This won’t help.

You need downtime – but it is hard to come by

These things get a lot trickier when you are jetlagged, sleep-deprived, hung over, dehydrated and your head is full of a dozen things you need to cover at the event. Whilst not all these factors should ever be a thing, a mix and match is not uncommon, depending on your outreach strategy.

Be aware that as soon as you are visible, you will have people come to you and ask for your attention. This is a great thing, but it also needs moderation. You need to take breaks to stay lucent and helpful to people’s needs, and you can’t do that for a whole event. You also need a lot of patience as people are prone to asking you the same questions dozens of times at the same event.

Skipping talks

I’d love to see every talk I am also interested in at events, but I am not a conference participant – I am part of it. It also can get weird. Often I sit in a talk I am interested in, but I can’t see it. As people see me as an expert they keep asking me during the talk if I agree with the current points. Often points that are beyond my grasp or I heard for the first time. As a DevRel person you’re a source of confirmation for people. This is not the time to learn. You are better off watching the talk recording later. Unless, of course, the presenter is a someone you want to support or a competitor you need to watch.

I started to use talks as a chance to go back to my hotel room or a quiet room (if the conference offers those – PLEASE DO!). I fall flat on my face, groan a bit and maybe take a 15 minute power nap. I also do other things like answering emails that would otherwise pile up. I change the shirt that is not too comfortable after my talk or shows sweat stains. In any case, I try to do nothing at all and have a quiet room without people for a while to find my Zen again. You need to do this, too. It’s basic work practice and even factory workers have breaks defined by law – take yours.

When you skip some talks and go out you can come back in the breaks to network much more refreshed.

Creature comforts – drinks and food

It is quite tough to feed a herd of humans with things everyone is happy with and can consume. Especially without breaking the budget of your event. Catering is hard and expensive. I applaud every conference organiser that gets it done even half-arsed. I have massive respect for the people serving food and making sure everything stays in order.

That said, if you work on conferences, things get tricky. Lunchbreaks are a great opportunity to start chats and talk to people. Yet, talking whilst eating is tough. If the conference provides access to food before the mad rush, take advantage of that. Have a bit of food beforehand and work the room with a drink later on instead. That way you can talk to people having their break without covering yourself and them in crumbs.

Alcohol, of course, is a tricky subject. Know your limits, or just don’t drink. I learned that a glass of water with ice cubes and a lime works. You can carry it like a cocktail and it gets you in with the drinking crowd without all the ill effects and deflects peer pressure. But hey, up to you, just remember what I wrote earlier about being on the record.

It is in any case a great idea to try to live a tad healthier than people who come to party. I carry nuts and fruit and make sure I use the gym when I can in the evenings and the mornings. It is also a great opportunity to wipe your memory and get into the next day with a fresh start.

The conference end isn’t the end of your work

Once the conference finished, your collation job begins.

  • You collect all unused swag, pack it up and mail it back to the office (or haul it yourself)
  • You write your reports
  • You follow up with leads and type in dozens of emails from business cards
  • You send out information about your talk or workshop to the audience or the attendees.
  • You answer conference demands like your slide deck
  • You collect and sort your receipts for expense reports
  • You answer enthusiastic tweets and emails people sent you – it is not good to keep happy people waiting
  • You remind people you met about your conversations.

All this you need to do this as soon as possible, as the longer you wait, the more you forget. This means you also need to have some energy left for these task.

So, why do it?

Given all this work you may wonder why we bother covering that many events. Well, there are lots of great parts, too. The network you accumulate with peers and conference organisers is worth a lot. Anything to make it easier for you to get invited helps. It also helps your company a lot when they know about lots of different conferences to see which ones make sense to sponsor. And a chance encounter with engineers of a certain company at an event is often a great foot in the door for collaboration. Often I managed to get access to companies that way that sales and marketing people failed to do for years. The peer-to-peer IRL network of engineers and designers is a powerful access point.

In any case, I just wanted to list the needs and demands a dedicated DevRel person has at events. I hope this helps you prepare. I also hope that some people consider this when they tell you – once again – how easy your life is hanging out at events all the time.

View full post on Christian Heilmann

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Developer Relations revelations: not all is glamour and fun

I spent this morning at a photoshoot. A photographer dragged me all over Berlin Mitte to take photos of me holding my phone and pretending to communicate. The reason is an essay about “Jobs of the Future” for a German finance magazine. Me, I am a “Developer Relations Person/Developer Evangelist/Developer Advocate” and this is baffling to people with “normal” jobs. I’ve done this for a long time and quite some time ago I wrote the Developer Evangelism handbook.

Don't fall in love, fall in coffee...

It is flattering to see how something that niche gets mainstream attention. It is also frightening to me. The explosion of DevRel opportunities in the last years is amazing. But often I am disappointed. The idea of companies hiring DevRel people in junior positions is odd. People with no company history or product involvement being DevRel is against everything I described.

DevRel is a great opportunity for engineers to move from delivering the product to helping it to become a bigger success. We’re not sales people and we’re not marketing. We’re communicators inside and outside the company and our main task is to make it easy for developers to do their job. That needs in-depth technical knowledge and company experience. That means dealing with the needs of marketing, management and recruiting and translating those to events and team communication. It also means – to a much larger degree – to ensure that the developer’s needs inside and outside the company are communicated in an understandable and actionable manner to the company.

What annoys me a lot more though is that by painting DevRel as a job disconnected from engineering, developers lose respect. And often people don’t get just how much stress, effort and unsatisfactory agreements working in DevRel is.

On the surface, DevRel sounds like a great job. Other people do the work, all you need to do is to present it in social media, at conferences and in blog posts. It also looks incredibly glamorous. You travel all over the world. You stay in hotels all the time. You get paid to go to conferences other people have to beg their managers to get tickets for. You hang out with higher-ups in the company. You always have the coolest new swag and inside information.

Now, I have been doing this job for quite some years now, and it is important to also explain the problems with this job. I don’t want to discourage people from pursuing this idea. But I also want to talk a bit about the things that frustrate, depress and endanger you when you work in DevRel . And I want to explain how some of these things that looks shiny and great can turn exhausting and drain a lot of energy. I’ve encountered burnout and frustration and depression and with every high comes a massive low. So, maybe this will help some of you avoid these.

Over the next few days I will cover a few of the concepts of DevRel and what dark and annoying things you should be prepared for:

  • Attending conferences
  • Presenting/Workshops
  • Traveling
  • Social Media
  • Working with your own company

View full post on Christian Heilmann

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)