• build accessible websites already or
• would like to in theory

However, if you work for a digital agency it’s likely you simply do not have the time to perform accessibility testing and it’s likely you don’t have anyone above you to help you out when you hit a brick wall – which is often when you first get started with a11y.

If you work in an organisation that does have the time to make things accessible you may not have the budget to properly test e.g. do you have the budget to pay for several different versions Jaws (because people don’t update Jaws too often) or the patience to run the demo version for 30 minutes at a time or the budget to pay for a 3rd party testing company?

For a recent project, I was tasked with making the site accessible. As I said before, most developers and designers like to think that their code/designs are accessible already but, in my experience, few actually test and ensure that they truly are. However, on this project the end-client requested Level AA WCAG 2.0 compliance and the agency (my client) hired a 3rd party supplier to test.

Whenever an accessibility bug was found, a card was created in Trello and that card stayed there until it was fixed. That meant accountability and it meant accessibility bugs could not be ignored.

When we make something accessible… what exactly are we looking to achieve?

• The site works with keyboard functionality (e.g. tabbing to links and form elements with a mouse)
• The site works for colour blind people (e.g. not just conveying information with colour alone)
• The site works for people will poor eyesight (who may zoom in or simply need a large enough font size and high contrast)
• The site works for visually impaired (or blind) people who use a screen-reader
• The site works for people who can see but not well and may use a screen-reader to assist them (e.g. what is read aloud to them should corresp0nd to what they see on screen)
• The site works if/when JavaScript isn’t available/doesn’t load (rare as this is)
• The site works for deaf/hard-of-hearing people (e.g. videos have captions)

Ok so that’s the basics. But the phrase ‘the site works’ doesn’t always cut it… because things can technically work, but they don’t always make sense e.g. a big thing when building for screen-readers is that we don’t always want the screen-reader to read out content that is hidden off screen – confusingly – sometimes we do want the screen-reader to read out content that is hidden off screen. See… I told you it was difficult :)

An example

Take an example of a hamburger menu that is hidden off-canvas when inactive and slides into view when its active.

• We only want the content of that menu to be read out when it is visible and open because remember not all screen-reader users are blind so we don’t want content read to them which seems like it is coming from nowhere.
• We also want the button (which the user clicks to show/hide that menu) to indicate to a screen-reader that the it toggles the hamburger menu and what state the hamburger menu is.
• We don’t want keyboard users to be able to tab (or up/down arrow) out of the menu when it is active and start tabbing visually hidden links elsewhere on the screen.
• We want people to be able to close the menu by pressing the Esc key on their keyboard and by clicking outside of the hamburger menu itself (that is, if there is any empty screenspace that the menu does not occupy)
• We want users to be returned to the position they were at before they opened the hamburger menu so they don’t get lost/disorientated.
• We want users to have their keyboard focus returned to their previous location before they activated the hamburger menu and we want their focus to go to the first item in the menu when they first activate it.
• We want to make sure the buttons that show/hide the menu are <button>s and not <a> tags to avoid confusion.
• We want the hamburger menu (in some cases) to display if JavaScript fails to load – otherwise it would always be hidden.
• We want the hamburger (and the site in general) to be fully functional and legible if the user zooms in 200% in their browser

That’s a lot of criteria. Showing a hamburger menu can be a few lines of code with jQuery. A click event on a link that toggles a class on the <nav> element and job done; making an accessible hamburger menu is a lot more work.

I’d say the first time you write an accessible JavaScript component like this you are at least doubling the amount of time it would take you to write it.

Lesson 1: Third party testing helps

My client hired a testing (QA) company called ULTRA who were brilliant. They pointed out lots of issues with my build which I had not considered and/or I didn’t realise were issues. After working with ULTRA on this project and testing on my own on other projects, my main takeaway for building accessible sites is: get an expert to test it. Providing you can afford it – of course.

Going through your templates with a screen-reader is beyond tedious and very time consuming. For me personally, I missed a lot of issues because I am not a  regular screen-reader user and I found learning Jaws and VoiceOver very difficult. I have no doubt I was not necessarily using it as a real user would use it so my testing was not really that great.

Lesson 2: Designing for accessibility from the start helps

Most of the big issues in development revolved around:

• colour contrast
• lack of link/button focus

Designers love light grey copy and links that don’t look like links. They hate :focus styles. Real people need to know what part of the page can be clicked/tapped and they need to know which current form input/link/button is currently in focus.

