And the truth (or at least, an attempt at redressing the balance)

Learnings so far after leaving my old job

It’s been three months, give or take a few days, since I left the Guardian—and London—to move to the BBC (I know, how imaginative…) in Birmingham. It’s flown by. Tomorrow I’m off for a visit to the capital where I’ll be seeing some former colleagues I haven’t seen since I left. Thinking about that has made me reflect on what I’ve learned so far.

The most immediate thing that stands out for me is that I’ve hugely upped my game, tech-wise. It’s counterintuitive: I’m the only developer on my team and don’t work directly with any other technical people. Really, I should be stagnating: there’s no omniscient senior dev or meddling software architect for me to learn from or query. Nobody is reviewing my pull requests (in fact, I’m mostly committing everything directly onto master… sorry, Roberto). Any technical decision my team needs to make is mine and mine alone – unlike at the Guardian, where this was rarely (if ever) the case, and any decision I did argue for was frequently challenged and queried by others.

On the other hand: being a solo dev in an organisation the size and scale of the BBC has forced me to drop some lazy habits and delegation I’d become used to relying on at the Guardian. True story: even at the point that I left that role (in June of this year), I still didn’t really have much of a grasp of what was going on behind the scenes when I hit the “deploy” button on our app. I didn’t know how to set up a new build process for a brand new app which would take code from my machine and plonk it onto the internet. Jesus, I’d never even used Heroku.

This was because I didn’t have to worry about those things. Other people did; often the groundwork for projects was already laid when I joined them and cleverer people than me had sweated over the fine details so I could mash the “deploy” button and go and buy an overpriced coffee while my code was hitting the servers. Clearly those skills (and tasks) existed within the Guardian but I never quite got around to picking them up. We did have vague training schemes for them and doubtless most of my colleagues would’ve been happy to walk me through these tasks when asked, but quite a lot of the time it was taken as an assumption that I either a) already knew how to do them, or b) would “self-select” and skill up on my own.

Clearly I was getting lazy and unmotivated and I think this is partly what prompted me to realise I needed a kick up the arse and to get out of that environment. It took this move – a leap of faith, really – to force me to learn what I’d been putting off.

In many ways it’s been the most challenging period of my developer career so far. The BBC has a huge, complex tech stack built over long years and hard-learned lessons. It’s called Cosmos and sits atop AWS for various complex legal reasons. Because my team was a new one with no existing tech stack (and no other developers, let alone operations support), it was my job to get to grips with Cosmos and figure out how to get my silly little apps onto the cloud.

It was painful. I wrestled with internal wikis, plagued IRC channels, roped generous remote colleagues into answering my rambling questions and eventually worked out that my lack of a developer certificate on my machine was why I couldn’t get half of it to work was a problem I needed to solve. I had to learn what a VPC was, how to configure CNAMEs in Route53 and automate build jobs from Github to Jenkins to the cloud. And I did it.

Now, it probably took me twice as long as most more competent developers would’ve taken, and doubtless there are still rookie errors and configuration bugs I’ve yet to spot which will cause me troubles down the line. But the main thing for me is that I’ve definitely “levelled up” as a developer in a way that I was never going to do at the Guardian. That’s likely down to me – when I get unhappy I tend to disappear into my own little world of moodiness and introspection, and by the time I recognised it at the Guardian I was too frustrated to want to solve my problems there and it was better just to leave. No doubt I could’ve learned all these things there too, but the comfort factor of sticking to what I already knew was too easy and the lack of management support meant I wasn’t being challenged to do this myself.

I should also say that the BBC itself is great at teaching these things: there’s actually an official internal training course (a proper, real-life event lasting two days) to learn about Cosmos, which I’m booked onto. New developers typically get a better start than I did because they’ll be joining established teams (or at least reporting to other technical staff who know the workarounds and timesinks from tried-and-tested experience).

