• You are currently browsing the archives for the General category.

  • Archive for the ‘General’ Category

    [German] Basta 2016 Keynote: Fahrvergnügen ohne Handbremse – IE ist tot, lang lebe das Web

    Friday, March 4th, 2016

    Webdesign nach Edge magazin

    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.

    Publikum in meinem Vortrag
    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.

    Answering some questions about developer evangelism

    Friday, February 12th, 2016

    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.

    Making ES6 available to all with ChakraCore – A talk at JFokus2016

    Thursday, February 11th, 2016

    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


    The Slide Deck is available on Slideshare.


    A screencast of the talk is on YouTube


    All the small things at Awwwards Amsterdam

    Tuesday, February 2nd, 2016

    Last week, I cut my holiday in the Bahamas short to go to the Awwwards conference in Amsterdam and deliver yet another fire and brimstone talk about performance and considering people outside of our sphere of influence.

    me at awwwardsPhoto by Trine Falbe

    The slides are on SlideShare:

    The screencast of the talk is on YouTube:

    I want to thank the organisers for allowing me to vent a bit and I was surprised to get a lot of good feedback from the audience. Whilst the conference, understandably, is very focused on design and being on the bleeding edge, some of the points I made hit home with a lot of people.

    Especially the mention of Project Oxford and its possible implementations in CMS got a lot of interest, and I’m planning to write a larger article for Smashing Magazine on this soon.

    Don’t tell me what my browser can’t do!

    Saturday, January 16th, 2016

    Chances are, your guess is wrong!

    you are obviously in the wrong place
    Arrogance towards possible customers never pays out – as shown in “Pretty Woman”

    There is nothing more frustrating than being capable of something and not getting a chance to do it. The same goes for being blocked out from something although you are capable of consuming it. Or you’re even willing to put some extra effort or even money in and you still don’t get to consume it.

    For example, I’d happily pay $50 a month to get access to Netflix’s world-wide library from any country I’m in. But the companies Netflix get their content from won’t go for that. Movies and TV show are budgeted by predicted revenue in different geographical markets with month-long breaks in between the releases. A world-wide network capable of delivering content in real time? Preposterous — let’s shut that down.

    On a less “let’s break a 100 year old monopoly” scale of annoyance, I tweeted yesterday something glib and apparently cruel:

    “Sorry, but your browser does not support WebGL!” – sorry, you are a shit coder.

    And I stand by this. I went to a web site that promised me some cute, pointless animation and technological demo. I was using Firefox Nightly — a WebGL capable browser. I also went there with Microsoft Edge — another WebGL capable browser. Finally, using Chrome, I was able to delight in seeing an animation.

    I’m not saying the creators of that thing lack in development capabilities. The demo was slick, beautiful and well coded. They still do lack in two things developers of web products (and I count apps into that) should have: empathy for the end user and an understanding that they are not in control.

    Now, I am a pretty capable technical person. When you tell me that I might be lacking WebGL, I know what you mean. I don’t lack WebGL. I was blocked out because the web site did browser sniffing instead of capability testing. But I know what could be the problem.

    A normal user of the web has no idea what WebGL is and — if you’re lucky — will try to find it on an app store. If you’re not lucky all you did is confuse a person. A person who went through the effort to click a link, open a browser and wait for your thing to load. A person that feels stupid for using your product as they have no clue what WebGL is and won’t ask. Humans hate feeling stupid and we do anything not to appear it or show it.

    This is what I mean by empathy for the end user. Our problems should never become theirs.

    A cryptic error message telling the user that they lack some technology helps nobody and is sloppy development at best, sheer arrogance at worst.

    The web is, sadly enough, littered with unhelpful error messages and assumptions that it is the user’s fault when they can’t consume the thing we built.

    Here’s a reality check — this is what our users should have to do to consume the things we build:

    That’s right. Nothing. This is the web. Everybody is invited to consume, contribute and create. This is what made it the success it is. This is what will make it outlive whatever other platform threatens it with shiny impressive interactions. Interactions at that time impossible to achieve with web technologies.

    Whenever I mention this, the knee-jerk reaction is the same:

    How can you expect us to build delightful experiences close to magic (and whatever other soundbites were in the last Apple keynote) if we keep having to support old browsers and users with terrible setups?

    You don’t have to support old browsers and terrible setups. But you are not allowed to block them out. It is a simple matter of giving a usable interface to end users. A button that does nothing when you click it is not a good experience. Test if the functionality is available, then create or show the button. This is as simple as it is.

    If you really have to rely on some technology then show people what they are missing out on and tell them how to upgrade. A screenshot or a video of a WebGL animation is still lovely to see. A message telling me I have no WebGL less so.

    Even more on the black and white scale, what the discussion boils down to is in essence:

    But it is 2016 — surely we can expect people to have JavaScript enabled — it is after all “the assembly language of the web”

    Despite the cringe-worthy misquote of the assembly language thing, here is a harsh truth:

    You can absolutely expect JavaScript to be available on your end users computers in 2016. At the same time it is painfully naive to expect it to work under all circumstances.

    JavaScript is brittle. HTML and CSS both are fault tolerant. If something goes wrong in HTML, browsers either display the content of the element or try to fix minor issues like unclosed elements for you. CSS skips lines of code it can’t understand and merrily goes on its way to show the rest of it. JavaScript breaks on errors and tells you that something went wrong. It will not execute the rest of the script, but throws in the towel and tells you to get your house in order first.

    There are many outside influences that will interfere with the execution of your JavaScript. That’s why a non-naive and non-arrogant — a dedicated and seasoned web developer — will never rely on it. Instead, you treat it as an enhancement and in an almost paranoid fashion test for the availability of everything before you access it.

    Sorry (not sorry) — this will never go away. This is the nature of JavaScript. And it is a good thing. It means we can access new features of the language as they come along instead of getting stuck in a certain state. It means we have to think about using it every time instead of relying on libraries to do the work for us. It means that we need to keep evolving with the web — a living and constantly changing medium, and not a software platform. That’s just part of it.

    This is why the whole discussion about JavaScript enabled or disabled is a massive waste of time. It is not the availability of JavaScript we need to worry about. It is our products breaking in perfectly capable environments because we rely on perfect execution instead of writing defensive code. A tumblr like Sigh, JavaScript is fun, but is pithy finger-pointing.

    There is nothing wrong with using JavaScript to build things. Just be aware that the error handling is your responsibility.

    Any message telling the user that they have to turn on JavaScript to use a certain product is a proof that you care more about your developer convenience than your users.

    It is damn hard these days to turn off JavaScript – you are complaining about a almost non-existent issue and tell the confused user to do something they don’t know how to.

    The chance that something in the JavaScript execution of any of your dozens of dependencies went wrong is much higher – and this is your job to fix. This is why advice like using noscript to provide alternative content is terrible. It means you double your workload instead of enhancing what works. Who knows? If you start with something not JavaScript dependent (or running it server side) you might find that you don’t need the complex solution you started with in the first place. Faster, smaller, easier. Sounds good, right?

    So, please, stop sniffing my browser, you will fail and tell me lies. Stop pretending that working with a brittle technology is the user’s fault when something goes wrong.

    As web developers we work in the service industry. We deliver products to people. And keeping these people happy and non-worried is our job. Nothing more, nothing less.

    Without users, your product is nothing. Sure, we are better paid and well educated and we are not flipping burgers. But we have no right whatsoever to be arrogant and not understanding that our mistakes are not the fault of our end users.

    Our demeanor when complaining about how stupid our end users and their terrible setups are reminds me of this Mitchell and Webb sketch.

    Don’t be that person. Our job is to enable people to consume, participate and create the web. This is magic. This is beautiful. This is incredibly rewarding. The next markets we should care about are ready to be as excited about the web as we were when we first encountered it. Browsers are good these days. Use what they offer after testing for it and enjoy what you can achieve. Don’t tell the user when things go wrong – they can not fix what you messed up.