If you can get designers onboard early who will use properly contrasted colours and who think of various link/button styles (and not just a hover state) then 50% of a11y problems go away immediately.

A big factor I employed was to use :focus-ring on this project and in particular the focus-ring polyfill script. Focus-ring can help you to only apply a focus style when it detects that the user navigatig the site with a keyboard – therefore you can style infocus links/buttons for these people and remove focus styles for non-keyboard users. This isn’t ideal but I am yet to meet a designer who *gets* focus styles, but I am also yet to meet a designer who users their keyboard to navigate a website so you can trick them and add in some accessible focus style this way while still making them happy :)

Lesson 3: Having time helps

As I stated earlier, coding accessible websites takes so much extra time. If your client/boss doesn’t give you the time – it isn’t going to happen.

Luckily, for this project, the end-client made everyone aware that this was critical feature so my client had to build the time into the schedule for it and the end-client had to pay for the time.

Summary

Building accessible websites can be difficult. The issues can be hard to see for a developer, time-consuming to fix and more often than not, nobody will thank you for this extra work. You are effective building a website in such a way that everyone can access it without problems or avoidable annoyances and people (usually) notice things that work . Something working is a pretty low barrier because all websites should be built so they are accessible to and work for everyone.

Although, it’s hard – it is very satisifying to create something that you know works for everyone.

For further reading and practical coding tips head to Inclusive Components.

How come?

After working in a couple of different client’s offices for the past 10 months, I am happy to be back in my own space, setting my own hours, surrounded by other freelancers of other disciplines. I’ve done working from home before and it’s a great way to save money but for me, doing it long-term can make me feel very lonely.

A desk in a shared office is a great solution to loneliness – without the downsides of it being too expensive. I have also found in the past that by having your own desk/office, people are more likely to a: take you more seriosusly and b: let you work from there instead of working under their nose in their offices.

Why WeWork?

Whilst I was working in Holborn I visited a friend’s office which so happened to be a WeWork place and I thought this feels like a pretty good environment to work and meet clients. So when my last contract came to an end and I picked up a short contract with a US digital agency I decided I needed an office and I’d check out what was available. Then I saw WeWork had opened a new space a little closer to my home (it’s a 20 minute bike ride which avoids me have to cycle through central London) in Hackney so I decided to pick up a dedicated desk there.

I’ve been here for a week now and I am surrounded by other freelancers including journalists, architects, and translators to name but a few different jobs other people are doing here. There’s free tea and coffee – which makes a change from the last client’s offices where nothing was provided (for fear of them breaking IR35 rules) and there was constant milk-thievery from the fridge.

If you fancy checking out a WeWork office space – here is a referral link.

The core job description of the Lead Developer on this project was:

• Assign tasks to the 3-4 other developers
• Monitor the progress of those tasks and feedback to Project Managers (PMs), Account Managers (AMs) and other non-dev team members
• Try to maintain code-quality e.g. review Pull Requests (PRs), provide feedback to devs and approve/deny PRs
• Merge PRs into main code branch and update servers
• Be the voice of the dev team if there are any disputes about the work e.g. scope creep, unrealistic timelines
• Carry messages from non-dev team members e.g. PMs to the dev team
• Have the final say on coding decisions
• Presenting code demos to non-dev team members
• Keep (Quality Assurance Testers) QAs aware of progress AND finally
• Continue coding as usual

Okay, so, the last task is the hardest. When you are reviewing the PRs of 3-4 other devs towards the end of the sprint, trying to motivate them, trying to communicate their workload and your expected finishing times to PMs whilst trying to manage your own work was very stressful at times.

However, what I did enjoy was having some semblance of control over the final product and being able to say ‘we have coded this like that because of XYZ‘ and presenting that to UX/AM/PMs and generally being believed/respected.

Trying to maintain code quality

It was also incredible difficult to maintain code quality and speed of other developers; I wasn’t really prepared for this. When the deadline is looming and everyone is behind it became impossible to justify spending time enforcing specific coding guidelines like spaces before curly braces in JavaScript or alphabetised CSS rules and minimal nesting in Sass or that elements were exactly 20px apart or that the font size was supposed to be 11px and not 12px.

