Nicole Sullivan on the value of optimising code

Enter the code generate100 at the checkout by midnight EST today to get $100 off your ticket to Generate New York!

Nicole Sullivan, the creator of Object-Oriented CSS, is one of the speakers at net magazine's upcoming Generate New York conference, which will take place Friday, 20 June.

Settling in front of her uncooperative Mac, she smiles broadly as we ask about her Twitter handle and web page name, Stubbornella.

With her webcam finally cooperating, she says: "That was a gift from a friend, for my birthday maybe 15 years ago." There is a certain lilting emphasis on the word 'gift'. "I wasn’t very much of a nerd at the time. I looked it and thought, 'Stubbornella? I'll take that as a compliment and take it to mean persistent - not stubborn.' I never thought I would start a speaking career and run a business under that name."

And thus far, it's been quite a career: one carved out at the astrophysics end of the CSS business. Sullivan spends her life helping big corporations like Facebook shave seconds off their sites' performance.

Explaining her fascination with hunting for tiny efficiencies in code, Sullivan says: "Hard problems get even harder when you add scale. It makes them all the more interesting. The tiniest decisions you make may have a big impact: things like whether you use div.classname or just .classname can make a difference of several KB. You don’t think that's much, but when you're serving [the file] to billions of people, those little differences are very important."

The fruit of that research is a list of web products that includes Object Orientated CSS (OOCSS), CSS Lint, image-optimisation tool Smush.it - and the delightfully Wallace-and-Gromit-sounding Type-o-matic, which counts fonts on a page. Sullivan also organises CSSConf. As she puts it, she is "crazy busy".

Last carpenter in Paris

Despite her long list of accomplishments, Sullivan didn't start out as a developer. "I had an undergraduate degree in economics and the jobs you can get with that are pretty terrible," she says. "So I decided to go and become a carpenter. I called everyone in the newspaper and said, 'Hey, give me a chance!'"

Sullivan’s carpentry career was cut short when she hurt her hands. "I lost sensation in my fingers, and the doctors said, 'You’re not that big - you really need to find something else to do.'"

When in France, that something else hove into view. "I had the opportunity to move to Paris, and I took it. Technically, I think I was [a legal immigrant], because I did leave every six months and I didn't work, [but] I had no papers; I had no documentation.

"In my boredom, I started reading W3C specifications. I read XML Schema first - which I didn't really understand - and then the CSS specification. [That sounded more interesting], but I thought it was describing how CSS actually worked. At that phase - it was 2002 - the specification was just a pipe dream."

Having accidentally enrolled in an engineering school - "My French was so bad, I thought I was signing up for a little night class in Java!" - Sullivan began working for French agency FullSIX. "They dealt with some of the biggest websites in Europe - things like the train system and big hotel networks - and built sites for most of the major cellphone providers. I got interested in scale and ended up managing the team."

Dance Dance Revolution

Sullivan later moved back to the US and began working for Yahoo's web performance team, where she began researching best practices - at which point, chance took a hand in her career once more.

"I got laid off," she explains. "At the time I was very upset. I had done a lot of work to deploy their performance-measurement system worldwide and felt like I wasn't quite done with it. But it turned out to be fantastic, as it allowed me time to polish up OOCSS."

The time off also enabled Sullivan to begin a pivotal parallel career as a conference speaker - something that jokingly attributes to her prowess at classic rhythm-based arcade games.

"I got a speaking part at Web Directions North because I'd played Dance Dance Revolution with [conference co-founder] John Allsopp in Japan 10 years earlier," she says. "I feel that life is a lot of random things: you have this grand plan and then you play Dance Dance Revolution, and it changes everything!"

Chance also played its part in that crucial conference talk. "I was going to do a basic overview of performance, but I was also thinking about what really mattered to me," says Sullivan. "The organisers were like, 'Hey, why don’t you do that tomorrow?' So I stayed up all night doing the OOCSS slides, and putting those ideas into words as opposed to just code. It was crazy after that. The slide show has near to half a million views."

