What do web developers do all day?

Lightly inspired by the BBC4 series What do artists do all day?, I thought it might be instructive to set out some of the things that web developers do for you.

The assumption has been made that resources, think money, are limited, so what’s presented takes a pragmatic view of what a web developer does, not what they might do in an ideal world.

What’s a web developer?

First, let’s clarify what we mean by web development in a broad context. It can cover one or more of the following jobs, though these functions will almost certainly be done by different people:

graphic design
user experience (UX) design
page coding
data structure and database design
photography and art direction – websites have their own particular requirements for imagery
image processing and optimisation
testing in various browsers on desktops, tablets and mobiles
website configuration including cacheing and redirections

There are a number of other jobs that follow launch including:

performance optimisation
broken link checking
uptime monitoring

To give a flavour of the daily activities of a web developer, it can be useful to look at the website launch checklist - though clearly some of the items in the above list cannot be subjected to box ticking. What follows is a typical checklist for a website launch.

Website launch checklist

Easy wins

These things are usually set globally:

Site wide

Create robots.txt
Set the favicon
Create an XML sitemap
‘Pretty’ error pages, particularly 404 Not found and 410 Gone
CSS validation – Cascading Style Sheets set the presentation of the website and need to be ‘correct’
Create a KML location file – this particularly applies if you are serving a particular geographic location
Cookie policy – if you are using cookies, how you let visitors know about it
Configure analytics – frequently Google Analytics – and external diagnostic tools

For each page

Set the language and locale for the page eg en-gb, en-us, en-nz – this will help search engines return results for the appropriate locale
Set the correct language character set eg utf8
Set the viewport – this is the ‘if-you-do-nothing-else’ compliance for mobile devices
Set the canonical page – this particularly applies if you have alternative versions of a page eg http://www.yourdomain.com, http://www.yourdomain.com/index, http://yourdomain.com may all return the same page and search engines don’t like duplicates (though in this case they’d probably work out what’s going on)
Include the code for ‘analytics’ for your traffic analysis
HTML validation – HTML is the markup language used for web page and it helps to be ‘correct’
Ensure no broken links

Slightly more complex checks

Site wide

Ensure no two pages have the same title tag – this is good search engine optimisation (SEO) practice
Ensure no two pages have the same ‘meta’ description – also good SEO practice

For each page

Check spelling, grammar and consistency – eg do you write ‘website’ or ‘web site’?
Check language consistency – make sure that the spelling corresponds to the locale you’ve chosen so if it’s Belgian or Swiss French you’ve chosen you may need to write nonante instead of quatre-vingt-dix
Check that the page has the correct heading structure – H1, H2, H3 etc in the descending order
Does it print properly?
Check using real devices on all significant browsers – in reality you will have to make a selection of devices and operating systems about which you care
Review page performance to ensure that there isn’t something odd happening

For form pages

Ensure that the correct input types – new ones are available in HTML5 eg number, email, url, telephone, date
Test the form live to make sure the data is properly collected, logged and notified
Test email address validation works with new top-level and secondary domains like .aero, .uk, .ltd.uk, etc

Even more complex checks

Check the time it takes for the page to load and make sure that there are no ‘hidden’ 404s for assets
Search engines attempt to derive semantic meaning from your text so word count alone may not be enough, but the alternatives of parsing phrases, sentences and paragraphs for meaning is very hard to automate. Apart from the entertainment value, putting the core text into a translation tool and then converting that output back to the original value may give some clues.
Microdata checks – this is an optional extra for websites designed to give specific information to search engines. If you use it, it should be ‘correct’.
Security checks – a whole topic in itself that you can mostly, but not completely, ignore if you don’t have any log ins.
Accessibility checks – for the visually-impaired and others who have difficulties operating a computer - another whole topic in itself.

Post-launch

Items for someone in the business rather than a web developer

Content

Ideally a website should have content added routinely and obsolete content taken down after its initial launch. In turn this requires regular checks, particularly for broken links including those from third-party sites. Adding content may not be part of the web developer’s remit if a content management system (CMS) is in use, but they may be called upon to optimise images.

Social media

It probably isn’t appropriate for a web developer to be adding content to social media like Facebook or Twitter. This needs to be done by someone within the business.

SEO

SEO should have been built into the project and good content is a part of SEO. A web developer can run checks for basic SEO errors eg duplicates, but usually SEO is best performed by someone within the business with marketing nous.

Items for a web developer

It’s appropriate to call upon a web developer for the following:

Website performance

A web developer can give the appropriate attention to website performance if the site becomes popular or if visitors complain that it’s slow.

Stale content

Dealing with broken links and page redirections are staple web developer fare.

Traffic analysis

Ideally you should be collecting data about visitors and using this to refine your website.

Other things web developers have to do

Self-training

Web and website technology moves on at a fast pace and web developers are obliged to keep up. To set the scene, here are some ‘first’ dates:

Apple iPhone – June 2007
Android handset – October 2008
Apple iPad – April 2010

That’s not very long ago and that’s just the visible technology. Behind this are ‘back-end’ technologies that power websites that fall in and out of favour and these include:

databases including SQL and Nosql types
scripting languages – particularly JavaScript
frameworks like jQuery, MooTools, Bootstrap
web technologies like ASP.NET, IIS, PHP and Apache

There’s simply too much to learn whilst doing paying work and so web developers have to make choices – and run to catch up if their chosen technologies fall by the wayside.

Is that it?

No, because web developers also get involved in other things like dreaming up ways of using technology to make their clients’ websites more competitive, but this list is long enough for the moment.