Harry Roberts on why pragmatism trumps perfectionism

Harry Roberts does a lot of speaking and a lot of teaching. He's been working for himself for more than a year; before that he spent three years as a senior developer for Sky.

But he's best known as a CSS guru – he flies under the Twitter handle of @csswizardry. Here he shares the lessons he's learned so far.

But first of all, who is Harry? "I'm a consultant frontend developer and frontend architect," he says. "I tend to work very short stints with clients all over the world, helping people guild their UI architecture and helping teams work better together on long-running products.

So, why has he dedicated himself so assiduously to Cascading Style Sheets? "CSS is still at a point where everything is open to be solved. Sites are getting bigger and more complex, and there's a move towards more product-led builds as opposed to just websites.

"What drives me is finding the solutions to these things with CSS, at scale. That's why I've stuck with CSS. Even for such a limited language, there's so much that you can do with it and so much that needs to be done to it. That's why I've gone down the large-scale sites and applications route. That's where the fun is for me."

Roberts got into the web "by accident". Growing up, he planned to become an architect, and spent his afternoons working at a local print supplies shop, surrounded by architects and their plans.

Around that time he and a friend started doing design work for local firms – making, in his words, terrible flyers, logos and adverts. "I realised we should get an online portfolio. At that point I concluded I was a much better developer than designer," he smiles.

As such, Roberts had no formal training, finding himself excited enough by web development to fully immerse himself in it. "Being self-taught is a gift and a curse. It's a gift because I can learn things at my own pace; I could learn what I wanted to, when I wanted to.

"One downside is that I haven't been formally introduced to programming languages. I don't know any JavaScript. I haven't been in an environment where I was shown what I needed to learn. I just picked things up and ran with them."

Peeking under the hood

"For me, the fun is solving problems and tinkering with things, " Roberts explains. "At the moment, that happens to be in the form of CSS. I'm the sort of person that says, 'If it ain't broke, break it and see how it works'. Anything that has inner workings, I have to tinker with and reverse-engineer. I have a fascination with everything. I probably account for half of Wikipedia's monthly throughput."

So, does Roberts habitually right-click and 'view source' as he hops around the internet? "I used to be terrible for that when I was first starting out, " he says. "It's what pushes the web forward and I wouldn't be a web developer today if I couldn't view source. It's a great way to learn."

However, he's trying to kick the habit, as it can become tiring. "I wonder if Gordon Ramsay goes out and can eat a meal without passing judgement?" he muses. "Can he stop thinking about the process behind it? Can it be just about food?"

These days, Roberts has learnt to take a more detached view. "One thing I've come to realise is that, as a user, I don't care what someone's code is like. And, one thing I learned quickly in a product environment is: pragmatism trumps perfectionism." A site that has ugly code, but still works, is infinitely more valuable than a site with lovely code that doesn't work.

As an example, Roberts points people to the source code for Facebook and Google.com. "It's a real mess, " he smiles. "But those sites handle millions of people every day, and the users don't care … Those sites are highly performant.

"As a developer working on one of those companies, sure, it would be important to me. But, in the last few years, I've stopped my voyeuristic peeking under the hood. It's just not important."

Spotlight on Sass

Naturally, however, it's imperative that people care a lot about source code when they're one of the developers tasked with building and maintaining a site. One area Roberts feels still needs a little more diligence is working with preprocessors.

"A problem, " Roberts explains "is that Sass can be something of a black box. You put things into it and often people ignore what comes out the other end. What you have to remember is, 'garbage in, garbage out'." He stresses that it's hugely important to be aware of the fact that what preprocessors spit out is what ends up on people's machines.

Sass, of course, has legions of fans, but also a healthy group of detractors. Last issue (261), for example, John Allsopp cautioned against preprocessors. He felt that although they might make developers' live easier in the short term, in so doing, they add complexity that may come back to bite in the future.

"I had a heated debate with John [Allsopp] at a conference recently, " Roberts recalls. "His stance was: 'Don't use Sass' , whereas mine was, 'No – if you're bad at Sass, then don't use Sass'."

In Roberts' view, it's all about context. "Sass, " he explains, "has the potential to be bad if used incorrectly. It's like saying guns are bad. Are guns are bad? Not if you're hunting. Are knives bad? Not if you need to chop some vegetables …"

