I recently gave a talk at Sydney’s Web Directions South on being more active as a web developer. These are the slides:

Update: The audio for this talk is now available here.

This talk came about from an article I wrote for WebStyleMag called Web Development with Curiosity.

It is also a personal story. In 2003, I discovered creating websites with CSS and HTML. It was a great time of exploration but it did not last long. In 2008, I was frustrated and bored with web development as I thought I knew all that was to know at that time.

Luckily for me, the first draft of HTML5 was released in 2008, and while reading it, I thought it would be a good idea to do an objective assessment of what I knew and how glad I am that I did that!

I opened one of my recent projects and started reading the code, to make sure I understood every code I wrote. I stumbled on the very first line: Why was I using a doctype?

In 2008, I did not have an answer! I also did not know why I was using XHTML doctype either. I knew there was a good reason to do so, but did not know exactly why. As you can tell, my confidence in my abilities burst like a balloon.

How did it happen that someone who learnt about web development in 2003 so quickly lost that knowledge? There were several reasons, but the main one being Outsourced Learning. It works this way:

I wake up in the morning, do my morning rituals, and then start reading articles from websites I track for web development. Stop to skim through an interesting article and bookmark it on delicious. Those bookmarks remain there, never to be used again. When time comes for their use, instead of looking into my bookmarks, I look for a solution on Google and use whatever comes up first (irrespective of how robust that solution is).

This is Outsourced Learning because, at best what I can do with this information is to gossip about latest techniques and demos that I come across. It does not give me any insight and expertise that I would get by practicing the technology.

I was under the illusion that by outsourcing my learning I was somehow still learning. But, as my assessment showed, I clearly wasn’t.

How can we make sure that we continue to learn instead of using stale knowledge? In the last 2 years, these two have worked for me:

• Create a Constitution
• Creating Learning Rituals

Constitution

By constitution I mean creating a support chart like so:

Features	Bling	Needs Fallback	Cannot Use
Border Radius	X	-	-
Box Shadow	X	-	-
HTML5 Forms	-	X - HTML5Widgets	-
Web Workers	-	-	X
Web Sockets	-	-	X

Categorize each new feature you come across into one of these 3 categories:

• Bling: You will use this feature, and you will not provide a fallback for browsers that do not support it.
• Needs Fallback: You will use this feature, but you will provide fallback for browsers that do not support it.
• Cannot Use Now: You will not use this feature for the time being for different reasons:
  • Lack of browser support
  • Feature is too unstable
  • Feature requires more than browser support (e.g. websockets require server-side support).

Make sure you mark which fallback you will use for each feature you put in the “needs fallback” category. Modernizr Wiki maintains an exhaustive set of fallbacks for new features.

The best part of this is not to create it, but to actively maintain it. I would recommend you glance through your Constitution at least once a month, as features may require reclassification based on support from new browsers, or may require new fallback solutions. Also, this will keep your awareness of new features up-to-date.

Create learning rituals

When you create and follow through with your learning rituals, learning about web development will become like second nature to you. It is no longer a chore, or a tiring activity, but something you just do. There are 3 ways to go about this:

• Deliberate Practice
• Passive Learning
• Participation

Deliberate Practice

I would recommend you set aside 2 hours of your week to practice web development (apart from your work schedule). This is not negotiable.

Passive Learning

• Refer to the Official Browser documentation when a particular feature does not work as per standard.
• Refer to the W3C Cheat Sheet if you want to look up a syntax for a property.
• Read these documents. It is worth your time:
  • Differences between HTML4 and HTML5
  • HTML5 The Markup Language
  • Using XHTML in HTML5
  • CS3 Selectors

Participate

The advantage of participating in online/offline activities on web development is that it is a two-way process. If you slack on your learning process, constant reminders from your communities will keep you updated on what you have missed so when you are ready to get back into the game, you do not have a black hole to start from. You already know what specifically you have to catch up to (not some voodoo called “HTML5” but specific sections in standards like “Websocket API” or “Webfonts”).

