Lately I find more and more people in comments fighting for the need for “view-source” in our web products and claiming it to be a “vital part of the open web” and a “great way of learning for new developers”. This ails me as it is in my point of view a very outdated idea of learning and building web sites. I am not saying that view-source is not important – I am saying that there are better ways of learning and analysing code.

When view-source was king

Back in the days when I started working on the web you learned by looking at the source code of other peoples live web sites, copying and pasting what they’ve done and reverse engineering the workings to see how you can use or improve it. This is how I learnt JavaScript as there were no free blogs, tutorials or articles out there to tell me. The books available (basically the JavaScript Reference) dealt with the technologies themselves and not their application in a browser world. JavaScript for example was still considered a toy language in comparison to the mighty Perl or ASP or PHP or Java.

A few years before the web I learnt Assembly Language by analysing games on my C64 and trying to get endless lives. I did this by freezing the game, checking the part of the screen that changed when I lost a life (the counter) and then hunting through the memory to find the code that altered the counter on the screen (finding the DEC). I learnt how to cheat the system – not how to write Assembly Language. That came later when I had spent a few years reverse engineering.

That kind of commitment we don’t have time for if you want to learn web development.

View source gives you a view and not the source

Despite the time spent, the problem with looking at a web site with view source is that you don’t see the source, but you see a view:

• If you build web sites with performance in mind and in high end environments you send browser-optimized views to different browsers. This means that learners would see what is optimised for Firefox and then try it out in Safari. Or worse, they see what we need to jump through to make old IEs behave and consider this the best way of developing.
• Live code is normally minified and concatenated and has comments removed. So you learn the how but not the why. Some of the things you see might be terrible hacks but necessary for the environment used to build the web site.
• Checking generated source is even worse. Browsers add browser-specific code that the original writer never added.
• Live web sites are normally built by committee and have a lot of things in them the developer feels dirty about: tracking codes, third party ads with ridiculous code quality, quick hacks to get the thing out the door at the agreed time and date.
• Most web sites these days are not written by hand – if you build for the web and you don’t use the power templating, CMS and databases and web services offer you are missing out on a lot of great opportunities. HTML is the end product of a methodology and a build process – not the start of it.

Open source is the new view-source

If you really want to learn about how web sites are built and how to use certain technologies, look at the source code repositories instead. GitHub, SourceForge, Google Code and all the others are full of great examples. This is where developers communicate with each other and show off the newest technologies.

As the final product is created and not written by hand you will find the important comments as to why something is the way it is there.

Say my entry to the 10K competition World Info. If you look at the source code you will see minified JS and CSS, all of it inline. I would never code that way. This is the result of a build script. I tell the world that:

If you look at the source on GitHub you get step by step comments how I have built the solution.

What would a new learner get more information from? This was not much more work for me – as I document where I write I keep things up-to-date. Even more interesting, I actually fixed a few problems and change my code while I was documenting it – as I was forced to look at it again from a different angle after having written it.

Learn the why not only the how

The main problem with teaching people how to become good web developers is that there is a massive lack of patience. Instead of realising that knowing the syntax of a language doesn’t make you a developer we think this is all that is needed. It is like learning the grammar of a language and then trying to communicate without having the vocabulary. Or analysing the syntax of a poem without looking at the metaphors and their meaning or the historical environment it was written in. Most of what makes development and writing art and craft is lost because of the lack of patience.

W3Schools is a great example. It tells you the quickest solution and gives you something to play with. This is why it is massively successful. It is a terrible resource though as it doesn’t explain what can go wrong, when this would be a bad solution and it gives people the idea that they know everything by knowing the syntax. The PHP documentation is better as you learn in the community comments how to apply the functions and how they fail.

If you really want to learn about web development and standards then there are a few very good resources:

• The Opera Web Standards Curriculum
• WaSP Interact
• HTML5 Doctor
• CSS3.info

And far too many personal blogs that I could list here now. None of these are 2 second lookup tasks – but once you went through some of them you will know the why and the how and you will be able to see what is sensible to take on from a source view and what is probably not that a good idea.

In a few hours Web Directions East in Tokyo will kick off with a Pecha Kucha presentation night. This means that every speaker gets to show 20 slides in 20 seconds each (I first thought the whole presentation was 20 seconds) and it is all good fun and speedy. Here are my slides that I will show as I am not speaking at the conference – I will be just a booth babe. Eye candy, so to say.

Notes