He suggests being cautious about when you use Sass, and approaching it as a nimble complement to what you already know. "Don't use a tool just because you've read an article that says it's cool. Look at the problems you have and find out what's going to solve them. Don't get me wrong – I'm a massive fan of Sass, but it's not a magic bullet."

The business

Despite his relatively tender age (he's this year's proud owner of net's Young Developer of the Year award), Roberts is already playing in the big league when in comes to clients, with a portfolio that boasts the likes of the BBC, NHS, Booking.com and the Financial Times.

"It can be daunting, " he says of those times he's found himself consulting with such large and respected organisations. "I've worked with people who I look to as fantastic developers. Going in and telling those guys how to build better sites makes for an interesting dynamic."

So, what sorts of problems is he brought in to solve – what, in other words, do firms do that result in sites that are slow?

"Actually, the problems usually come from the business level. A lot of companies don't realise that performance is a business problem, not just a dev one. There's only so much a developer can do to improve the performance of a poor feature decision."

Often Roberts finds a company might not understand performance. Rather it takes the view that the site's speed, operation and efficiency are the developers' problems to solve. "You can't work like that, " Roberts emphasises.

"Large web pages with extraneous features lead to bloated code, and those problems tend to come from the business. A lot of the work I do is pushing back on superfluous stuff … saying 'the user won't miss this' , but they will care that they're now using a slow website'."

Reflections

Roberts cites Conway's Law. The adage is named after programmer Melvin Conway who, in 1968, opined that 'organisations which design systems … produce designs which are copies of the communications structures of those organisations'. Essentially, software interface structures reflect the social structures of the organisations that produce them.

"For me, Roberts says, "understanding the business is very important in understanding how and why a product was put together. Before I go into a client, I try and get a 30,000ft overview of the organisation. If I can, I'll have a Skype call with a couple of developers and somebody above them, to get a view of their problems. At the end of the day, I exist to solve business problems. It's all about cost savings and efficiencies."

With this overview established, Roberts dives into the code. And the code base can be big, he says, explaining that he spends a lot of time poring over the code. When he can't get on-site, he'll do review code remotely, although this does have its inherent difficulties.

"I could look at some source and think 'this is ridiculous, why has the developer done this?' But I could sit with the developer for five minutes and they could explain that – for whatever reason – they've got to support a particular device.

"Suddenly you realise this isn't a bad developer, this is is a good developer working in a tough environment. So looking at code is very political and business-oriented."

When it comes to the nuts and bolts of code dissection, Roberts swears by Parker. Beyond that, he recommends CSS Lint by Nicole Sullivan and Chrome's Dev Tools.

Built to last

Along with making sites run quickly and efficiently, another big concern for Roberts is building sites that are sustainable – ones that last, and ones that can be maintained.

"I work in companies where sites could already be three years old and might need to last for another eight, " he says. "The key is simplicity. Reduce the number of moving parts – if you can get rid of it, do so. There's no framework or language that's going to make your site last 20 years, as if by magic."

A lot of clients are prone to falling under the spell of the latest, greatest and shiniest new technologies, he explains. For example, they may want to use a new technology and, to ensure compatibility with old browsers, they plan to build fallbacks.

"You've instantly given yourself two lots of work. You've got new stuff for new browsers and old stuff for old browsers. The thing is, the old stuff works everywhere. So, if you need [the site] to last a long time – and this is a very unsexy stance to take – just use the thing that will work everywhere."

A definition

Sustainability does, however, mean different things in different
contexts. Roberts points out, if you're working in an agency where staff turnover is likely to be high, sustainable might just involve writing code that can be worked on by other people when you're gone.

"Elsewhere, sustainable might involve thinking about how long a site can be left running before we need to start sharding databases, for example. It's also about scaling the platform. It's about building simply, not being overly ambitious, and not showing off."

The cutting edge, Roberts admits, can be a risky place to be if you want to build sites that have a huge reach that nets a lot of money for the business. At the end of the day, simplicity is always the answer.

Words: Martin Cooper

This interview previously appeared in net magazine.

Like this? Read these!

• Outstanding examples of CSS
• How to build an app: try these great tutorials
• Useful and inspiring flyer templates