I recommend the following for participation:

• Mailing Lists
• Filing browser bug reports
• Browser communities
• Writing and sharing demos.

Mailing Lists

If you write HTML and CSS, subscribing to these mailing lists is mandatory:

• www-style: This is where you track how browsers are implementing CSS specs. This is also where you ask for features in CSS.
• whatwg: Browser developers frequently discuss new features. This is also where you can give feedback on the specs.
• mobile web: Recent mailing list exclusively for developing for mobile devices. Developing for mobile devices is a whole new level of torture that these warriors will help you overcome.

These mailing lists do get overwhelming. So, do not try to be on top of each and every thread. I usually, pick up an email thread, and spend 30 minutes or so to understand completely what that thread is discussing (and occasionally contribute to it).

Browser Bug Reports

It is almost an impossible task to check how each feature works in combination with other features. Browser developers do try, but miss a lot of use cases. So, I would think it is mandatory for developers to submit a bug report if they find a browser that renders a feature inconsistent with the description in the specification. Read John Resig’s post on a Web Developer’s Responsibility to understand how to write and where to file bug reports.

Communities:

Almost all browsers have places where they discuss and describe Open Web Standards. Subscribe and comment on their posts!

Writing and Sharing Demos:

I mentioned deliberate practice. But before you get started, you would have to get your practice tools set-up.

• Get a sandbox where you can practice without worrying if your demos are going to take your homepage/blog down. I use dropbox. You can use whatever you are comfortable with.
• Use a template to start your demos (try HTML5 Boilerplate). If you start writing code from scratch, your focus deflects from the features themselves to writing the support structure. Then again, make sure you use a template that is up-to-date and not something stale.
• Finally, start writing demos! Here are some ways to think about these demos:
  • What is the most annoying use-case at work? How can you make it less annoying?
  • Is there a repeated pattern you can replace with the new features of HTML5/CSS3 or other Open Web Standards?
  • How fancy can you get with form elements without using graphics?
  • Do you use arrow graphics in your web application? If so, how about using only CSS to do these graphics?

Once you have your demo, it is time to evaluate it!

• Test it on all browsers that your audience would use (or the audience for the websites in your workplace would). How does it render on browsers that support the required features? How does it render on all other browsers?
• Does it use a lot of CPU cycles (usually you would know this by the increased noise from the fans in your computer when you run your demo).
• Does it slow down your browser (test this by scrolling or resizing the browser window)?
• What fallback solutions do you need to render the demo correctly on all browsers?
• Finally does your Constitution require an update based on the demo?

Share

• Put up the code on Github (ask a friend how to do this, if you do not know already). Get people to comment and critique it.
• By sharing your code, you will learn more simply by having others ask questions on what you did. Even better when someone points you to a simpler solution.
• If you are working with a few other web developers, meet once a month at work to discuss either the constitution or what is new in Open Web Standards.
• You could even meet to autopsy demos. Choose a demo and change the parameters. Disable JavaScript and see how it works. Analyse its performance. How does it work when you combine it with some other feature? Are there other ways to accomplish the same demo? What are the fallbacks the demo uses? Can you use something else?

Continue Outsourced Learning

While you are doing all this, do continue with reading articles on Web Development. But do remember to be wary of any claims articles make. Everyone has biases which they may or may not be aware of.

Always test and evaluate any demo before you accept the assertions as facts.

Designers

If you are a web designer, I have news for you. It used to be that, it was sufficient to know HTML/CSS to be a web designer.

Alas, the new APIs that are available for HTML5 provide a lot of interactive features that can only be accessed through JavaScript. Learn JavaScript.

Do subscribe to the mailing lists I mentioned earlier, and be vocal about what you want from the standards bodies. If you have friends who have the same concerns as you, encourage them to voice it in the mailing lists. Browsers and standards bodies are actively looking to help web designers and developers for feature-requests and the more people who advocate it, the less it would seem like an isolated voice in the dark.

Finally, live long and prosper!