I don’t regret my experience so far because it’s taught me to learn to solve these things myself – and as I hinted at above, I have almost complete freedom to decide what I work on, how I build it and when it’s “done”. With great power comes great responsibility, of course, and I’m conscious that left unchecked this will start to see my work decline if I get blasé about my code, but in general right now I’m feeling like uprooting myself from my comfort zone has been one of the best things I’ve done in a long, long time.

Past, present and future

By the time I press “Publish” on this entry, my employment at the Guardian will be over after just shy of five years working as a developer there. I’m also days away from leaving London, the city I moved to in order to work at the newspaper. I’ll be moving to Birmingham to start a new job with the BBC. This post is a reflection on the road that’s brought me here.

The past

It feels a bit strange to think of my time at the Guardian as being “in the past”. It’s still only my second job and the longest time I’ve spent working anywhere. It’s changed an enormous amount since 2010, not least the new editor whose stint began during my final week. Most of the changes are for the best, but some of them less so.

Ultimately I left because I felt under-utilised and bored. I have to take responsibility for these things myself, at least partly: I could’ve pushed to be placed on more dynamic projects or kicked up more of a fuss when I fell through the cracks a bit after stepping down as a manager last summer. I didn’t, though, and it was when I realised that I was beginning to feel negative towards the company and my department there that it was time to go.

I was asked last year to mentor a talented young chap on the Guardian’s graduate scheme and the experience really brought home to me how much my own career was missing someone in that role who could look objectively at what I was doing and give me a nudge in the right direction. The Guardian does have a line management function (indeed, I was a line manager for three of the five years I spent there) but in my opinion it’s poorly defined and implemented.

The Guardian has a fantastic reputation technically and people are always attracted to it as a workplace for tech/software as well as the obvious journalism draw. This is all completely valid and I’ve worked with some of the smartest, most intelligent people I’m sure I’ll ever encounter. On the other hand, I often felt the dreaded imposter syndrome as people made assumptions about my experience and knowledge which were widely off the mark. Similarly, several times I had the unpleasant experience of way smarter people than me pouncing on things I’d been doing and telling me how wrong they were. Again, this is down to me: better communication could’ve avoided these things, but equally, my department over the last year saw a rise in the pursuit of senior engineers, which I think exacerbates this aggressive mindset towards coding ability.

Really, I just didn’t feel like I was fitting in: I’d had a go at being a manager because I thought I could at least get my head around working with people, if not senior software engineering. That was a challenging experience which I don’t regret but definitely reached my limits with (for now). When I saw the Creative Technologist role at the BBC advertised, I knew that this was closer to what I wanted to be doing: using tech to make things. I’m never going to be the super-smart engineering guru who can grok monads while debating the finer points of graph theory. But I can usually hack something up which does what I need, and even learn how to do it better next time if I’m lucky enough to be working alongside someone who’ll explain it to me and not just do it themselves.

The present

That brings me to the current day. I resigned from the Guardian, worked out my notice and am about to begin my next role at that other big liberal media organisation, the BBC.

It’s going to be hugely, dramatically different. The team I’m joining is (I think) seven people strong – my immediate project team at the Guardian had eleven of us and that was in a department of 130+ people. I’ll also (as far as I’m aware) be the only developer. This is both terrifying and liberating.

The stuff we’ll be building won’t be directly related to news journalism, which has been my bread and butter for the last five years. This, too, though, feels exciting: the Twittersphere and the London media bubble do a great job of sucking you in until you end up feeling like either a) everybody else in the country experiences things just like you do, or b) who cares what people who aren’t in it think?

I took a few months off Twitter while I worked through my job frustrations and it was really valuable: I stopped missing it pretty quickly; found myself thankful I wasn’t there when things like the Jeremy Clarkson sacking took place; noticed the proliferation of media reporting on what essentially boiled down to Twitter drama (whereas before I’d usually find such write-ups relevant and newsworthy). I also stopped going to London media meetups which tended to be overly schmoozy/cliquey. This helped me remember why I got into writing code in the first place: to make cool stuff that people would look at and enjoy, not to fart around in a filter bubble with the same few dozen faces.

