Today Smashing Magazine will released an article I wrote yesterday about a “beginner tutorial” on the same magazine which showed developers how to build a Christmas wish list whilst opening up the server to a lot of attacks.

It annoyed me that these things still happen, which is why I talked to Vitaly about it (I am on the expert advisor panel of SM) and he asked me to write an article to talk about the tutorial.

The beginner tutorial loop of annoyance

In general my point is that we are flooding the web with a lot of beginner tutorials, and a lot of them are nothing of the kind. Instead, they aim to make beginners feel good about a certain topic but fail to deliver knowledge. Instead, they oversimplify and try to pad with a lot of content in one tutorial. The reactions to these kind of articles are predictable:

• Seasoned developers will find issues with the code and claim that it should not be done that way
• Other people will disagree and tell the old men to stop telling young kids to get off their lawn
• Real beginners will chime in and say that they are very happy about the article and getting the feeling that things are not as complex as they seem to be
• A lot of fanboys will mention technology XYZ that makes this much easier
• The author will add more disclaimers about the nature of the code of the article in some edits and add warning messages about its viability in the wild – saying that this is just demo code

In short – a lot of back and forth and in the end the author will comply that the tutorial might be misleading and own up that the code should not be used in a live environment and explain. That doesn’t mean though that people will not do so, which is why I consider it very dangerous to cut corners when
writing beginner tutorials.

A call for real beginner tutorials

In the article I added a call for real beginner tutorials, as right now we keep falling into the same trap:

• We assume that only quick successes will make people want to learn things
• That’s why instead of explaining one thing we build a full solution with a beautiful interface, admin interfaces and a backend – omiting important features and warnings in each of them as we don’t want to overload people
• We release code that is not safe for release or real production quality – as it is easier to explain – and warn people not to use it in the real world – assuming that people do read and follow these warnings

The big fallacy is that we try too hard to give beginners a quick way in instead of allowing them to find out things on their own terms – which includes trial and error.

jQuery is not that easy to repeat

A lot of this is trying to repeat the success of jQuery when it comes to getting new developers to hit the ground running. The problem is that the success of jQuery is only repeatable when you do the thing jQuery did – replace the original technology with a simpler syntax and richer API. This is why it is much simpler to write a tutorial on how to use an API or package to achieve a task than to teach people how to start from scratch – the final goal is much closer and success immediate.

Quick success = lots of hits

The really annoying part about this is that simple and quick tutorials with a beautiful example are incredibly successful. They get a lot of hits, happy comments from beginners who think they learned something they can repeat and because of that online magazines who need the traffic to show ads will always be happy to publish them and deliberately ask writers to add more and omit the “complex stuff”.

Use the web to link to resources for beginners

We should not teach bad practices that are hard to un-learn for the sake of a quick win and click numbers. The web is already full of great resources we can keep up-to-date (yes, the Mozilla Developer Network being the biggest) and link to instead of repeating the same mistakes and starting from scratch over and over again.

Happy holidays everyone, I just used the 3D tester and played around a bit as I was inspired by a christmas tree ornament:

The effect needs Firefox Aurora or Webkit as it uses CSS Animation and 3D transformation.

I just got a weird feeling that we are quite misusing the web at the moment to get eyeballs and clicks to our own personal blogs (I am not talking about company sites here).

Take this cool quote by Penn Jilette:

There is no god and that’s the simple truth. If every trace of any single religion died out and nothing were passed on, it would never be created exactly that way again. There might be some other nonsense in its place, but not that exact nonsense. If all of science were wiped out, it would still be true and someone would find a way to figure it all out again.

This seems to originate on imgur. Probably in a post on 4chan or some other board. Instead of just quoting as text someone put it in an image as it is more appealing and probably people link to it more. Well, the really sensible thing would be to provide the text, too, cause then people can quote and search engines can find it. I am not going to have to explain again that people who can not see the image or for whom it doesn’t load should get the info, I hope.

So this happened:

It went on mlkshk posted by Maggie Nelson, then Kottke blogged it, giving it a transcription in HTML and the enticing title “exact nonsense”. Kottke also proved his worth as a good blogger by linking the quote to the book it came from and linking the book title to Google books for you to see (a lesser blogger would have linked it to Amazon with their affiliate ID). Then Gruber blogged exactly the same post with the same title and a “via” pointing to Kottke (ommiting the link to Google Books though). This is how I found it via a retweet of Gruber by Brandon Mitchell.

I like one thing about this: that the original message was converted to a more portable format and Kottke added even meta information.

I don’t like about this that the message then gets put almost verbatim on yet another blog and information (the link to the book) gets omitted again.