So what’s the deal with OOCSS? "It's about applying engineering best practices when we're writing CSS," explains Sullivan. "Those best practices really do hold true in the CSS world. That said, I didn’t come up with OOCSS through pure theory. What I did was try building a whole lot of sites and making mistakes, and over time I kept eliminating techniques that kept failing."

"One time, I named all of my class names very presentationally; stuff like 'Big Red Heading'," she continues. When she came back to the same company on a new contract, Sullivan found, to her horror, that everyone had a translation chart pinned to their workspace walls. "It said things like, 'Big Red Heading actually gives you a tiny blue heading'. I thought, 'I’ll never do that again,'"

"Basically, [OOCSS is about finding a] good, solid core that works and is maintainable," she says. "It's about making things that are easier to understand."

Practical benefits

Making life easier for developers is one thing, but clients care about their bottom lines. What practical advantages does OOCSS hold?

"Lots of companies have me come and work with them because of the performance benefits," says Sullivan. "I had a client who had about 100,000 lines of CSS. We were able to rewrite it in about 1,500, so [there can be] huge differences. But what people really get out of it is their teams work better together. They start delivering features faster."

Sullivan compares this approach to coding to building models out of Lego. "You don’t know how the Lego bricks are formed; you just stack them on top of each other. And though you don't realise it, you're learning what makes a good component, too."

CSS isn't the only part of your code that you can optimise. But, as Sullivan points out, it’s a good place to start, since nothing is rendered until it is loaded and parsed.

"It's [responsible for] that blank white screen before the page even shows up," she says. "That's a really important thing to eliminate, because it changes user behaviour. Leave users waiting too long and it makes a bad first impression. People tend to shop less and friend less."

The gum ball wall

So how do you diagnose where the problems with a site actually lie? "It's really difficult, because rendering is mixed in with all the other things that a browser does," admits Sullivan. "It may seem like your JavaScript is slow, but it could be that you're causing a bunch of repaints of your entire page. Or you may have so many unused selectors that your browser has to parse through a bunch of extra stuff that you don't need it to worry about. CSS performance gets hidden in the cracks around other problems."

To troubleshoot her clients' sites, Sullivan uses Chrome DevTools in conjunction with the grep command-line utility. "I grep my style sheets for different property-value pairs to see how many times they’re used," she says. "I had a client that had margin and padding declarations used ten thousand times! Three or four hundred is more typical, but that’s still too high."

But surely Sass is the magic wand to wave over all our styling problems? "You’d think so. But if you apply Sass without any architecture, you wind up with a crazy mess, like you would if you did any language with no architecture."

As an analogy, Sullivan points to the infamous Bubblegum Alley, a tourist landmark in San Luis Obispo, California, that she has visited - although not contributed to.

"Everyone that has passed by sticks their gum on the wall. It's disgusting!" she says. "If you write your CSS like [she mimics thumbing wads of gum onto a wall], you wind up with code that looks like the gum ball wall - and at that point, teams get stuck."

Coming full circle

To conclude the interview, we couldn't resist asking Sullivan if there are any parallels between CSS and carpentry.

"You know, I was thinking about doing a talk about the things I learned from being a carpenter," she says. "If you build a roof, you have to stand on it the next day. If you've made some horrible mistake, you might take a ride off it, and that changes your perception of [what it means to do] quality work."

"At the other end of the scale, it makes you think about the right level of quality. When you're using class names, does it matter if they're perfectly semantic? Users of the site don't care about them. There are no accessibility devices that read out class names to people on screen readers. It turns out that the primary consumers of my class names are other developers, and that makes it easier to decide on the quality I need."

As Sullivan points out, you only need to make it obvious what each class is for, so that other developers can maintain the code over time. Anything else is overkill. At this point, she breaks into another huge smile. "Once, I was framing a basement. I was cutting the wood to be so precise, and being really meticulous about it. One of the carpenters turned to me and said: 'Nicole, you're not building a fucking piano!'"

Enter the code generate100 at the checkout by midnight EST today, 13 June, to get $100 off your ticket to Generate New York!

This article originally appeared in net magazine issue 254 - on sale now!