Category Archives: Work

What I love about working at Twitter

I’ve never been the one with the fancy words and clever insights. My writing is either hastily-scribbled thoughts to myself, or simple language and simple meaning to convey a message. If you’re looking for the poetic literature on this subject, I recommend my colleague Jeremy’s Medium post, “Why I Love Twitter“.

Twitter is the first company I’ve worked for whose product I use every day. I’ve never had that before, and I never realised how significant that is, before this job. It’s incredibly satisfying to work on a website you depend on yourself. It becomes a labour of love.

The Twitter site always appears to be very simple. There’s reliably someone on HackerNews each week claiming they could build it in a day, and before I came here, that could well have been me. Since joining, I’ve learned of the tremendous complexity that underlies essential services, like Twitter, Facebook and Google, to keep them running 24/7. Why is 24/7 just hours and days? It’s not enough. Every second of every year, you expect Twitter to be there when you ask for it.

And at scale! We serve hundreds of millions of users! Our Google Analytics numbers are just ridiculous to browse through. (I’ve wasted hours in those dashboards – hours). I love working at scale. After 16 years building websites, I’ve learned that the most fun work is realtime, scale, and user-focused. The kids say they love Machine Learning and Big Data these days, but they’re honestly missing out. I love the breakneck pace of developing for users, the tension of stability, and the challenges of scale.

When I read the news (BBC), nearly every story mentions Twitter or a Tweet. Everything. Politicians making announcements, or campaigning, or discussing foreign affairs. Celebrities doing whatever it is they do. Every single obituary. It’s the perfect way to get a short soundbite for a story. It’s the source of news on the ground. It’s a direct line to the people who matter. I love that we have this impact.

Nearly everyone, whether they use it or not, has an opinion on Twitter. You should do this, you should do that. Sometimes we agree, and there’s a technical constraint. Sometimes we agree, and we just haven’t got time for that yet. Sometimes we agree and it gets done! I love being on the inside and being able to sway those priorities.

This is, after all, a product I use every day.

For me, one of the perks of the job is little tweaks. I’m not a coder any more, I’m just a manager. But that doesn’t stop me making the *slightest* tweak here, the *slightest* tweak there. Just when I’ve got a free afternoon. Maybe I’ll speed up the page load. Maybe I’ll add another column. It all gets approved by others. There’s nothing underhand. And it’s all small, but I love that power.

When I joined Twitter, I felt incredibly unworthy. I assumed the coders there would be gods, writing these books and building these sites. What I found were humans. Ok, one or two are the exceptional kind, who could rebuild your templating engine in C over the weekend just for kicks, saving the company millions of dollars. But there are also many wonderfully talented normal humans doing great work. And I was proud to join them.

It’s been more than five years since I joined, but the company, the work, the job, the product, the environment, the world. It all keeps changing. A few years ago everyone said we were doomed. Then they said we were amazing. And now they say we’re doomed again. The faces at the top sometimes change. Sometimes often. But the team I work with, the team I build and run. This team is a constant. They’re always doing the best they can to serve our users. To keep the site running, the service alive. To make it better every day.

That is what I love about working at Twitter.


Working at Twitter is something of a luxury. And I don’t mean the snacks.

I work on, the main website for desktop browsers. My everyday tools are JavaScript and Ruby. Which surprises me, since every other job has heavily involved HTML and CSS.

At Twitter, this has been a very minor consideration. Why? Because our designers handle the HTML and CSS. I work with Mark Otto, who has designed a non-trivial percentage of the Internet through his Bootstrap library. He knows his stuff, but is still happy to learn or adjust if needed, to make the best result. It works very well.

Now, a lot of you are thinking “so what?” and “this is normal”. Maybe for you, this is.

But I’ve spent the majority of my career working at digital advertising agencies. There, the “creatives”, who are all “Art Directors” by rank, throw a Photoshop PSD over the wall and forget about the rest of the process. They don’t care what CSS is, they don’t care what HTML tags are.

I once worked with an Art Director on a style guide. I thought this would be a really simple idea. Not so. After carefully explaining the heading tags, H1 through H6, I turn up the next day to find the guide complete: heading tags H1 through H6, paragraph tags P1 through P6 and table tags T1 through T6.

I’ve never been able to understand why a web designer wouldn’t be interested in learning the basics of the material they work with. It is, quite literally, the media. If they were print designers, I would expect them to know about paper. Instead they live in Photoshop, on a Mac, and know nothing about the world outside.

However, thinking about it, I realise that I’ve been wrong to blame them.

At a digital agency, the “creative”‘s job is not to design.

Their job is to satisfy the client.

And the client, invariably, is impossible. They want three different executions of an idea. By tomorrow. Even though they’ve already decided what they want. Even though they already have a brand guide that limits any hope of creative spark. And no budget.

Oh, and the site has to be completely different to anything else. And viral. And have video.

Never will the client care about accessibility, semantic markup, reusability, comments or sanity. Except perhaps to check a box.

At Twitter our designers can take the time to iterate on new features with their Product Managers, and engineers too, until they’re really happy they’ve got it right.

At a digital agency, designers work all night to complete three page designs they know will be useless, because they haven’t been properly briefed. There’s no time to mock up designs in CSS, or test the interaction model on an iPhone. It’s an impossible job.

But they do these things. Clients get happy, sites gets churned out, money is made.

It’s two different worlds, with different requirements and different results.

For now, I think I prefer it on this side.

Context switching

I’m at work.

And I know what you’re thinking.


Logs onto his own blog when he should be working?! When are we going to get 150 character tweets, if the developers all spend their days on personal blogs?

I hear you.

But I’m getting old. With old age comes a certain amount of experience, a certain amount of stiffness in the bones, a certain grey-haired softly-spoken cynicism of newfangled inventions.

But as far as coding goes, the biggest effect is context switch pain.

I feel sure that when I was twenty I could happily flip between six different projects, in seven different languages, for eight different clients. I could jump contexts like a frog that dodges traffic in an old computer game.

Now I’m over a hundred, I find this harder. Come over and ask me about your project, and my thought processes go like this:
– what?
– what’s happening?
– try to remember current task
– who is this?
– does it look urgent?
– if I ignore them any longer, will they just go away?
– save
– remove headphones
– try to work out what I spoke with them last about
– ask them to repeat what they’ve been saying for five minutes.

The whirl of my mind is a bit like that special effect in Butterfly Effect where there’s a kind of wobbly text, whoosh, whoosh, and I have no idea what’s going on.

When I’ve finishing talking about their problem, I turn back to my computer. Rebooting the brain goes like this:
– what is this?
– what was I doing?
– email
– check name of git branch
– look up relevant ticket
– resume coding
– who’s this?
– does it look urgent?
… and the process continues.

Some tricks I’ve discovered to help with this:
– just don’t use facebook
– name my git branches something sensible
– try to work on one thing at a time
– keep my todo list in jira.

It mostly works. Mostly.

And why am I blogging?

My tests are running. Usually I’d switch to another branch and carry on working. Today, with a five am baby feed to start the day, I’ll settle for one thing at a time.

Tests complete. Back to work.


Everyone talks about what makes a great manager. Inspirational, motivational, aspirational. But a great project manager is a different kettle of fish. Or a kettle of different fish. Maybe goldfish.

Whatever. Different.

Let me tell you a story of many years past. I was working closely with my PM on a significant project for a major car company (I’ve actually worked for most of them).

My PM’s job was to protect me from all the political, contractual rubbish that comes with any large project, to allow me to focus.

When we went to meet our partner company for this contract, we divided up. Techies in one room, project managers in another. Hey, we only had an afternoon. It meant we could focus.

The trouble was that without project managers, we had no idea who was supposed to do what. We divided up the work as we saw it, not the way the contract, budget, or the project plan that had been drawn up in the other room, had expected.

As the project progressed, the levels of insulation increased. I was excluded from status meetings, client meetings. I was still working to my own plans.

Months of hard work later, we were significantly out of step. Expectations didn’t meet product.

Deadlines passed. Clients fumed. Rivers of blood. Earthquakes rent the land. Trees fell. Floods. Weekend work. Fire. Brimstone. The works.

At Twitter we have a core value, to “communicate fearlessly to build trust”. It’s my favourite value. It doesn’t say communicate *needlessly*, so I don’t need to know what you have for breakfast, or how much the CEO earns.

But it speaks to transparency and openness, and I’ve learned that this is what makes a great Project Manager.

Instead of standing between the engineers and the rest of the company, they serve as a connector, bringing you news, making introductions, setting up meetings. Not telling me what I need to know, but telling me everything I might want to know.

A connector, not a shield. That’s a great PM.

Why do we use jQuery?

It’s a common question these days: “why use jQuery”?

Reasons given to avoid it are:

  • Large size
  • Poor UI Library
  • No class support
  • No script loader
  • None of this, none of that
  • Moan moan moan

As far as file-size goes, I think the lack of modularity could be a real issue. If we were building a fast-as-lightning mobile app, I’d break it into parts. Or use something else. Ender, for example.

But for a reasonably-sized website, here’s what we really want:

  • Friendly, familiar API: CHECK
  • Well tested, especially across older browsers: CHECK
  • DOM lookup, traversal, manipulation: CHECK
  • AJAX helpers: CHECK
  • Custom events framework: CHECK
  • A few simple animation effects, including a queue: CHECK

Ok cool, so jQuery is actually giving us a lot of stuff, and we can just build on top of it where we need to. I DON’T find that jQuery is providing lots of things that we’re not using. Also, jQuery isn’t dictating how we work with our own code – it just provides a toolset for DOM manipulation. That gives us a lot of flexibility to find our own style.

On top of this, at Twitter we add:

  • ES5-shim – for JavaScript strict mode support
  • Loadrunner – for script loading / dependency management
  • Our custom component framework

Here’s a few things we WISH we had:

  • HTML5 polyfill – for additional input controls
  • All of DOJO’s UI components, especially (personally) the datagrid

jQuery’s plugins and UI components are the parts I avoid, but are also the parts we can build ourselves. I envy the DOJO UI, because as a user I find the controls to be useful and reliable, but i always find it very hard to work with them. Their API is awful. I’d love to see a full port to jQuery.

Ultimately, jQuery is actually a useful tool. Long may it continue to be so.

CSS Rules!

I don’t know how designers start work. I used to draw masses of squiggles, and then remove all the lines that didn’t fit. It’s probably not a good method for websites. Maybe they do the same; I don’t know.

All I know is that at some point they drag rulers, guidelines or keylines across the page, to help them line up the elements. Then they hand us the resulting PSD file, which we break up into nice little segments for conversion to HTML and CSS.

My idea: use rulers in CSS. Continue reading CSS Rules!

Building – Part 5: Serving from the Cloud

I’ve just finished working on McLaren’s new F1 site,, for the 2010 season, at Pirata London, for Work Club.

I’ll be writing up what we’ve done here in several parts. Sign up for my RSS feed to keep updated.

Part five covers the setting up of broadcast servers using Amazon EC2. Continue reading Building – Part 5: Serving from the Cloud

Building – Part 4: Load testing

I’ve just finished working on McLaren’s new F1 site,, for the 2010 season, at Pirata London, for Work Club.

I’ll be writing up what we’ve done here in several parts. Sign up for my RSS feed to keep updated.

Part four covers the load testing of telemetry data, broadcast by the nginx http push module. Continue reading Building – Part 4: Load testing

Building – Part 3: Reading Telemetry

I’ve just finished working on McLaren’s new F1 site,, for the 2010 season, at Pirata London, for Work Club.

I’ll be writing up what we’ve done here in several parts. Sign up for my RSS feed to keep updated.

Part three covers the JavaScript data for the telemetry panel, known as “The Race 1.0b”. Continue reading Building – Part 3: Reading Telemetry