I like distribution on the web and if Kottke’s blog went down we’d still have Gruber to get at least the text. In “amazing world” the original image would have had the alternative text and be linked to the book. I wonder if we don’t just get too overboard with the ‘/via’ we put on the web now – if we don’t add value to the original content by putting it on our blog. There is a lot of duplication going on and a lot of unnecessary branding. You see this with images a lot. A funny image crops up and 2 months later you see it in 20 copies (in worse quality most of the time) with watermarks of “fun collections” domains on them.

Frankly I was just annoyed that I spent time chasing the /via links in this case as I thought the title “exact nonsense” was an article by Gruber on overzealous design or code practices. I find a blog something where you should add to the subject matter, not just copy and paste. Right?

I am right now in my hotel room after the smashing magazine meetup in Stuttgart waving good-bye to each byte of the audio recording of my talk as it is uploading to archive.org (Update: it is done now). I had a great time at the meetup and want to thank Lisa, Vitaly and the others of Smashing Magazine and the Stuttgart GTUG for organising and having us.

Paul Irish’s talk HTML5 history and terminology was a good reminder on why things are the way they are in HTML5, how the HTML5 Shiv came to be and explained some terminology in detail. You can see his slides here

My own talk was more or less the blog post I wrote yesterday on discontent in the web design world but with a comparison to Ski Jumping and bringing the need for discussion and explanation home. I urged people not to repeat “best practices” and “useful shortcuts” blindly but consider the consequences instead. I also plead for less preaching and more assistance in creating new and modern web products with good approaches from the past.

The slides are available here (left+right to go back and forward, down for next bullet point and N to toggle notes):

The audio of the talk is available on archive.org

There were great questions from the audience and after the talk Paul, Vitaly and me also recorded a Podcast for Workingdraft.de which should be out soon.

Again, thanks for organising, and I had good fun there! See you next time.

There is a lot of discontent in our ranks lately. Almost every week there is something people get overly excited about and blame others for doing wrong. There are endless blog comment and Twitter arguments and they turn personal rather quickly. Or they are being labeled personal attacks where in reality there is not much to them (beware the wrong use of “ad hominem” there). All in all it feels uncomfortable and people start to not say anything for fear of being misunderstood.

And that pains me. It annoys me as I have spent almost my whole career as a web developer. It annoys me as our success so far is based on communication, publication and open discussion. It also annoys me as we are ungrateful to a job that is unique, incredibly liberating and creative.

• We do what we like to do as a job – this is rare
• We get away with much more than in any other job I ever had
• We learn from another and with lots and lots of free resources
• Our market has not enough people to fill the demand
• Companies apply to us for hiring us

Instead of being happy and amazed about that it seems to me that there is a constant craving for things to be unhappy about and complain. Maybe this is just because we like to do things in the open – the way other jobs are not done. Or maybe it is a kind of guilt syndrome cause if you don’t get just how damn privileged we are as web developers, then you are a very spoilt person.

Change is a constant, not a threat

A lot of this discontent has to do with change. Change is good, but change that repeats mistakes of the past is dangerous. Sometimes it is change for the sake of change. It is the prerogative of a new generation of makers to question the ways of old and move the craft ahead. But it is also a fact that to learn a craft, you should learn from good masters, who have experience and can prevent you from repeating their follies.

“That’s the duty of the old,” said the Librarian, “to be anxious on behalf of the young. And the duty of the young is to scorn the anxiety of the old.”

They sat for a while longer, and then parted, for it was late, and they were old and anxious.

Philip Pullman, Northern Lights

Craving controversy to win arguments

It seems that instead of trying to find a consensus, the speed and rules of internet conversations are much more likely to make people concentrate on “winning an argument”. This is where “expert panels” with added controversy at conferences come in. We stoke the fire of discontent for entertainment purposes and wonder when we don’t get anywhere when people repeat the truisms uttered there for the sake of a quick laugh or to one-up one another. The repetition of these and the quoting out of context of experts by others is what causes a lot of quarrels and discontent.

In order to understand better what is going on I wanted to explain a few things I found looking back into the history of what we do.

Bumpy beginnings

When web design started we were the joke of the design industry. The market saw the web as something that can be generated by software, Frontpage and the likes.

The battles we fought were not only of technical nature but mostly outdated and limited understanding of the web as a platform for design. People tried to control every pixel and make things look and behave exactly like print.

We had no guidelines or ideas to follow – it was pure trial and error.

One main difference to industries like interactive CD-ROMs or the likes is that when we found out how to achieve something we shared it with others. This is how the web design community started – people sharing ideas and discussing solutions.

Structuring our approach and finding our niche