If I’d have had more time and more foresight I would have ruled with more of an iron fist in the beginning of the project which I feel would have prevented problems with the code further down the line. However, as I joined the team after coding had been started and I was then promoted after some code had already been written (in multiple styles), I did not feel practical to start refactoring every code after I became Lead. Nor was there the time.

Documentation >= code

Code is really important but keeping track of the code, documenting it and letting non-dev people know what’s going on is even more important. At the start, we were pushing, pulling and merging and trying to get our commit messages as good as possible but when you pass that on to a third party (or when you have a gap inbetween finishing the code and releasing it) you realise that you can’t remember exactly what has been changed and why.

Maybe 2 new functions have been added and 1 has been removed but why and what modules/pages etc does it affect? Why was the decision made to make those changes? If you don’t write it down someone will either override your changes later in the project because they don’t understand why a decision has been made or the end-client/non-dev team member will request a change that requires significant work because they do not understand the background.

Managing developers

Same goes for other developers, writing code when you are the sole developer is a very different proposition from writing code that a team of other developers have to understand, extend, delete, or upgrade. And part of the job of the Lead Developer is diplomatically trying to get all developers to appreciate this without causing offence – this was something I did not excel at, at first, and I admit that I found it quite uncomfortable trying to explain to developers  (who had been on the same level as me at the start of the project) that they needed to improve. I like to think this is something I improved as the project wore on but that is for others to decide.

Agency development life

If you don’t work in an agency, it may be hard to understand how/why you have to make  compromises on code quality. Every sprint (i.e. 2 week block of work) is timed and justified by the price paid by the client;  if you slip on these deadlines and start falling behind the agency starts losing money.

It can be hard to justify to an agency that up-front costs are needed that may save costs down the line  (e.g. setting up automated JavaScript testing, or properly planning all modules/components that the system will use before starting to code) because it’s hard to explain this to the end-client who just wants you to start coding and producing work straight away.

In different environments there isn’t always the same time-pressure and more of a focus on quality over speed can be used.

Occasional Tech Lead responsibilities

At times, when the Tech Lead was otherwise unavailable, I was also asked to take on some of their responsibilities for this project which included:

• Estimating development time based upon initial UX wireframes (this was prior to sprint planning with other devs where the timings were refined)
• Reviewing the end-client’s bugs and estimating time required to fix, whether bugs were really bugs or disguised scope creep
• Feeding back to the end-client on bug fixing status

Summary

I was very grateful for the opportunity of stepping up to be a Lead Developer on this project and whilst my next role will only be a Senior Developer and not a Lead I will be looking to be a Lead Developer again as soon as the opportunity arises.

I worked with some great people on this project and while at times the project was a slog, it was often a joy to come into work and spend time working with them.

Those days are gone.

There are too many unanswered questions in responsive web design and a designer sat in isolation cannot answer them all.

Introducing style guide driven design

Responsive websites can be a headache – if you decide to tweak one element that change must be tested and coded on all different screen sizes. However, by starting the designing and building of a website with a style guide (or pattern library) enables designers and developers to collaborate and avoid those headaches.

The style-guide-drive design approach allows a designer to quickly create initial elements, pass them onto the developer who turns them into HTML/CSS. In record speed we have a prototype that feels like a digital product. It’s answered questions of how will it look on an iPhone 6 Plus *and* an iPhone 4 instantly. No more assuming and no more guessing.

How to do it

Instead of creating a full page design, a designer starts with something smaller. Maybe that’s colours and typography and from there transform that into bigger component e.g. a list of products.

Once components start to be produced they can be passed on to a developer who builds them.

Designing and building one website element (e.g. the site’s masthead) at a time and testing across different devices and screen sizes before moving on to the next element (e.g. the site footer) and then fitting them all together to create individual pages at the end of the process is the best way to build a consistent product.

At first, it may feel like this approach is taking longer but the more elements are created the easier it is to build the website as a whole and to add new features.

The benefits

Fitting in with our need to speed-up websites, a style guide can standardise the CSS, keeping it small and quick to load. New members of the dev team can quickly pick-up coding styles; see whether existing modules exist and not waste time coding new elements from scratch.

As project’s evolve, a common approach to on-page problems is to design a unique solution for that specific page but with a style guide approach – a designer can see all the elements together and design as a system.

This way we avoid situations where a website has multiple different buttons styles or multiple heading sizes all of which suit a specific context, but as a whole confuse users who need to see consistency to understand your website’s interface.

Share this article

