A few years ago now, I spent two afternoons to write down all I knew back then about Developer Evangelism/Advocacy and created the Developer Evangelism Handbook. It has been a massive success in terms of readers and what I hear from people has helped a lot of them find a new role in their current company or a new job in others. I know for a fact that the handbook is used in a few companies as training material and I am very happy about that. I also got thanked by a lot of people not in a role like this learning something from the handbook. This made me even happier.

With the role of developer evangelist/advocat being rampant now and not a fringe part of what we do in IT I think it is time to give the handbook some love and brush it up to a larger “Guide to Developer Evangelism/Advocacy” by re-writing parts of it and adding new, more interactive features.

For this, I am considering starting a Kickstarter project as I will have to do that in my free-time and I see people making money with things they learned. Ads on the page do not cut it – at all (a common issue when you write content for people who use ad-blockers). That’s why I want to sound the waters now to see what you’d want this guide to be like to make it worth you supporting me.

In order to learn, I put together a small survey about the Guide and I’d very much appreciate literally 5 minutes of your time to fill it out. No, you can’t win an iPad or a holiday in the Carribean, this is a legit survey.

Let’s get this started, I’d love to hear what you think.

Got comments? Please tell me on Google+ or Facebook or Twitter.

The video series “Everything wrong with $movie in $length minutes or less” by Cinema Sins is a big YouTube success and for a movie buff like me a lot of fun to watch.

The team behind it take a lot of time to meticulously analyse goofs and issues in movies and mercilessly point them out in short movies. Frankly, I am amazed they can show that much footage of current movies without take-downs and that they have such a quick turnaround time. It is funny, it is parody and satire and it shows that even the most polished and expensive products of the entertainment history aren’t safe from slip-ups. What I like most about them though is that they are also pointing out how they themselves are not without fault: “We are not reviewers – we’re assholes”.

I see a lot of parallels in how people criticise products on the web – we don’t really look at the why and how something was built but from the get-go try to find the simple to prove fault and talk about that instead. The fault that probably only us web developers will ever see or even remotely care about.

This, in itself is not a bad thing as it shows that we care about our craft and look at what other people do. This can be gratifying which is why we leave code comments and easter eggs – a secret handshake from one professional to another. We want people to look at what we do. We do not, however need people to nit-pick at one small detail and disregard the rest of our work as that is hurtful and makes the person reporting the issue (and only this issue) appear as intentionally hurting or trying to find a flaw at all cost.

Things go wrong, and in many cases we don’t know the reason. It could be that the place the content is published has limited access to the writer, thus forcing us to use an image where a text with CSS would have been better. Zeldman put that eloquently in his Get off my lawn! essay where he explained that it is not ironic if an article about a certain best practice gets published on a platform that doesn’t follow that practice.

It could be that the product had to be shipped at a certain date no matter what and corners had to be cut – a fault of the project manager, not the developer/designer. Many things are impacting the release of a web product (and that includes apps in my book); it is unfair to blame the executing party.

Maybe it is a good idea to reconsider publishing that one fault publicly and instead do a two minute research finding the makers of the product and report the fault there. Instead of public naming and shaming and – let’s face it – gloating we could thus either report an unknown fault to those who can fix it or learn why something happened. In either case, this means you are a constructive critic and don’t come across as a know-it-all. It is very simple to point out a flaw, harder to fix it and hardest to prevent them. To the outside, our constant nit-picking doesn’t make us look an inviting bunch, and is the small moment of fame finding the obvious bug worth that?

The second day of Chrome Developer Summit continued as strong as the first one, with few surprises but solid information.

Here’s my personal reviews of the sessions – again to be taken with the knowledge that I spend a lot of times at conferences so there is less “new to me”.

Blink: Behind the scenes – Greg Simon and Eric Seidel

This session was a well paced, good introduction of what is new in Blink and what this means to Chrome. It seems Blink is concentrating on interesting things like Webcomponents, partial layout and CSS grids (which was a bit of a surprise seeing that it is the IE contender for Flexbox). The presentation was solid and delivered with the right amount of “look at us”. Interesting.

#perfmatters: Instant mobile web apps – Bryan McQuade

Bryan gave a performance talk that was catered to making a web site to show up in a mobile browser in one second rather than the twenty it originally took. He explained the steps needed to make that happen, repeating a lot of information that has been mentioned in talks in for example Yahoo some years ago but that sadly enough keep getting forgotten.

