Christian Heilmann

Posts Tagged ‘evangelism’

Goodbye, Yahoo – it was an awesome time

Wednesday, October 27th, 2010

Last week I handed in my notice at Yahoo to leave them for pastures new. I’ve been with the company for almost 5 years (which would have given me a gumball machine) and I have to say that I do not regret a single moment.

So yeah, I quit! Anybody for a Hot Piece of Engineer/Evangelist?

Hot piece of engineer/evangelist anyone?

So yeah, another Yahoo jumps the ship – I can already see people talking about talent bleed and all that. To all the people who blog, write and publish that Yahoo is not a technology company and there is no innovation going on I can only say: bullshit.

Yahoo rocks as a tech company

The amount of talented people I was lucky enough to work with is one of my best takeaways from the time I had at Yahoo. The amount of innovation and kick-ass tech being produced is staggering, too. Yahoo doesn’t blow its own horn about it enough, that is all. If, as a web developer you look at the Yahoo homepage and see the JS implementation and the performance you will see what I mean. Yahoo also publishes and gives out the findings for free. The design pattern library, YUI and the performance guidelines can be used by you to be as awesome without much work.

In Yahoo I learnt a lot I previously thought I knew already – having come to the company with already 8 years of experience. I got a chance to hone my speaking and training skills and I witnessed the birth of amazing technologies like GeoPlanet, YUI, YQL, YSlow, BrowserPlus and all the other things you probably miss out on if you see Yahoo as a huge ad company on its way out like some of the rag mags of our tech world love to paint it.

It is about the people

The thing that kept me for a long time in Yahoo are its people. You can have fun working there. Travelling the world and visiting different offices I was amazed just how much local flavour is retained rather than being a Silicon Valley drone someplace else. It is also OK to be outspoken in the company and nobody gets stopped from blogging, tweeting or writing their own thoughts on their own server. Going through a few interviews I found this not to be the norm at all with other companies like Yahoo.

I find myself being in contact with all of the people I care about outside the company channels and there is no way that I will not use these connections in the future to share great ideas, get inspiration and bounce off previews of the things I will release. There are far too many people to thank personally for the time I had in Yahoo and this is not for public – you know who you are.

Yahoo has its problems, and given time I will write about a few I can mention. None of these are really surprising given that they are a big company. Putting too many people together to solve a problem will always result in a lot of noise vs. signal – it is simply human nature.

So why am I quitting?

It is actually very simple – my job is done here. I’ve spent the last two years evangelising Yahoo and left over a hundred different presentations, numerous blog posts, demos and screencasts and other info on its technologies and how they fit into the larger picture of technology or how you can use them to make your life easier.

I find myself repeating what I said before and getting congratulated for getting people excited about technologies like YQL just to get the final blow of “I had no idea Yahoo did anything like that! I thought you guys were almost dead”. I don’t mind the misinformation – albeit wrong – I mind that I feel I ran in circles telling people about the real Yahoo just not to be backed up by other official statements and actions of the company.

I proposed to start a full evangelism department in the company (based on requests from engineers which also lead to me writing the Developer Evangelism Handbook), training up engineers to talk to the world and get them excited and offer evangelism and training as a natural evolution for engineers who want to talk about what they do. Right now Yahoo has two full-time developer evangelists: Tom Hughes-Croucher in the US and me for the world. There were no plans for that to change in the near future so maybe a change is in order.

The other thing is that I have been in the company too long. As I mentioned in my talk at Fronteers this year it is amazing how much better you work when you concentrate on the good things about your job. If you’ve been at one place for a long time you start to get tainted and always see the “this will not work as it didn’t before” instead of the “fuck yeah, let’s do this”.

The good news is that the man who brought me to Yahoo in the first place, Murray Rowan, is now in charge of YDN international, so I am confident he will find a replacement for me soon.

So what’s next?

Later today I will publish a chapter of a book I started but never went anywhere – so this is one of the goodies I will leave immediately. Update this is now live get the book chapter here.

As for the new job…

You know, what? I keep that announcement for tomorrow. I have a new job and I am as excited as a 12 year old in a candy shop with a free puppy section. There is a hint in the source code of the Wait-till-i.com start page and I can say that I am very much looking forward to being Wash and playing with Dinosaurs:

I am also very much looking forward to being able to rant and realise that it is me who can and will fix the thing I am annoyed about:

Thanks!

Again, me leaving Yahoo is not on a bad note – I just see myself in the way of people who should get a chance to shine. I will still be rooting from the sidelines and talk about their stuff when I like it. My last day is the 24th of November, my last official Yahoo gig is YUIConf in Sunnyvale and I will be at Science Hack Day in Palo Alto. Then I will go to Jordan to talk to the Maktoob people about the wonderful world of Yahoo Tech and on the first of December my new job starts – with me brewing a coffee in my own flat in North London and writing my first mails to the people I had so much fun with during the job interview.

Giving technology to the world – a talk about writing good code examples

Friday, February 5th, 2010

One of the things I love about my company is that you are perfectly allowed in Yahoo to give “Fire and Brimstone” talks to rally your colleagues. It is a very open company and if you can back up criticism with proof and offer solutions people are happy to listen to you.

Last Thursday I took the opportunity of being in the Silicon Valley to give a talk about giving technology to the world, pointing out mistakes we made in explaining our services and APIs, what works well and how some competitors do a great job at explaining complex technology in an easy to understand fashion.

It was a great opportunity to explain the concepts of developer evangelism to an internal audience who hadn’t yet read anything about the matter of seeing developers as an audience.

Check the slides on SlideShare and the audio on archive.org:

Listen to the Audio of the talk on archive.org:

Do you know any great API sandboxes and documentation? I’d be happy to have more positive examples!

How to write an article or tutorial the fast way

Saturday, January 2nd, 2010

As you know if you come here often, I am a very prolific writer and churn out blog posts and articles very quickly. Some people asked me how I do that – especially as they want to take part in Project 52.

Well, here is how I approach writing a new post/article:

Step 1: Find a problem to solve

Your article should solve an issue – either one you encountered yourself and always wanted to find a solution to on the web (this is how I started this blog) or something people ask on mailing lists, forums or Twitter.

Step 2: Research or code (or both)

The first step is the research of the topic you want to cover. When you write, you don’t want to get side-tracked by looking up web sites. Do your surfing, copy and paste the quotes and URLs, take the screenshots and all that jazz. Put them in a folder on your hard drive.

If your article is a code tutorial, code the whole thing and save it in different steps (plain_html.html, styled.html, script.html, final.html,final_with_docs.html). Do this step well – you will copy and paste part of the code into your article and when you find mistakes then you need to maintain it in two spots again. Make sure this code can be used by others and does not need anything only you can provide (for more tips check the write excellent code examples chapter of the developer evangelism handbook).

Step 3: Build the article outline

The next thing I do is write the outline of the article as weighted headlines (HTML, eh?). This has a few benefits.

  • You know what you will cover and it allows you to limit yourself to what is really needed.
  • You will know what follows what you are writing and already know what you don’t need to mention. I myself tend to get excited and want to say everything in the first few lines. This is bad as it doesn’t get the readers on a journey but overloads them instead.
  • You can estimate the size of the overall article
  • You can write the different parts independent of another. If you get stuck with one sub-topic, jump to one you know inside-out and get this out of the way.

It would look something like this:

Turning a nested list into a tree navigation

See the demo, download the code

Considering the audience

How do tree navigations work?

Allowing for styling

Accessibility concerns

Start with the minimal markup

Add styling

The dynamic CSS class switch

Add the script

Event delegation vs. Event handling

Adding a configuration file

Other options to consider

See it in action

Contact and comment options

Step 4: Fill in keywords for each section

For each of the sections just put in a list of keywords or topics you want to cover. This will help you to write the full text.

Turning a nested list into a tree navigation

See the demo, download the code

working demo, code on github

Considering the audience

who needs tree navigations? where are they used?

How do tree navigations work?

How does a tree navigation work? What features are common? How to allow expanding a sub-branch and keep a link to a landing page?

Allowing for styling

keep look and feel away from the script, write a clean css with background images.

Accessibility concerns

Consider keyboard access. cursor keys, tabbing not from link to link but section to section and enter to expand.

Start with the minimal markup

clean HTML, simple CSS handles, not a class per item

Add styling

show the style, explain how to alter it – show a few options

The dynamic CSS class switch

the trick to add a class to a parent element. allows for styles for the dynamic and non-dynamic version. Also prevents the need for looping

Add the script

Performance tricks, safe checking for elements, structure of the script

Event delegation vs. Event handling

One event is enough. Explain why – the menu will change as it will be maintained elsewhere.

Adding a configuration file

Take all the strings, colours and parameters and add it to a configuration file – stops people from messing with your code.

Other options to consider

Dynamic loading of child branches.

See it in action

Show again where it is and if it was used in live sites

Contact and comment options

Tell me where and how to fix things

Step 5: Write the full text for each section.

As said before you can do that in succession or part by part. I find myself filling in different sections at different times. Mostly I get out the laptop on the train and fill in a quick section I know very well on a short ride. That means it is out of my way.

Step 6: Add fillers from section to section

I then add a sentence after each section that sums up what we achieved and what we will do next. This is not really needed but great for reading flow.

Step 7: Read the lot and delete what can be deleted

The last step is to read the whole text (probably printed out as you find more mistakes that way) and see how it flows. Alter as needed and remove all the things that seemed a great idea at the first time of writing but seem superfluous now. People are busy.

Step 8: Put it live and wait for the chanting groupies

Find a place to put the article, convert it to the right format, check all the links and images and you are ready to go.

More, please, more!

More tips on the style of the article itself are also listed in the Write great posts and articles chapter of the developer evangelism handbook.

Developer Evangelism book update – new chapter on writing slides, new print version

Tuesday, December 15th, 2009

Yesterday I spent my evening updating the Developer Evangelism Handbook:

New cover. by  you.

The updates include:

The rest remains the same:

Developer Evangelism is a new kind of role in IT companies. This is the handbook how to be successful in it.

A developer evangelist is a spokesperson, mediator and translator between a company and both its technical staff and outside developers. If you think this would be a good role for you, here’s the developer evangelist handbook which gives you some great tips on how to do this job.

Using the handbook you’ll learn how to:

  • Find great web content and promote it.
  • Write for the web and create engaging code examples.
  • Use the web and the social web to your advantage to reach, research and promote.
  • Prepare and deliver great presentations

The Developer Evangelist handbook is out!

Tuesday, July 28th, 2009

Alright, after writing on it for four evenings and on one flight in between watching Watchmen and “The Boat that rocked” I am proud to present you:

The handbook explains several things:

  • What developer evangelism is
  • What makes a good developer evangelist
  • How to write for the web
  • How to use social media and the web to promote content
  • How to deliver great presentations
  • How to deal with criticism of your company and what to do with the competition
  • How to write easy to understand and useful code examples

The handbook is Creative Commons and free to use. I am working on getting a printed version out, too.

Here are shortcuts to the chapters:

You can also go to the full table of contents.