Before I get too self-righteous, I also should be clear that I’m about to start working at the BBC so I’m hardly some provincial everyman. I’m super excited, though, to be part of what’s unquestionably the greatest broadcaster in the world: it still hasn’t really sunk in yet but I got a little tingle of pride when they emailed me my staff ID number.

The future

And that brings me to London—or to be precise—makes me leave it. I’ve written here in the past about my frustrations with the capital and it seemed the right time to try going somewhere else.

I love the city and I’ll never regret the years we spent living here. I’m sure I’m going to miss it hugely too: while I’ve reassured myself that Birmingham has all the things I need for my daily quality of life, it’s not London and never will be, and I’ll miss the capital for its abundance of random interesting events, unbeatable culture and sheer scale: it’s been inconceivable to me to imagine being unable to travel to some part of the city at an unusual hour, buy something outlandish even on a Sunday evening or sample the cuisine of a nation on the other side of the planet as I wander down my local high street.

But then, London doesn’t have the monopoly on such things, and indeed, that’s the snobbish attitude many Londoners have about the rest of the country. I’m proud that the BBC is bucking the Londoncentric trend and excited to see what living somewhere that’s definitively up-and-coming (compared to the less salubrious parts of London I’ve lived in that have doggedly been claiming just that for the better part of a decade) is really like.

So, what’s next? Well, Maddy and I are both 28 (well, she has a few weeks left of being in denial about graduating from Club 27) and starting to think about what’s next for us. I’d like to start thinking about having kids one day and this is all just another step on the path of settling down. Probably. Let’s see what happens, right?


An apology

On Monday night I posted a ranty tweet which I followed up on Tuesday. In essence, I was registering my surprise that a digital journalist at an internal event admitted they didn’t know what “CMS” stood for.

There were a couple of reactions to the tweet, mostly from people arguing (skilfully) that not knowing the definition of an acronym doesn’t necessarily amount to not knowing the concept itself, which I agreed with. In casual (alcohol-influenced…) conversation with workmates this evening, though, it turns out I ruffled a few feathers with that tweet – all credit to my colleague Will Franklin for having the balls to tell me he thought I was out of line.

I wrestled with posting it: beforehand I talked it through with my partner and explained that the event where I heard this soundbite (an internal, Guardian staff-only version of the Hacks/Hackers meetup) was an inclusive space and that I didn’t want to discourage people from attending, or continue the myth that web development is a members-only domain where you have to know the specific lingo/jargon in order to make headway. The event itself is a fantastic opportunity for devs and non-devs alike to meet up and talk about digital journalism.

I don’t have a Facebook account and often use Twitter to register quick reactions and my personal thoughts on things as they happen, which have (on occasion) turned into something bigger while I slept overnight. It turned out that in this instance, the things I’d posted had caused colleagues of mine to discuss my tweet (and presumed attitude) in internal emails. When I first heard this I thought it was a bit odd that people were talking about stuff I’d said without involving me, until I realised that that was exactly what I’d done to the person whose admission I was referencing in my original tweet.

With that in mind, I’d like to apologise for coming off as exclusive and snobbish: I strive in my work and my personal life to be inclusive of others and highlight occasions when people are marginalised and ignored. In this instance I pointed to an individual (albeit without identifying information) and registered my concern that they didn’t know a technical term I thought would be commonplace. A colleague this evening pointed out that I couldn’t define the term “monad” (a technical term for a software concept… I think), despite the fact that I’ve almost certainly made use of them in my career as a developer. This is a completely fair point and one I failed to consider when making my initial complaint.

I’ll make no secret of the fact that I’m pretty unhappy in my job at the moment and feeling fairly negative towards the Guardian right now (this is another blog/rant entirely…), which I think influenced my complaining tweets during this event. This is no excuse, though, and doesn’t change the impact of my words on the person I was referring to (or those who saw it).

So: while I won’t deny I found it surprising to hear of a journalist who didn’t know the term “CMS”, I agree that the way I highlighted it and the act of drawing attention to it didn’t add anything to the problem (if indeed it is a problem) and wouldn’t have made the individual in question feel more welcome at that event.

What am I going to do about it? For one, take the person concerned for a coffee and talk about what we can do to break down boundaries between technical nerds like myself and the people on the frontlines of journalism (watch this space to see how that goes). I’d be interested in other things you think would be worth doing here, too. Let me know.

Humans and algorithms

Dick Costolo, CEO of Twitter, has made headlines this week for his admission that “we suck at dealing with abuse and trolls” as part of an internal memo. While Twitter is unclear about how they currently moderate the platform, it seems that much of the removal of questionable content is done via users reporting it, rather than by Twitter employees actively engaged in seeking out abusive content and removing it.

Google has a similar fear of policing their content. Famously, they refused to take down a racist graphic of Michelle Obama in 2009, adding a message to the results page which explained they won’t take down a link “simply because its content is unpopular or because we receive complaints concerning it”. They went on to point to their algorithms (including a nerdy boast about the “thousands of factors” they make use of), which account for the “integrity” of their search results.

Twitter’s own “rules” are explicit about their stance on this theme (emphasis mine):

We respect the ownership of the content that users share and each user is responsible for the content he or she provides. Because of these principles, we do not actively monitor and will not censor user content, except in limited circumstances described below.

The “limited circumstances” they mention are mostly around fake accounts and legal concerns, although there is one mention of “direct, specific threats against others” (which, it seems, is up to users to report or “local authorities” to bring to Twitter directly). Their use of “censor” speaks volumes about their current take on what it would mean to actively moderate the stream.

There’s a brief parallel here with the web development community. Last year, Eric Meyer, a prominent web developer and industry figure, lost his six year old daughter Rebecca to a brain tumour. In response, a set of developers and friends proposed adding the alias “rebeccapurple” (a colour she loved) to the hex color #663399 as a tribute to her life (and his work). The change was accepted, but was not without controversy: on several technical discussions, people argued against the change:

I don’t see why a project like Mozilla would allow an emotional response to work its way into actual code, and I think it’s dangerous precedent. We don’t need in-jokes, easter eggs, or memorials in established web standards, and I think it’s irresponsible to suggest that this is the right course of action. – Jay P

For me, this comes down to the same thing as Google’s refusal to overrule the all-powerful algorithm or Twitter’s clear desire to avoid the messy business of hiring humans to police other humans. These are technology companies (or technical standards): there’s an almost outright fear that any involvement of actual people making emotional, “logic-free” decisions is an admission that the whole system is imperfect and unworkable.

Why are we so afraid of the things that make us human accidentally making their way into our systems? As if the world we currently live in isn’t shaped by humans and our emotion in its words, its social conventions, its standardisation and its measurements?

Maybe Dick Costolo will reconsider the claim that removing questionable content is “censoring” users. He might reflect instead that he has the power to shape the experiences of an entire social group—users of the web—and that allowing human emotion, empathy and compassion to shape that group might in fact be to its benefit, rather than passing the buck to computer code.

And maybe we’re too complicated for mere algorithms, no matter how “integral” they are.


Book review: JavaScript & jQuery (by Jon Duckett)

I was excited to sit down and read the newly-published JavaScript & jQuery by Jon Duckett, produced by the team behind the hugely well-received HTML & CSS book. It’s a large and beautifully-designed tome aimed at newbie developers with familiarity with HTML/CSS but no experience with programming in the browser. In this post I’ll offer some thoughts and feedback on a couple of aspects of the book, but the TL;DR version is: if you’re new to front-end web development, buying this is a no-brainer.