Later on browsers got better and we started separating concerns of development. CSS is where the look and feel goes, HTML is there to structure the document and JavaScript and Flash brings the extra bling that can’t be added server-side.

We thought we are on a good track there. Our jobs were much more defined, we got more respect in the market and were recognised as a profession. Before we started showing a structured approach and measurable successes with web technologies we were just “designers” or “HTML monkeys”.

A hero who turned villain – IE6

IE6 was the main browser used. It was also the most capable browser when you wrote code only available in it. Tied in with developer tools and environments that were Windows only it became a very natural choice for a lot of companies to concentrate on exclusively.

And this is what we still suffer from now. A lot of work and a lot of expensive systems were built for one browser only, a browser that is now outdated and annoying. The problem is that re-writing these systems is much more expensive than writing new ones and writing new ones is more expensive than just “letting them stay the way they are”. By writing browser-specific code, we painted ourselves into a corner of “never change a running system”, and the people who suffer are the visitors having to use these now terribly dated systems and the maintaining developers.

Starting the fight for standards

This is the time where the hardliners on one side of the web development battle come from. We proved we can build amazing things on the web and now we wanted to add style and standardisation.

We wanted to make what we do predictable, teachable and understandable. For this, you need standards and style guides and they’ve served us well.

Many a man hour was not wasted by trying to understand what other developers have done. As their work applied to a standard, we knew what was supposed to happen and debugging got much easier.

Standards need to embrace change, too

What we fail to do on the web these days is to understand that our standards were defined for a time that is in the past. Instead of understanding that there is a change in what we are doing on the web we still talk about the old techniques we needed to fight the WYSIWYG editors and browser specific code that wasn’t based on an agreed standard.

So yes, at times it is totally OK not to close your tags. Some applications are fine to rely on JavaScript. And it is very much pointless to complain about the markup quality of an application that was built using GWT.

On the other hand not everything needs to be a web app the likes of Google Docs and the best practices there do violate good ideas that for example need to be followed when writing a blogging system.

We need a “pick and mix” best practice approach – not the “one size doesn’t quite fit all” we do now.

Think of the maintainers

All in all this is about maintainability. You are totally welcome to violate any best practices and ideas from the past but you should not be surprised when people maintaining your code are slow in doing so. You should also not be surprised when your projects get totally scrapped and re-build from scratch when changes need to be done.

Maybe this is a dream we have to give up. Maybe there is no such thing as longevity in web design. Maybe our job is to start from scratch every single time and maybe that is what keeps us fresh and fun to work in our environment.

From craft to commodity

The old standards for “best practices” do not apply to today’s world any longer. We wanted web development to be a craft, but it actually is becoming a commodity. The people who laughed at web developers for “not being engineers” are the ones trying to do our jobs now as we are one of the few markets that are booming.

Not so hidden agenda: getting graduates hit the ground running

And this is where a lot of the “forget the old ways, here, write less and achieve more” mentality comes from. Companies are hard pushed to hire as many engineers as they need so they want to make web development interesting for people who just came out of university. Now, in university we learn nothing that is of much use in web development. Re-educating people is a long and arduous process so let’s bring the things we learn in university into the market deliveries.

This is a good idea to hire people and to stop them from building native code (Android, iOS) instead of thinking about becoming web developers. It washes out the craft though, which is always the case when things become mainstream and need lots of people.

Where we think we build Chippendale furniture, the market needs more IKEA Billies and it makes sense to teach new people to build those.

The best change is to avoid repeating mistakes

All in all our market is changing and there is no point in taking sides and trying to torpedo each other. It is fun and damn easy to do, but it is a waste of our time.

To me, our energies should be spent on preventing repeating mistakes of the past like:

• Relying on a single browser to be the one to support – Webkit should not be the next IE6
• Write sloppy code that obviously works now but will become a nightmare to maintain in the future – shorter is not better when it needs long explanations how to change it
• Stick to tried and true old ideas and technologies by any means necessary (no, IE6 does not need animation when you can do it in CSS for other browsers)

Furthermore we should stop thinking as limited as we do right now

• Complaining about the symptoms and not the causes (we try to educate people far too late about the merits of “old school” standards web development)
• Cut corners relying on certain environments and call it “best practice”
• Embrace the idea that a semantically marked up blog is as much web development as is an app like Google Docs and an interactive video like Wilderness Downtown.
• Ask for the reason why something was done the way it was instead of flat out shooting it down in flames
• Fix things for people instead of telling them off for not doing it – most of our code is open source, so if you are unhappy with an implementation, fix it!

I don’t think that we are split in two as a community. I think we all want the same things, we just fail to be aware of the reasons, pressures and end goals that drive certain people to do things in a certain way.