I liked this presentation a lot – rather than just showing off the tools Chrome has to analyse your content it showed the difference a few tweaks can make. A lot is going back to what we did in the past and replaced by clever JS trickery – like writing static HTML instead of generating a, well, static page.

Best UX patterns for mobile web apps – Paul Kinlan

Paul Kinlan is a good, dry and very down to earth presenter. He showed a lot of issues with web products being shown on mobiles starting with an analysis of the top 1000 pages in Alexa and the very basic things they do wrong, like omitting a viewport definition. He then proceeded to show how the results of that research got incorporated into the Pagespeed Insights tool in a new “User Experience” section to follow which allows you to fix the biggest issues. This experimental feature (enabled by adding a ux=1 parameter) needs feedback, so play with it. Good talk and insights.

Multi-device accessibility – Alice Boxhall

It was great to see an accessibility talk at the event and Alice did a good job repeating the need for basic keyboard access and mistakes being made that are simple to fix but result in a massive barrier for people with different abilities. She also did a good job debunking the idea that accessibility is only for people with severe problems but a matter of availability. The talk covered various accessibility issues and how to fix them, the accessibility add-on for Chrome devtools which allows to debug ARIA and shows problems to fix and ended with a list of free resources like screenreaders to test with. Nothing new here (to me at least), but very important information for this audience. I get a bit worried about ARIA as a solution though as it really is meant to be a fix. A lot of times it is not needed if you use the correct markup to start with.

Got SSL? An overview of why you need it and how to do it right. – Parisa Tabriz

This was probably my favourite talk of the day. Parisa did a great job explaining why you should use SSL, how to do it, what it protects you and your users from and what still can go wrong in terms of privacy and security. A good reminder that HTTPS is not slow and expensive like it used to be but actually easy to go for these days.

DevTools for Mobile – Paul Irish

Paul is a seasoned presenter and has gotten better and better over time. I am not very partial to the “yay, dudes, this is how easy stuff is” style of presenting and was happy to see that this was not one of them. Paul did a good job of telling a story of how developer tools evolved and bit by bit showed the audience the great new features in Chrome devtools to remote debug on mobile devices and simulate devices on the desktop. A boatload of great new features have been added. Talking to other people there was not much here that wasn’t in his Google IO talk, but I was impressed, both by the features shown and the nonchalant way he presented them.

Optimizing your workflow for a cross-device world – Matt Gaunt

Matt took over from where Paul started and showed how to test on various devices in parallel and using tools like Yeoman to work on desktop and mobile in parallel without having to reload any of them. He is a valuable new addition to the devrel team and dealt with breakage of demos gracefully explaining simply what could have happened. It is refreshing to see a native developer share his story how he got more web focused and bringing his tooling requirements to the new environment.

Chrome and Android leadership Q&A panel

The final panel had the leads of different technology platforms in Google answer people’s questions with Jake Archibald trying to juggle the answers and collate lots of different questions. Interesting insights here and some good explanations why some decisions were made that look like going back in the “don’t be evil” and “HTML5 is the platform” messaging. If you want to know why packaged apps were the way to go for Chrome, there were some good answers here.

Breakout session: Code education

The last thing I attended was a longer session on code education covering Coder which was a very open discussion about online education in general. Coder is an interesting idea and I tried to see how we can align and re-use some of the content of Webmaker

Summary

All in all, I have to congratulate the Chrome team on a very successful event. There was a lot to take in, there was no dull moment and all the speakers did a good job mixing news with explaining the why and repeating important messages. There was no hand-waving but we heard about the possible but also about what still needs to be done.
My initial fear of getting a Chrome indoctrination over two days was not at all validated, this was a summit about web technologies and how Chrome solves some of the problems for developers but also for their needs. There is a lot of innovation going on here and whilst not all will come to fruition it is something to compare to the work of other people and align to get this ready for all.
It was very much worth my time coming and I had no trouble staying interested and following the action. Great job all around.

When I was invited to come to the Chrome Developer Summit, I went with a sense of dread. I got a weird impression the last few months that Google is pushing very hard into a Chrome-only world, with lots of information about Dart and APIs only available in Chrome packaged apps flooding Google+ and the announcement that extensions to Chrome can only come from the store now. That said, I have massive respect for the Chrome relations team and many people in there I love to work with. So I went to see what’s what.

