Looking around I am amazed how big the whole “developer evangelism” thing has become since we started it and I wrote the developer evangelism handbook (now updated with a new section on pre-emptive writing). I am also humbled by how many people cite it and mention it to me as a source of inspiration.

I find, however, that there is still a lot of confusion as to what developer evangelists do, and I also find lately that a lot of very obvious marketing and PR messages get sold as developer evangelism.

What we do as developer evangelists

Developer evangelism for me started out of the necessity to have an unbiased, sane voice for developers out there. We don’t sell products, we explain them and let developers make their own decisions about using them. Our main goal is word of mouth and people using the materials we provide. This means first and foremost one thing: being honest and real about what a product does and how it is useful for developers.

We also need to be the spokespeople for developers in our companies. We should know what people use out there and what they want, what excites them and how our products match those needs.

And this is where a skill comes in that can rub people with traditional marketing and PR tasks and skills the wrong way which I call pre-emptive writing.

What is pre-emptive writing?

What I mean by pre-emptive writing is that when you for example blog about a product you do not only praise its usefulness and show what it does for people but you also slip out of your role as a salesperson. Instead think of how you as a developer would read this were you a fan of a competing technology or other products.

Then you include and answer the arguments that you would write as comments to your own post playing that devil’s advocate. Instead of taking the traditional route of not mentioning flaws that might go undetected or obvious similarities to other products you mention them with the arguments that make them interesting for you. For example:

• If your product has a flaw that needs ironing out you mention what can happen and how to recover or fix the issue. You also list the obvious feedback channels people can use should that problem happen to them. As developers we know that stuff breaks – it is ridiculous to claim otherwise and let people find out the hard way
• If your product is very close to a competitor’s you explain that this is the case as the other product is a very useful thing and it wouldn’t make sense to reinvent the wheel if it runs smoothly. You point out the differences and benefits your product has – for example that it ties into a larger set of products or that it is available open source or performs better in a head-to-head comparison. People make these comparisons in any case – if you anticipate and do them in their stead they see that you are one of them and that you are not blinded by your own advertising. If the similarities are very obvious it would make you look like a very uninformed person or not very skilful liar not mentioning them

Why is this important?

Three words: de-trolling your feedback. Right now our jobs can be incredibly frustrating as the feedback we get (and marketing and PR also looks at) is largely polarised. You either have fans praising what you do over the moon or fans of your competitors pointing out that they already did the same and you are catching up.

Of course you also have comments full of vitriol by people who just hate what your company does and want to repeatedly tell you that, but that is a thing you can happily ignore.

By pointing out the obvious pros and cons of your product to people you prevent a lot of obvious hateful or overly excited comments. Yes, this will cut down on the number of comments you will get but it will also start a more interesting conversation.

Another effect of pre-emptive writing is that you don’t have to prepare a counter-statement – you already did that. In a traditional marketing world this is what you do. You don’t say what’s wrong but you prepare a statement for the press when things go wrong. In most cases you prepare this statement after things went wrong with a lot of stress, phone calls and “we need to deal with this now, people are re-tweeting and re-posting the bad messages all over the place”. This is stress we can avoid.

Getting pre-emptive writing out can be tricky as it is against a lot of basic beliefs of sales and marketing. But you are a developer evangelist – this is your job. Pre-emptive writing and constantly questioning your own products makes you one of your audience and keeps you their spokesman – a developer evangelist.

Comment on Facebook, Google+ or LinkedIn.

I like playing Doodle jump on my phone. It is a very simple, fast game and I like the graphics not trying to be impressive but just a little funny time waster. I also like that it has no music.

I also found though that it is a very good metaphor for working. Why? Well, here are some of my musings:

The simple way that quickly gets forgotten

The task of Doodle jump is to get from one platform to the next without falling. You could play almost endlessly if you just think about reaching the next platform near to you. At work, that would be doing the next task and doing that one right.

As a kid I loved Momo by Michael Ende. It is a book featuring a street cleaner who explains this way of working to Momo:

“...it’s like this. Sometimes, when you’ve a very long street ahead of you, you think how terribly long it is and feel sure you’ll never get it swept. And then you start to hurry. You work faster and faster and every time you look up there seems to be just as much left to sweep as before, and you try even harder, and you panic, and in the end you’re out of breath and have to stop—and still the street stretches away in front of you. That’s not the way to do it.

You must never think of the whole street at once, understand? You must only concentrate on the next step, the next breath, the next stroke of the broom, and the next, and the next. Nothing else.

That way you enjoy your work, which is important, because then you make a good job of it. And that’s how it ought to be.

And all at once, before you know it, you find you’ve swept the whole street clean, bit by bit. what’s more, you aren’t out of breath. That’s important, too… (28-29)”

― Michael Ende, Momo

Sure you won’t be a superhero working that way, but you deliver a job and you don’t wear yourself out.

Don’t expect stability when it is not needed

There are not many situations in the game when this changes. Yes, some platforms vanish or crack once you step on them, but so what? You normally don’t jump twice on the same plaform anyways. The only difference is that you need to be a bit faster (especially with the yellow to red fading ones). Don’t let the fact that you can’t trust that platform stress you out. All you need is to get on it once and move on.

If you have a dependency at work make sure you get from it what you need and don’t expect that to happen every single time – it won’t. Have a plan B to move ahead on instead of getting stuck trying to deliver Plan A because of something you can not control.

Reasons you die in Doodle jump

Technically the game should be never ending. There is not much that can go wrong. You jump from platform to platform, you avoid obstacles and enemies and if you can’t avoid them you can still shoot them or there are even shields you can grab to be invincible for a short while.

Actually I found most of the reasons you die to be self-made:

• Haste – instead of jumping from platform to platform it is very tempting to reach for the springs, the propeller hat, the trampolines and the jetpack to move ahead quicker. The game makers know this of course and tempt you constantly. Many a time you try doing that instead of reaching the simpler next platform. Especially in the case of a single spring this is not worthwhile as it propels you the same distance as three simpler steps would. At work, we call these things shortcuts – moving ahead too quickly to reach a goal fooling ourselves into believing we will get time to fix things later on. We won’t.
• Aggression – many a time I die in Doodle Jump it is because I try to shoot an alien (especially the one with the flapping wings as it makes me twitchy) instead of avoiding them. At work this could be trying to be as good as somebody else by all means necessary or trying to get their job. You might succeed at that but you won’t be happy doing it. Beating yourself by being better tomorrow than you are today is a way to beat competition and learn at the same time. In Doodle jump most aliens can be avoided by using platforms around them instead of shooting them – this even means you can play with one hand
• Focusing on the score – every single time my eyes go up to check the score and if I am on track to beat my last one I die in Doodle jump. Which is ironic if you think about it. At work this could be goals that the company sets for itself, your team or you for yourself. If your drive becomes to reach goals rather than doing the right things to reach them then you will fail. You will reach some of them, sure. But you will not have an arsenal of techniques to reach the next ones as you failed to think about your steps whilst reaching the goal
• Being sucked into a black hole – Doodle jump features black holes that suck you in that you cannot shoot but you need to avoid. There are also UFOs that abduct you but you can shoot those. At work we call both of these meetings, town halls and all hands. The black hole ones can sometimes not be avoided but the UFO ones could be circumvented unless you allow yourself to be sucked into every single one of them
• Distraction – of course the biggest thing is getting distracted whilst playing. Doodle jump is fast and needs your attention. Work does, too. In many cases we think we can multi-task, but we can’t. So from time to time it is important to suspend what you do and pause it before doing something else and then coming back resuming the paused task instead of trying to deliver two at the same time

Maybe I am overthinking this, but from time to time I like having fun jumping from step to step rather than speeding along with a jetpack and failing to miss my landing.

Want to fix the mobile web? Are you developing mobile apps using web standards and libraries?

At Mozilla we are right now planning our outreach to libraries and tool makers to support more than one platform when it comes to mobile web development. To make sure that we change where it is most needed we need some more information.

Could you do me a favour and fill out a quick survey about libraries and developer use?

I killed my Macbook Air the other day and I am still not convinced about the current ones. The intel video chipset has/had problems with WebGL on Chrome and when I tried to connect to a projector, it did nothing whatsoever which is a deal breaker for me as a presenter. It seems the way to fix that issue is to reboot the machine with a power lead attached and connected to the projector. But this still sounds like a hack to me and I don’t buy macs to reboot them before a talk. So I am waiting for the rumoured MBP 13” upgrade which would be cool.

What this taught me though is things I told people for years – back up all your stuff online as you can get it there as a last resort. Of course this is more frustrating than anything when you are on the road and offline or on a very slow hotel connection, but it is better than being stuck as it means that if your hardware deserts you, you can still use some other machine.

For the moment I switched to the company 15” macbook pro for work but it is incredible how unwieldy and slow this one feels in comparison. It has a traditional hard disk, and coming back to that from SSD is just weird – especially for video and presentation work. For example I recorded a voiceover for slides using the Quicktime recording in Keynote and the audio and video was completely out of sync.

So I thought that this is a great opportunity to make a total switch and give full online working a go. I am writing this on the Chromebook I got at the last Google IO and which subsequently left a shy retired life on my shelf. Upgrading to the latest Chrome OS I found it to be actually quite useful. The machine is not as heavy as the 15” MBP to carry around and the keyboard is good. The trackpad is utterly woeful however, but I am 90% a keyboard user.

For editing I use WordPress, Google Docs, Wikis and Etherpad. For coding I am using Cloud 9 IDE which ties in with Github. Storage is Google Drive (although dropbox might be better, just not sure how to do that with a Chromebook. I miss Skitch and I am still not quite happy with Twitter’s page instead of Tweetdeck/Client. I also would love to use Spotify but alas there is no web version except for setting up my own play buttons.

Things I can not do of course is video editing, but I might give the YouTube editors a go.

All in all it is incredible just how much you can do online already and in a lot of cases our offline storage is more of a Linus blanket than really having things handy as we fill up our hard drives without tagging or naming files properly. I will see how far I can go with this and try out the new features the Google infrastructure promises us.

Being able to correctly estimate time is a very important skill for speakers and people who record themselves on screencasts and the like. The media loves you when you can deliver a sound-bite of a certain length. So I thought it would be a fun thing to build a very simple game to test your sense of time.

So go and play Time yourself (source on GitHub). All you need to do is to accept the challenge and you get a message telling you how many seconds you should press your mouse or a key and it will tell you how many milliseconds you were off. Of course it then also gives you a chance to boast about your skills on Twitter using the #timeyourself hash tag.

Under the hood this is a demo for an upcoming event article for Smashing magazine and it uses the timeStamp of click and key events to measure how long you pressed the key or the mouse.

Enjoy!