Things that are amazing about the book:

  • It’s very thorough. It rarely rushes (it’s over 600 pages long) and builds things up logically, “linking” to future chapters where topics that are hinted at will become fleshed out. For someone new to the language it will give them a thorough grounding in many aspects of JS.
  • It’s good at answering the “why should I care?” question. Many of the code examples would be challenging to explain in purely theoretical terms, but by pairing them with screenshots of an attractively-designed mock website and using the code to manipulate the page, it’s never a challenge to work out why a particular function or property is useful for making websites.
  • It’s gorgeously designed. The image on the book website of the for-loop flow diagram is probably the money shot, but generally it’s a pleasure to read and may be the only published JavaScript book which will make you look cool while you’re reading it in a coffee shop.
  • It’s great value. I came into the jQuery plugins section thinking it’d just be a way to pad out the last hundred pages or so with cheap instructions on using lightbox or something, but in fact it broke down the concepts and the DOM structure in almost obsessive detail and really got into the idea of building things in modular, configurable way. This is probably a bit advanced for the casual reader but represents good value for money (and plenty of repeat reading value when someone’s digested the basics).
  • It works for experienced developers as well as newbies. I’ve been writing JavaScript for quite a while these days but there were things in here that were new to me (I didn’t know jQuery had a $(“:header”) selector…) and it also cleared up a few niggly things that I could never quite adequately explain to myself. In general it’d be a great reference book to have around an office or home, regardless of experience level.

Things that I found a bit weird about the book:

  • Early on in the book there are code examples where a HTML element’s class attribute is set to the string “true” or “false” depending on a Boolean. There’s a quick disclaimer that this is rarely useful but it seemed odd to me to demonstrate it all rather than using a proper, semantic string for a classname.
  • Some of the layout choices made it difficult to know what order to read things. It did sometimes feel that things had been placed on the page in order to achieve optimum symmetry or alignment rather than to aid readability. Here’s an example:IMG_20141001_223200
    Some pages have this style of text but without the numbering and it’s not always clear if you’re reading in columns or rows.
  • In the section on JavaScript’s Date object, the book explains that getMonth() will return a month number ranging from 0-11, but doesn’t flag this up enough in my opinion (or attempt to explain why this is the case, although I have no idea either…). This feature often catches out newbie developers with JS.
  • This code sample is a bit weird too. I understand the technique and why it’s mentioned but I think it’s an unhelpful and confusing thing to show to a new developer (mangling HTML to fix cross-browser issues?) and just serves to make them think browser support for fairly innocuous stuff is even worse than it is.

  • As beautiful as the pages must’ve looked on a screen during design, the all-black pages lose something by the time a sticky set of paws like mine touch them:IMG_20141001_223339
  • This page (and a few others like it) seemed a bit incongruous:IMG_20141001_223400
    Again, I can see why they felt it should be included, but why give it a whole page?
  • The Handling Exceptions section feels a bit rushed and glosses over some concepts that are fairly challenging for anyone who’s never come across try/catch blocks before (eg. most of the intended audience?). The tone of some of these pages was (to me) markedly more complex than other parts of the book.
  • This sentence:IMG_20141001_223525
    Maybe I’m just immature, but the quote marks around “closed” felt a bit melodramatic.
  • I can’t really see any reason to angle the “blurb” text on the back cover except to make it feel like decoration and not something you’d actually read:IMG_20141001_233948
  • Similarly, the angle of the text on the spine is different from all the other books I own which is mildly jarring to my OCD:IMG_20141001_234043

These are almost all minor quibbles though. There are a couple of clear code/printing errors (which the website already corrects) and one or two fonts which feel a bit large to read comfortably up close, but otherwise nothing to be worried about.

So, overall thoughts? Well, I already recommended the book to members of the HTML, CSS & JavaScript beginner’s course I teach, which should tell you something. It’s massively well-researched, works on multiple levels and has been put together in a beautiful, readable and understandable format. The team working on this have worked really hard to create something that will no doubt go down as a classic of the genre (as the HTML & CSS book has) and I’ve already had multiple people in my office eyeing up my review copy and asking to borrow it when I’m done.

If you’re new to JavaScript or need a refresher, go out and pick this up – I was really impressed.

Note: the photos above are all from my fairly rubbish camera on my phone, so if text looks weird / blurry etc, that’s almost certainly my fault. The book itself looks lovely – check out the website for more.

Full disclosure: I received a free copy of the book for review, but that’s all.