Using style guides to build better responsive websites: https://t.co/XyuPBr3f8A

— Phil Thompson (@imgiseverything) March 22, 2016

With more and more designs featuring large images and marketing teams demanding multiple third-party tracking scripts everywhere, your website is at risk of loading slowly and putting off customers.

The statistics don’t lie, with kissmetrics.com reporting that 47% of consumers expect a website to load in under 2 seconds and 40% abandon a website that takes over 3 seconds to load.

Pretty sobering stuff.

40% [of people] abandon a website that takes over 3 seconds to load
Source: kissmetrics

A website that takes an age to load is at real risk of its users hitting their back buttons and clicking the next result down in Google. That’s a lost sale, but it could have been easily avoided with some careful planning.

Improving how fast your website loads requires buy-in from the whole team.

• It requires designers to really think about how many different typefaces this designs really needs.
• It requires marketing teams to consider whether Facebook/Twitter share counters are truly worth causing your site to freeze for a second or two while they load their own code.
• It requires developers to create HTML/CSS code that is mobile first and doesn’t include tonnes of third party junk because it makes their lives a little easier.

Using a performance budget

At the start of a project, the team sets a target for the how quickly this site should load. Say if you want it to load in under 5 seconds on mobile and your target audience is (mostly) on 3G, well that means you need to plan accordingly.

Designers now have to make some tough choices because every element on every page has to justify its presence.

If a new feature is needed then something else on the page either needs to be removed or optimised to allow ‘room’ for the new feature.

…a 1 second delay decreases customer satisfaction by 16%
Source: kissmetrics

Combining code assets

Bizarrely, web browsers will often download one large file quicker than several smaller files. So while it may be better for your developers to split their CSS into multiple files for their own ease of management, it could be slowing your site down – unless you combine all those little files into one big one before you use it on your website.

A super simple way to get around this, is for your developers to use a build tool like Grunt or Gulp (yup, they sound made up but, honestly, they’re real things) and automatically combine their smaller JavaScript files (or CSS files) into one big file. While that is happening you could also cut out all the whitespace, comments and uglify the code (once again, I promise, I’m not making these terms up) to reduce that one big file even more.

The rise of flat design

Flat design has taken off in such a big way and a lot of that is down to how much easier it is to design and build websites (and apps) with block colours, less images and simple typography.

If you look at my this site, you will see very few images and you will notice it loads very fast but that approach is not practical for every brand. A lot of the time you need images, big images and lots of them.

If your designer wants to use a carousel you’re potentially asking your customers to download several HUGE images and wait several seconds before they can interact with your site.

With the following 3 tips you could significantly improve your user’s download speeds and reduce their data bills without impacting the quality of your images. That’s win-win – right?

1 Optimise your images in Photoshop/Illustrator

Images are a killer on the web. We all want images to look crisp but what if we could have great looking images at smaller file sizes.

The biggest mistakes is when designers save images at 100% quality, when something like 75% will not reduce appearance but will dramatically reduce file-size.

Here’s how

1. Trigger Save for Web by pressing Command-Option-Alt-s (on Mac)
2. Choose JPEG from the dropdown
3. Set Quality to Very High or 75%
4. Tick the Progressive box
5. Untick the Convert to sRGB box
6. Click Save…
7. Finally, run the saved image through an optimisation app like ImageOptim

Here’s some screenshots of the process

Option one is to save the image with Photoshop’s default Save As feature. You can optimise it in here but it’s not as obvious what you’re getting.

Use mobile-sized images

Mobile phones are only 300px to 600px wide so why are we sending them the same 1600px wide images that a 1920px wide desktop gets?

With HTML’s new <picture> element, we can now send different sized images to differently sized devices. We can even art direct imagery so your website’s mobile version can get a differently proportioned image and not just a scaled down one.

On a recent project with The Economist, there was a need to display different images at different screen sizes – not just to give user’s on mobile a smaller image to download, but because the design was split into differently sized modules with copy laid on top of images and some call to action buttons laid on top of the image too. The images were 600px high (in the largest module) but as the screen got smaller, the images needed to stay the same height but shrink in width.

As the images in question were cover images for short films it wasn’t good enough to crop the image with CSS and risk a face or important part of the image being out of frame so different images were cropped at different sizes.

Here is a sample of the code used:

Here we can see, that by default, a 312px wide by 600px high image is shown. Any browsers without <picture> support (and for whatever reason no JavaScript support) will get this image. Not the end of the world. We can size this with CSS so it’s full screen – which would make it blurred but it’s not a completely terrible fallback.

Then as the screen gets wider a wider image is displayed. Any screen wider than 321px gets a 471px wide image; anything wider than 471px gets a 632px wide image and anything larger than 632px gets the 961px wide image.

(N.B.The sizes 312px, 471px, 632px and 961px are merely the sizes in the design.)

The reason we set the first rule to be 321px is because an iPhone 5 is 320px wide so it’s a reasonable breakpoint, but more importantly – when the site’s gutters (of 10px either side of the image) are considered, a 312px wide image fits in the layout without any distortion. Each time the screen width becomes greater than the current image width we swap it with a wider image so user’s always get a crisp image.

N.B. The picture element is not 100% supported across all browsers (as always, check caniuse.com for details) so you may need some JavaScript to get it to work. That’s where the picturefill script comes in.

3 Use SVGs

SVG may be a new term to a lot of people but it’s likely your design team is already creating vector graphics as part of their process. Create a logo or icon in Illustrator and saving as a .eps or .ai file makes it automatically a vector. So exporting it as an SVG is super easy.

Little things like using SVGs instead of PNGs/JPGs for icons and logos can go a long way to making your website look slicker.

Sick of maintaining 2x or 3x size images for retina devices? Switching to SVG means you don’t have to anymore – an SVG looks crisp on any device and it’s easy to animate too.

A few years ago, developers would place all their icons inside sprites (i.e. one big image containing smaller images) but this is no longer the optimal approach – SVG is!

You can even optimise SVGs by running them through an app like SVGOMG to remove whitespace and shrink the file-size further.

SVG Sprites

Okay, so sprites haven’t gone away, they still make sense except now we have SVG sprites instead of giant PNGs. Inline SVGs make a lot of sense; you can animate them and manipulate them in many ways, but say you have a table with 30 rows and each row has a delete icon and an edit icon. It would be silly to repeat each SVG 30 times.

The solution is to put all your SVGs in one big SVG file (e.g. a sprite) as <symbol>s and reference your SVG like so:

That’s great but it doesn’t allow browsers to cache the sprite (and therefore have quicker repeated views of your website) and it adds a lot of bloat to the HTML.

Don’t fear help is on the way, because you can simply reference an external SVG file instead of the one inline in HTML. You’d simply edit the <use>‘s xlink:href attribute value to have a full href value like /assets/path/to/sprite.svg#icon-close instead of #icon-close.

External SVG sprites aren’t 100% supported (big surprise) so you may need some JavaScript (again) in the form of a script called SVG4Everybody to get it working in all the (currently) modern browsers.

Summary

Those fixes can be made today and your website’s visitors (users, customers – whatever you call them) will be happier if you use them on your site.

Retweet this article

3 speedy tips to optimise your web images https://t.co/OgdNkO1bcC #front-end #images #optimisation #performance via @imgiseverything

— Phil Thompson (@imgiseverything) March 7, 2016

At the point of writing this, I have been freelance (full-time) for a little under 8.5 years. Initially I fell into freelancing but the reasons, 8.5 years ago, for pursuing it were down to limited opportunities (for me, as 24 year old web developer) to grow professionally. By going freelance, I was able to work for international brands via numerous different digital agencies on a variety of projects (and got paid more money too) than I would have done as a full-time middle-weight web developer (with only 3 years of industry experience).

Since moving to London (in July 2015), I’ve continued to freelance, but I have noticed that here, compared to elsewhere in the UK, there are lots of big company headquarters with well known digital teams and seemingly lots of job openings on those teams. My thought process 8.5 years ago was that to further my career it made sense to be freelance; whereas my current thought process is that perhaps working in one of these corporate headquarters as a permie would be equally career-furthering.

So I investigated this avenue and, shock horror, applied for some permanent roles.

However…

From my experience of applying and interviewing, it seems being what I call a Front-end Developer and what Brad Frost calls a Front-end Designer isn’t as sought after in the job world here in London.

I’d argue there’s plenty of companies needing people with a specific skill-set that straddles design, UX and dev but they all seem to be recruiting for people with advanced JavaScript skills as if their HTML and CSS is an after-thought (after all it can/will be built with Bootstrap) and anything and everything has to be built as a one-page app with React/Angular – with no thought as to whether that is the best solution for the project.

A tale of a recent interview

Being freelance means that I have avoided job interview hell for nearly a decade. Amazing. And being freelance means clients usually hire you based upon a recommendation or by viewing your portfolio – sometimes that is it and sometimes you may be asked to come in for a chat too. A chat. Easy. However, I did interview for a recent full-time position and it did not go great…

The interview was a 4 stage process – I’d argue it was 5 steps, because the first step was me trying to get the in-house recruiter to tell me what the salary was (I failed to get that information after asking several times), then you apply via CV/covering letter, then it’s a telephone interview, then a 2 hour (in your own time) test, which would be followed by a pair programming session and then a final interview in person. Overkill for sure.

Interview stage 1 – the telephone interview

In the telephone interview with two developers, I was thoroughly examined on my knowledge and asked to describe all the different HTTP methods like GET, PUT, POST, asked what a closure was in JavaScript. Not easy stuff on the spot. For someone who hates making phone calls.

On the job, I will Google answers a lot; not sure of something – Google it. There’s so many facets to this job that you can’t keep it in your head all the time. My Google search history is a litany of misspelt WordPress function names – it’s gross.

I managed to pass this stage. Somewhat surprisingly.

Interview stage 2 – the 2 hour coding test

The next step was the two hour coding test; it wasn’t too bad – the brief was to create a module/component grabbing a list of content from the company’s API that would sit on the site; you were to take only 2 hours and the resulting product was something that you should be proud to release onto the working website. In my opinion, 2 hours is not enough time for this – it’s enough time to get something working but not enough time for you to proudly deploy to a website.

Interview stage 3

A few days later I was emailed to say I wouldn’t be progressing to the next stage of the process, when I asked for feedback I was told my paired programming test showed that I wasn’t of a high enough standard for the job, when I explained I hadn’t done the paired programming test, and asked (nicely) if I could have some feedback on my test I got no response.

Pretty demoralising stuff.

So what’s my point?

I know it’s hard to find new developers and trust that they will come in and be able to work to your team’s high standards. A lot of applicants for these kind of jobs have none of the requisite skills – so I totally get that a process is needed and rejection has to happen and that has to be based on some criteria. If you get 100s of applicants and 95 of them don’t know basic HTML then they need to be whittled out. But, I think my pride was hurt at being rejected because I feel I’ve shown enough in my career that I can go into any team and adapt to their coding style and learn new methods quickly.

I’m not sure what the right solution is for interviewing/finding new developers but I do think I have a lot to offer (and so do many like me) and the current hiring process doesn’t recognise me as a good candidate.

Further reading

If you liked Brad and Zach’s posts then you may like these great articles too:

• Developers Who Can Build Things from Scratch by Aaron Stannard
• Inside Automattic’s remote hiring process by Dave Martin

Last year, I moved to Cheltenham and spent the year working for digital agencies in both Birmingham and Bristol (Cheltenham is halfway between both y’see). So I have some experience in setting up in a new city.

But first, let me address (by which I mean rant a little) an issue about moving cities. Upon telling friends/family that you are relocating, their first response is often ‘it is a good job you can work from home/anywhere‘. This isn’t really true of all web developers (some yes, but certainly not all).

because…

In my role, companies often expect me to work in their offices and quite often, that is best for the project – you’re near the designer and/or UX people (hopefully) and you can quickly discuss ideas; with responsive web design, this is crucial because sometimes designs created in Photoshop/Illustrator/Sketch don’t translate well to the web… as much as we hope they will. My point, is that it is very important that where you live is close to the (type of) companies you wish to work for. In my experience, companies based in Bristol want to hire Bristol-based web developers and companies in London want to hire people based in/near London.

which brings me to my next point…

London is huge

In the past three months, I have worked in Camden, Canary Wharf, Shoreditch and in central London. I have rented a desk in a shared office in Shoreditch and have worked onsite in those other locations. I have gone to meetings (to try and secure work) in those places too and it takes an age to get there and back. My partner and I decided to look for a home near Finsbury Park station as that was good for her work as well as mine – meaning I am only 30 mins away from Shoreditch, Clerkenwell and central London where I’d guessed all my work would come from.