1. I am Chris and my job is to make developers happy.
2. I travel the world talking to people about simple solutions to big problems.
3. And I love my job.
4. To me, the web is not about sites and code.
5. It is about information – data.
6. The web is full of great information and tools that help us deal with information.
7. All we need is a simple way to reach that information.
8. And remix it.
9. Once we have the data we can build great interfaces that help everyone to consume that data.
10. All this needs passion.
11. And collaboration.
12. When we all – world-wide – work together towards the same goals, our job is easy.
13. This means re-using what other people have done.
14. This is not cheating – on the contrary, it is a cleverer way of dealing with a problem that we all have.
15. Using systems that have proven to work means they can be constantly upgraded and secured.
16. Working together on systems that by make it easier and more secure to use our products protects our users.
17. So before you build something, look around what was already done and can be re-used.
18. If you build something, give it out for free.
19. You will reach more people like you and get feedback on improvements that you had no idea about.
20. Together we can build the future, each on our own can create a nice present.

Things that made me happy this morning:

• The source code of the moon landing control programs has been released as open source. Now get soldering and build the hardware in Arduino. I also checked the code and could not find a fake call!
• MapQuest released their driving directions web service
• AnythingZoomer is a jQuery script that provides you with a little lens to zoom parts of the screen. Nothing new, but potentially useful.
• Open a banana like a monkey is one of those videos that makes you go “why did I do it wrong my whole life?”
• Apparently rounded corners are all the rage in remedy packages – Apple has a lot to answer for, but I like it.
• Moddims is an Apache module that uses ImageMagick to convert pictures on the fly. Great for a thumbnail API.
• Make magazine has a cool EeePC hardware notifier hack that embeds an LED into the casing which flashes in different colours depending on you getting an IM, an email or a Tweet.
• IBM has a long and detailed article on using jQuery with JSON-P
• Opera’s Hallvord shows us the most expensive line of JavaScript ever

• A great flickr collection of Lego Minifig re-enactments of classic photos
• The w3c showing some very dry twitter humour
• How to fake time travel using twitter
• Gez Lemon shows how to create accessible drag and drop using ARIA.
• YQL is now not only read but also insert,update and delete.
• A great but also very graphic video and campaign about Motor Neurone Disease – MND
• The BBC finally released their JavaScript library Glow as open source.
• Slickmap is a CSS to show sitemaps in a very nice fashion.
• A proposal for Anti paparazzi clothes and accessories
• A Nice tongue-in-cheek minimal CSS framework
• A proposal by Yahoo to open source one of our Apache mods – geared for high traffic sites
• SoundAmp – an application for the iPhone turns the device into something of a hearing -aid. Whilst this does not really help the hard of hearing I love that somebody thought about using the microphone of the iPhone as an input and thought about accessibility.
• A set of Lovely social media icons by Paul Robert Lloyd

My talk at the Geek Meet in Craiova/Romania last week covered a topic that I consider terribly important right now. As developers we are constantly shooting ourselves in the foot and create new and improved bullets to make it hurt a bit less instead of not doing that.

We constantly complain about the world, our colleagues, the market and of course our “stupid company” but at the same time we got noone to blame but ourselves for a lot of the stupid things that happen to us.

As developers we have this tiny little bad adviser living in our heads: the feature creature^*.

This one keeps telling us constantly not only to add more features to our solutions but it also gives us a terribly inflated sense of what our job is to bring to the world.

It makes us arrogant and ignorant to the solutions that other developers – just like us – already developed and offer for use. In short, it makes us do the same jobs over and over again as we know best instead of telling us to have a look around at what has already been done and tweak or extend it to our needs.

Instead of spending time on creating well-documented software that is built to be customized and allows for plugins and extensions we keep building the same software types we refuse to use ourselves as they don’t exactly do what we want.

Maybe it is time to shut the little feature creature up and work together on bigger, better and more stable solutions. It is not about who can make the fastest and smallest and most optimized code. This is an extra step we should take when we need exceptional performance, not the common use case.

If you want to go nuts on bringing the best out of hardware and technology, go and do some stuff in the demo scene, this is where I got rid of a lot of my bad habits.

I’ve put the slides up on SlideShare:

[slideshare id=799134&doc=resistingthefeaturecreature-1227921707703820-8&w=425]

^* The feature creature is not my invention, I heard it from a speaker in 2004/2005 at the PHP conference in Amsterdam, but for the life of me I cannot remember who it was. He was ranting about Struts a lot, I remember that.