The conference organisation

All in all, it was an excellent conference so far. It seems that the Chrome Developer Summit has taken a leaf out of the book of smaller conferences like Edge and Full Frontal and learned that a single track conference with shorter talks and larger breaks makes more sense than hour-long talks rushing people from track to track. The event was also streamed and I am sure the recordings will be available, too.

The location – one building on the Google Campus – was easy to get to and had all the facilities to look after a large group of geeks already in place. Food and drink was plentiful and good; breaks were half an hour each which gave people plenty of time to network and ask questions. Instead of Q&A speakers were available in the breaks after their talk at a dedicated “meet the speakers” spot. That made it much less of a rush to get the answers you wanted.

Jake Archibald and Paul Irish did the moderation and introduction of the other speakers which was very low key and just the right amount of information and – in Jake’s case – a good amount of dry humour.

Audience

The audience was mostly developers and a who is who of client-side development. In addition to the Google developers working on bleeding edge stuff well known faces like Alex Sexton, Brian LeRoux, Nicole Sullivan, Eli Fidler and quite a few Microsoft people were around to chat.

Following is a presentation by presentation review I was asked to put together, pointing out what I liked but also what could be improved. Bear in mind that right now I live from event to event and dabble in the bleeding edge of what browsers do. Some of this might sound harsh because of that but I was explicitly asked to give this kind of unfiltered feedback. That way I ask you to read the following with me playing the role of the harsher judge of a TV “next rockstar” show rather than the one who is supposed to make you feel good before the other one can crush you.

Keynote by Linus Upson

This was the first surprise. Linus is a very down-to-earth, charming speaker and instead of pushing Chrome we got a history of writing code for the web, the move towards mobile and apps and what challenges it brings. Linus forgot a few things and had to ask his experts to help him out, which may sound terrible in a keynote, but to me actually made it much warmer and human. I was really inspired and it managed to evaporate my worries of being at a two day indoctrination summit to the way of the Chrome.

Build mobile apps with Chrome WebView by Matt Gaunt

Matt introduced the new features of Chrome Webview. Lots of good information here and no glossing over the issues that are still there with the concept of WebViews (deep connection with the OS, not automatically updating, lack of support of technologies available in Chrome Desktop). I’ve never seen Matt speak before, and it was a well paced talk with lots of good information.

Network connectivity: optional by Jake Archibald

Jake is always very insightful and extremely funny to watch. In this talk he covered the issues of detecting connectivity and being able to provide offline functionality using current solutions like Appcache but also improved ideas like Service Workers. I’ve seen excellent talks by Jake. This one did the job, but felt a bit rushed. I guess the double duty as moderator and presenter is tough to pull off.

Media APIs for the multi-platform web – Sam Dutton and Jan Linden

This was the show-and-tell talk about all the cool things we can do with media. Video, Audio, WebRTC, realtime communication and so forth. Sam and Jan did a good job of showing that WebRTC is more than getUserMedia and give a lot of demos how we can use multimedia natively on the web these days. They were also joined on stage by Chris Wilson and his magical Midi and USB hardware – if only briefly. Technically this was a really good talk and showed the state of WebRTC, I just found that it tried to show too many demos for a half hour talk and thus felt a bit dense and rushed and in the end it ran out of time. Two really significant demos, less extra hardware and more “check this out as homework” would have been better.

#perfmatters: Tooling techniques for the performance ninja – Colt McAnlis

Colt, self proclaimed “angry bald man who shouts a lot about performance” did exactly that. A lot of great information about performance, delivered at machine gun speed with a lot of good things to take away. It could have been overwhelming for some. I enjoyed it.

#perfmatters: Optimizing network performance – Ilya Grigorik

Ilya’s talk was one that would have gone down immensely well at a performance conference like Velocity. Lots of information, a lot of it based on real data and analysed eloquently and with proven results. I felt a bit overwhelmed and it was too academic for me. Basically all the information was on the slides and Ilya read it out to us. I guess with a data-heavy topic this can work, but I was missing some zing for it to be an engaging presentation. I want to see this as a post.

#perfmatters: 60fps layout and rendering – Tom Wiltzius and Nat Duca

The first of my two highlights of the day, Tom and Nat did a great job selling the jankfree idea with real examples how to make scrolling smooth in a web view and on the desktop. Lots of great information about performance optimisations, how to use tools to find the bottlenecks and what to avoid if you want to create a truly engaging experience on the web. These talks can come across as very arrogant and condescending (“this is how you do it”) but the interplay of Tom and Nat on stage made it much more human and exciting than many other talks I saw with this topic. There was also no selling of pixie dust – we heard about the good and the bad in equal measures. More of that.

Polymer: declarative, encapsulated, and reusable components for the web – Eric Bidelman

My second highlight (probably because I really dig web components by now) was Eric Bidelman explaining Polymer and web components by starting with the humble select element and how versatile it was and how this fidelity of declarative markup can be achieved for all of our widgets using web components. Seth showed short and to-the-point demos of how to use web components and what they are good for. This was not “the Polymer show” but a good introduction to the need for web components and an explanation how Polymer makes them possible today rather than having to wait for them. Excellent job.

Dart for the modern web developer – Kasper Lund and Seth Ladd

This one already got some flak online for being a talk that didn’t tell many new things seeing the improvements that are happening to JavaScript itself. While I don’t necessarily agree or disagree, I enjoyed the talk. I don’t care about Dart, I never was interested in writing a language that “fixes JavaScript” but converts to it. The way Seth and Kasper showed the language though showed me how it can be very interesting for certain developers and I found the explanation how Dart optimises the generated JavaScript very insightful. My main worry about abstractions is always that the final code is not only unreadable but also bloated (GWT anyone?). I now am actually pretty confident that Dart can make people happier with writing for the web and result in optimised, fast JavaScript, too. I’ve avoided Dart talks before this, now I know what they try to do and am happy with it.

Develop Chrome Apps on desktop/mobile, distribute and profit – Joe Marini

The packaged Chrome Apps talk was not the “hey, this solves all your problems” presentation I dreaded but a nice overview of how packaging an app for Chrome or via Phonegap makes it achieve more in the OS it runs in. Much like the talks I give about Firefox OS, with a bit less standardization proposals mixed in. Joe showed some nice demos, explained why Chrome needed a packaged app model and how to get started. A solid talk, maybe only lacking some real success stories. Some of it was glossed over and shown to impress. Sure you can make a text editor in HTML5 look like SublimeText; the real issue is making it have the same keyboard shortcut fidelity and speed in rendering lots and lots of code. I liked very much though how Joe explained the need for real offline functionality being easier to achieve and easier to understand for end users in packaged apps.

Portable Native Client: How we learned to stop compiling and love the translator – Molly Mackinlay and David Sehr

pNaCL was one of the big things for Samsung at their developer conference in San Francisco a few weeks ago. They did a great job showing how this technology allows to convert C++/Java/C# etc. code to the web whilst keeping performance and security and the development tool chain the same for developers of classic native apps. This talk, however, it has to be said, was terrible. It appeared badly rehearsed, sounded at times very condescending and was all in all a pure sales pitch sometimes disagreeing with great points already made and proven in other talks.

Summary

Day one was well worth it and I congratulate the events team on a job well done. The only real issue I had was the presentation part of the event ending with the worst presentation instead of leaving with a bang and giving people some excitement to talk about at the after party. I’d have loved to see something at the end that is brand new, a preview of things to come, something that only people following this event, right now, could see and talk about. Start strong, end strong. Let’s see what tomorrow will bring.

I spend a lot of my time right now coaching people on public speaking and attending conferences seeing other presenters. The latter is a great step to get into presenting yourself. Analyse what you see, find what you like and what you could use without parroting what the other speaker does. Also take down what you thought was bad and store it in the back of your head to avoid when it is your turn to dazzle an audience.

Presenting is not about winning against other presenters

I see a lot of talent and I see a lot of great stuff happening. I also see a worrying trend though trying to impress and audience and “win the conference” or “kill it” with a great talk. In other words, we plan technology performances rather than conference talks.

Attendee feedback seems to say that this is what we need to do; a talk showing how to control a model helicopter with JavaScript gets more votes than one explaining how to fix a layout issue across browsers. The latter does make us more effective in our jobs, the former is inspiring and has a cool factor we’d love our jobs to have every day. It is technological escapism. Maybe there is a place for that in tech conferences – a presentation is a performance as much as a teaching exercise – but I see too much of it. There are excellent people out there doing this kind of work – Seb Lee-Delisle comes to mind – but we also need people who show how doing something in a certain way yielded great, albeit more boring, results.

Nicholas Zakas just wrote about the issue that conference talks seem to trend towards showing us the “soon possible” and “amazing without proof” instead of case studies proving that doing something in a certain way yields great results.

I agree to a certain point, but also realise that filling a conference with great talks is a hard job. A conference consisting 90% of case studies would not be much better – as you can not assume that attendees have the same problems to solve. A lot of what we hear at conferences as “best practices” might apply to GMail’s mobile interface, Spotify’s “find new music” feature or Facebook’s chat panel, but doesn’t apply to a large part of the market out there. And I don’t buy the logic of “if it works in a high-traffic, technically taxing environment it will make everything better” – an argument we keep hearing a lot when it comes to the web on mobiles. What makes sense for a game might not make sense for a CMS driven content site. Delivering a great experience is more than technical excellence and people do use slow interfaces if the content is good enough – heck, I wait 30 seconds for Minion Run on my Android to start as I like playing it.

Why not talk about what you know and how you do things?

What does this mean? It means that there is a massive demand for talks that are coming from the unknown territory of implementation that is not needed for the big players. How did you clean up a Drupal driven site? How did you manage to sell new technology in a local government project? What does making an interface accessible really mean? How can we deal with old Android phones?

Instead I see an annoying effect of the “let’s impress people with technology” talks: a lot of upcoming speakers bend over backwards to write the awesome cool new talk showing an alpha tech product that makes “everything easy” instead of, well, crafting a presentation and talking about what they do and know.

Live coding, interactive examples and “hey this is not a problem at all” talks are highly successful. They can also backfire. Yes, you get the audience clapping, the oohs and aahs and the overly excited tweets. But you also get forgotten as fast when people realise that they can not use what you showed and that five other speakers at three of the conferences running in parallel pulled the same trick. And if you do it over and over again you “kill it” at the conference, but you also – in the long run – under-deliver as people can’t take home what you taught them and impress their boss with it. To me, this is always the main result I want to achieve.

The awesome that actually is a mistake in disguise

I see the search for the “Tech awesome extravaganza” talks be frustrating for a lot of people who are interested in presenting but feel inadequate to do so from the get-go. Which, of course, is nonsense. That’s like saying that there is no point in starting to run as an exercise as Usain Bolt will always be faster than you. What I see a lot is people making the following mistakes when presenting which do work when you are a seasoned speaker but are pretty disrupting when you are not. All of these are born out of the desire to be as cool as that talk that caused the loudest feedback, and we assume therefore to be the most successful.

• Showing too many examples – a lot of decks or outlines I get to review show five or more code examples to talk through. You won’t have time for that unless you rush. Either create one example and build onto that one – then five to seven steps can be easily done – or show two or three, tops.
• Introduce lookatme.js or iassureyouitworks.io – the solution to all of our worries. A lot of times these are abstractions of very complex, still evolving technologies in three lines of code with only five dependencies on other frameworks and libraries. Without your awesome solution having proven itself in a real production environment you are selling pixie dust. Even worse, you discourage the audience to give feedback to the experimental technologies you try to get people to use.
• Build the most complex thing ever and rely on stage tech – you will be offline, trust me, do not rely on wireless or 3G to be available. Also, bringing a lot of hardware and funky gadgets means you make the life of the stage technicians and organisers hell. You probably also will take too much time and make the presenter after you suffer for it as most conferences plan very tight hand-over periods in between speakers
• Meme overload – this is hot right now, and will make you look like a dork in a year’s time. Stay ahead of the fads, you are a professional.
• Minimalism – if your slide says a cryptic word and you are just showing live code at that time – call it demo and link to a code sample that will be available after the conference

You are totally invited to do whatever you want – I am not saying that any of the above can not work and be very natural for you. I am just saying that a lot of it can seem forced to comply with a current trend. And it can make you look like a fraud, or actually be caused by you trying too hard not to look like one.

We need all kind of talks, and the best I have seen and remember and keep telling people about and go back to several times are not the flashy ones. They are the ones based on lots of research, show solutions and explain why the solution came about. Tell your story, do not throw out confetti and hope it sticks and someone turns it into great novels and understandable books. Many great ideas die these days as a “perfect, small solution” is at their start that never gets taken further as it fails to deliver in production.