Christian Heilmann

The prestige of being a web developer – Fronteers 11

Friday, October 7th, 2011 at 2:10 pm

The audio recording of the talk is available on


Today I will talk about about perceptions and ways how we as web developers can make our lives better. I got inspired to do so by a great movie called the prestige. The prestige is full of amazing actors and is a twist-and-turn drama story about two stage magicians who learn the trade together and then become mortal enemies. They sabotage each others’ shows, they spy on each other and steal from each other. All to get a bigger audience and to make money. The movie also shows nicely that the audience of the magic shows do not care much for the safety of the magicians – all they want is to be entertained.

One of the things explained in the movie is how magic tricks work. Every great magic trick consists of three parts or acts:

  • The first part is called “The Pledge”. You show something ordinary and build up anticipation.
  • The second act is called “The Turn”. The magician takes the ordinary something and makes it do something extraordinary.
  • The third act, the hardest part, is “The Prestige”. This is when you bring the extraordinary back to the real world.

What we do as developers of the web can seem magic to people. A lot really do not care what we do but I constantly see people on planes looking on my screen while I am fiddling with some JS or CSS and reload the browser and I see them go “oh!” and start asking me what I am doing there.

We do the same to each other. We start with the pledge of using web technologies to build an interface or a solution or a demo.

Then we fiddle around with it until it is is perfect and we show it to people and they go “ouuuhhhhh” and clap and get excited and go to Twitter, Facebook and Google+ and tell people about it.

Us, in the audience, do the same. What we miss doing is going the full way and bring “The Prestige” to others.

Making demos and playing with technology is incredibly important. More important though is slowly but steadily, or – even better – quickly bring the awesome that is in those demos to our delivery jobs.

But before I go to the prestige, let’s take a look at how you can be a good magician (as told in the movie) and how it can relate to our work.

Reuse and improve

A lot of the tricks shown on stage and in the movie are not new, but based on an older trick, spiced up with new ideas and more danger.

This we can easily do as well. Instead of reinventing the wheel we should base whatever we do on things that work. Sensible markup is not there to fill a screen, it is there to bring stability to our products.

We should not discard what we found to be a sure way of building a nice experience in the past. We should build on those principles and allow them to change to address the needs of a new audience that wants other things.

Learn from others

You can see the magicians visiting other magic shows (in disguises) and seeing how others do it, discussing how tricks could be done and trying them out for themselves.

As geeks we are prone to want to build everything ourselves. We take a glance at what other people do but at the first “meh” we see in their code we just start from scratch. You hardly see any demos and talks based on other people’s work and improving them. Why not?

Not invented here to me is the biggest problem we have. We should swallow our pride more often and just use what already works and partner with those who created these things rather than doing the same again but not quite the same but you know, better and stuff…

Be inventive

When the competition gets harder the magicians in the movie start to use special effects, fireworks and mechanical parts on their bodies to create new illusions.

If we stop inventing and tinkering we might as well give up in our job as web developers. The thing to learn from the movie though is that these things are hidden and aid the cause and are not shown as the main attraction. Right now a lot of tricks who are a necessary evil to make something work are sold as “best practices”. They can not always be applied across the board though.

Go out of your comfort zone

When one magician does a trick the other just can not fathom he goes out of the world of stage shows and tries to employ the work of Nikola Tesla who allegedly really can transport people and things to other parts of a room using electricity.

With the web moving towards tablets and mobile and rich experiences with native APIs and code we have to start to open up to learn from others. A lot of what we need to fix right now for WebGL and gaming has been fixed in Flash in the past already. If you are honest about it – the demos we show and applaud in open technologies would be laughed at when shown in Flash. So let’s reach out and talk to the experts in these fields to see what can be re-used.

Be gorgeous

Once a trick has been created, the magicians dress it up with beautiful stage machinery and gorgeous assistants and nice clothing.

When we show off things they should be gorgeous. The whole concept of “this is only a demo of course it can break” is not helpful to the cause. When we are ready to show the world about our new cool things they should look incredible, be beautifully interactive and work across the board. I’ve said it before, your code is poetry and others should learn how to play with language from it.

Be open

The most impressive tricks magicians show are the ones done in the middle of a big crowds, with everybody watching and they still manage to amaze people with seemingly impossible things.

It is very simple to create an amazing product when you control everything. This is why the web can never compete on a “completeness” level with native code on iPhones and other devices. The thing is though that it doesn’t have to and giving a web product only one interface and experience is not using it to its strengths.

Bringing the prestige

So what about the prestige? How do we bring the magic back to its origin to make it even more fascinating? One word: adaptation.

“It is not the strongest of the species that survive, nor the most intelligent, but the ones most responsive to change.”—Charles Darwin

The biggest power of open web technologies is their ability to adapt. Web applications can be re-used in closed environments by means of conversion and you can maintain your product in one space. If you want to go native you multiply your work by every platform you need to support. We should be like the web.

“I was a young man with uninformed ideas. I threw out queries, suggestions, wondering all the time over everything; and to my astonishment the ideas took like wildfire” —Charles Darwin

Never stop questioning and give your input. We are web developers, not stage magicians. Your job is not to sit their open mouthed and be awestruck. Your job is to take what the bleeding edge of our market does and bring it into the day to day delivery. You can only do that when you ask the right questions.

Don’t be out for blood.

In the movie the competition between the magicians turns tragic as in fierce competition they try to kick each other out of the market. In the past this happened with browser makers, too.