And that’s fine, most work does seem to come from those places but then, it turns out there is a lot of work to be found in Canary Wharf and that seems to take aaaages to travel to… and it is not a fun journey. While I worked in Manchester, I could easily pop into a client’s offices for a meeting across town because the city centre is so compact but London is so vast that a meeting on the other side of the city can wipe out your schedule for the day – or, at the very least, the afternoon.

The work is different

I had presumed, as in Bristol, Birmingham and Manchester that I would work for digital agencies. Before I got here, I collated a list of the agencies I wanted to work with here in London and the plan was to contact them, set-up meetings and secure some contracts but when I got here I quickly realised that there seemed to be more jobs working directly with clients in their in-house digital departments.

Since arriving in London, I have worked directly with Topshop, Viacom and The Economist. Work that I could not have hoped to achieve whilst living in Manchester mainly because large commercial companies don’t tend to be located outside of London – some are but most aren’t and when there’s 1000s of businesses all located in the same city it is a lot easier to find work.

In this slightly different marketplace, you are a contractor as opposed to a freelancer and other differences seems to be that the day-rates seem to be higher and often the client pays their invoices in anywhere from 7 days to 14 days after invoicing – which is rare if you work with agencies.

Work is both easier and harder to find

A slight contradiction here, because there is lots of work; in digital agencies, in medium-sized companies, in large companies, in government organisations and once you tap into that it’s easy to find work and go from job to job but it’s hard to tap in to because most of the recruiting of contractors seems to be done via recruitment consultants and actually finding out who the right person to speak to at a specific organisation can be quite difficult.

Want to contract at the BBC? Great there’s loads of roles going but unless you know the specific person recruiting for that role you’re not going to get very far – you won’t even know a role is available let alone be able to apply for it and it’s like that for a lot of organisations.

Angular/React/MVC libraries

There seems to be a lot of work for people with knowledge of Angular and other associated JavaScript libraries all across London with some eye watering day rates on offer too. I’m not 100% sure why so many organisations are making what should be traditional websites (i.e. not web apps) that don’t really benefit from a framework like Angular or React but they are and they’re willing to pay a fortune for the pleasure.

However, after a year, my partner’s work contract came to an end. So we decided to start a new adventure and move to London and I will be starting all over again by targeting work with London agencies and start-ups.

Why London?

Bristol, Birmingham, Manchester and many other UK cities have flourishing agency scenes with an abundance of front-end work for freelancers but they have less freelance opportunities inside bigger companies and/or smaller start-ups whereas London offers opportunities in all types of organisations. Something which is very exciting.

Similarly to when I first moved to the South West, the first month or two of this move will be spent making new connections, going out and meeting people and trying to prove my skills to people I’ve never met before – whilst doing remote jobs for existing clients and trying to find a nice deskspace.

If you’re a front-end developer in London (or looking to hire one) please say hello via twitter @imgiseverything.

This post was first published 1st January 2009 but has been updated 14th May 2015.

Your parents and friends might be telling you that your lack of employment is down to the current economy but here’s the real truth; the truth that your lecturers and parents don’t know: for the vast majority of educational courses, everything you’re taught is not very useful in a commercial environment and regardless of the economy, that first job can be bloody difficult to land.

Web agencies want, no, demand junior developers to come in and to be able to start work immediately and most graduates can’t do that. Of course, a junior developer will learn on the job and constantly improve and with the help of a good middleweight or senior developers above them, they’ll improve significantly more but they need to have the basics down first.

The basics

Every agency is different but the basic tasks for a junior web developer could consist of:

• buying domain names and updating/setting-up DNS on those domains
• setting up a local web server with XAMPP or MAMP or a more senior dev may have set-up Grunt/Gulp tasks to do this
• building HTML/CSS templates from a Photoshop/Illustrator/Sketch design
• backing up files in version control (GIT but maybe SVN if you’re unlucky)
• installing/setting up a new website with the agency’s in-house CMS or open source varieties like WordPress/Drupal/ExpressionEngine etc
• keeping track of time and learning how long it takes to do key tasks
• quickly explaining your previous day’s work and current day’s plans at the morning stand-up meeting

Code Computerlove have published a series of articles where key people in their team detail what they do on a daily basis:

• Day in the life of a (back-end) Web Developer
• A day in the life of a Front-end Web Developer

When I went to university to study Computer Science, I certainly didn’t learn any of those basic skills in lectures or in projects. Some, I picked up in a placement year, where I worked as web designer for the local council, but for the most part I picked those skills up on my own in my spare time and so did everyone else in this field – we’re all self-taught by blogs, books and podcasts.

How I got my first job

In my first year at uni (2001–02), the lecturer in charge of industrial placements told us that there were ‘no jobs in web design/development‘, this made my heart sink. However, a year later when the work placements started to be advertised on the university notice boards at least half were for web based jobs. I decided then and there that I wanted to be a web developer and that such a thing was actually possible. Sadly, every placement I applied for wanted me to have experience which I didn’t have.

After six months of trying to get a placement which involved lots of (failed) interviews, I realised I needed some hands-on experience to get any sort of credibility with interviewers, so I started to maintain the website (for free) of the charity that my girlfriend’s mother worked for. My CV now had some experience and a URL on it. In interviews I talked about it to prove I had relevant experience, not to mention initiative and eventually with only one week before term was due to restart I got that work placement.

Fast forward to my final year (2004–05), and in January/March, I sent out a mail merge to around 30 different Manchester, Cheshire and nearby web agencies informing them of who I was and that I was graduating in six months. Nothing much happened; I might have got three emails all of which said, thanks but they weren’t interested just now. In hindsight, I would not advise this blanket approach. A better approach is to research 3–5 places you’d like to work then target them specifically. A mail-merge letter comes off as a bit insulting which was something I did not appreciate when I was looking for my first job10+ years ago.

Closer to graduation, I put my CV online with large job websites (the kid you see advertised on TV) and started applying for jobs – still nothing. With one month to graduation, I put my CV on local digital industry website, Manchester Digital, and I received an email which eventually lead to my first job at JJB Sports in their Marketing department. By spreading myself out and trying different techniques I found one that actually worked!

How you can get your first job

I would consider not hiring someone who:

• has a hotmail/yahoo email address (tip: why wouldn’t you have your own domain as a wannabe developer?)
• doesn’t have a web presence e.g. a website/blog/online portfolio/github (or equivalent) or a twitter account
• has no experience whatsoever

The last point is a big one. Experience is everything in this industry. You can get very far very quickly with no qualifications, if, that is, you have the requisite skills. A good education is brilliant but if the person in competition with you for a job has a years experience on their CV and you only have a degree then the experienced person looks better (in most cases).

You have to get your name out there, so apply for jobs, talk on twitter, try to network, try to learn some important people’s names. Everyone in this industry knows everyone else therefore, if you apply to agency X and don’t get the job but you impress someone then an employee working at agency X might tell their friend working at agency Y about you.

Networking

Ah that dreaded word. Most (but definitely not all) developers are introverts and the thought of networking, strikes fear into them (it certainly does for me). However, there is a difference between traditional networking events (think walking into a large hall with people in suits and starting conversations with these people, who you don’t know, about work stuff) and merely getting to know people in the industry a little through Twitter, email, or having a casual chat at a design/dev talk like Glug.

Getting the experience

If you have no experience and therefore no commercial references, you should make it your mission to obtain some. If I were in that situation (again) I’d be looking to:

• set up my own website/blog
• set up a website for a friend’s/relative’s small business (and get paid for it)
• work for free* (or low pay) in a local web agency – making tea if I had to
• take a lower paid (than expected) job as web developer
• work for a local web agency – not as a web dev but maybe in a different role and work my way up
• read books/blogs and practice web development as much as possible
• make some money while waiting for that dream web development job

If you apply for a job with no commercial experience, but you have built your own website then you’ll instantly look much better than your competitor who has no experience and no website.

* Point of note about working for free. Working for free to get experience is a good idea but don’t do it for too long. 1-2 weeks is fine. If an agency wants you to work for 1-3 months for no pay then they are most likely taking advantage of you and the chances are there is another agency somewhere willing to pay you to do the same job.

Summary

All web agencies are looking for people, and whilst it may be true that some are putting a hold on hiring right now due to the current financial situation, a lot more agencies are crying out for good junior web developers but they just can’t find them. Your mission is to seek out these people and let them know you exist and how good you are. You’ll save them time and money on advertising for people and you’ll save them from have to deal with recruitment agencies because they loathe that exercise.

By no means am I an expert on employment; these are just my experiences and advice. You may be a student on a fantastic university/college course teaching you everything you need to know – not all courses are crap but sadly, a lot of them are.

If you’ve got an experience or some advice on getting that first job that you’d like to share; I’d love to hear it.