Nowadays the competition of browsers is different. We all want the new web to work. We all are aware of browsers having to adapt to new environments. This is what we should be concentrating on – not building more and more magic shows to tell the world that one or the other browser is the better one.

Therefore I’d love to see a shift in the community, something that Chris Williams talked about at JSConf, too: stop trolling, stop inciting fights and stop the greed for controversy.

We all like a good fight and we all like to see great artists and athletes compete with another. When our main focus though is to be better than others and react to attacks and things others have done we lose the opportunity to work together on a predictable web for developers and great experiences for end users across the board.

A speaker needs people he can trust

When you are on stage you are in the limelight. What you say has a lot more gravitas then when you say it in the pub. Therefore you need to have people you can trust to ensure you don’t tell lies. If you talk about a product and get people excited and the product becomes unavailable or the product team is totally unresponsive it is you who gets the blame.

Vanishing act

Three days ago, Mark Pilgrim vanished off the internet. No Twitter account, no Google+, no Facebook and all his sites, including the awesome Dive into HTML5 became a 410 “Gone” empty page.

People started getting worried and tried to contact him to no avail, they even called the police to check on him and found that he is OK and was annoyed that people went so far as to call the police.

Regardless of Mark’s reasons, this made me think about longevity. In the last year we have seen a lot of web attrition. APIs got shut down, companies closed their “labs” sections and formerly free software gets bought and vanishes quickly. Just look at the HTML5 game engines out there.

The vanishing of Dive into HTML5 was a massive blow. I linked to this great resource in almost all my presentations, when people ask me where to learn about HTML5 I sent them there. Of course there are mirrors of the site, but that still means that all my old links are broken now.

Stop following the stars, join a band

It made me think that it is time to stop relying on a few people and on ourselves as a source of truth and information. I write a lot of things on my blog and people link to that. I also don’t find time to re-visit old posts and update the information which might not be applicable any longer.

So I started to think that it makes more sense to contribute to places where people already work together to document things. Forums, developer documentations, wikis, and – of course – the Mozilla Developer Network docs.

Anyone can do that – there is an edit button on those and you can add a fix, a note or an example.

Collaborative coding and discussions

Instead of writing a blog post and hoping for comments amongst the spam I started to use collaborative tools to begin with a discussion and then write an article or post once we found an interesting solution. There are many cool tools to do so:

  • Using JSFiddle you can show some code and ask people to fix and improve it with you. You can also provide a working demo to prove a point or give a demo to people.
  • Using Google Docs and Etherpad you can write docs and explanations together and get some quick review from people.
  • Using Dropbox you can work together with people on some files.
  • Using GitHub you can spread your code and you can get and improve other people’s work.

Be your own teacher

I’ve always found that I learn best by doing. Instead of getting things explained to me and following an hour of live coding or watch a video I get the best results by downloading the code, playing with it, breaking it and finding the solution doing some research.

Anyone can do that. That is the fun about open source and the way we do things as web development speakers.

Fill the blanks

The other day I went to attend Seb Lee-Delisle’s Creative JS course. A great course and a good reminder to play with technology. The course assumed a lot of previous knowledge of how to animate with computers and basic Math of triangles and basic physics. As Smashing Magazine were very eager to get another article from me to publish I reminded myself of a few of the Math tricks used in Commodore 64 demos and wrote an article about it. The article got good comments and did the rounds on Twitter.

As an extra, I put all the demo code on JSFiddle for people to play with. People now can read that article as a refresher before the course.

Guerrilla documentation

You can do that, too. If you find something cool on GitHub and you use it and you find an annoyance, why not fix it and send the original writer a pull request? Of course not everybody is happy about changes in the code but I dare you to find anyone who’d be unhappy to get some extra docs or examples using their systems.

You could also create a folder with fixes for other browsers for demos that only work in one. There are a lot of possibilities.

Use what you hear about!

It is very important that you use what people on stage talk about. And not only give it a go in your lunch break. Implement it in products and feed back the issues you find. There is no point in us showing a brave new world of technology on stage and then never seeing it used.

Using things means we can avoid the delivering people getting more and more disconnected from those who show what “best practices” are. Or as Molly Holzschlag put it: “now that we spent 4 years making rounded corners working in every browser designers don’t want to use them as they look dated”.

Repeat the messages

Most of you work somewhere, and others work with clients. Why don’t you now go home after this conference and set up an internal meeting showing off some of the things you learned?

There are a few benefits to this: you can share the goodies, you give back to the company who paid your ticket here, you get some experience speaking and you show that Fronteers is not just a big party.

Collect good stories

If you manage to use some of the stuff you heard about here and made a client happy or worked more effectively in your job, tell this story. Send it around, blog it or send it as an email to us. We need to hear how our work has impacted your life.

Best practices are discovered, not defined

We live in a changed world. The “best practices” of old are not applicable everywhere and there is a lot of criticism towards the web camp as being people who preach dogma and missed the boat.

Let’s collect real evidence how we used open standards, sharing practices and free tools to build an amazing web. Then clean up our approach and make it a best practice based on facts instead of great principles.

It is time to step up – all of you deserve to be in the limelight

So please, join us in documenting, fixing and using what we are all very excited about. This is not a magic show, we are here to tend to the web that was so far damn good to us.

Share on Mastodon (needs instance)

Share on Twitter

My other work: