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

#harkive 2017

Note: this blog entry is for the #harkive project, an annual popular music research project that asks people to tell the tale of HowWhere and Why they listen to music on a single day each year. You can find more about that project on the official site.

I wake up to the sound of Radio 4, perhaps the most middle class of awakenings. It’s on the alarm clock and I quickly switch it off: sometimes you need a coffee inside you before you can stand an extended John Humphrys monologue.

I travel to work in silence besides the noise of the bus, preferring to read a magazine without musical distraction until I arrive at work. My first proper music listening of the day doesn’t start until 11am when I finish all of my just-got-to-the-office catchups, discussions and meetings and am able to escape into my headphones.

I’m quite bad when it comes to listening to old favourites rather than new music so I start off with a classic: At The Drive-In’s 2000 album “Relationship of Command”. I was obsessed with this band in the early 2000s—just after they split—and was a bit disappointed by their recent new album, so I return this one for its sheer urgency and power. Every time I hear it fires me up and takes me back to being 17 and angry, presumably at something.

After this blast I need something a bit more casual so I decide to turn to Wikipedia to see if there’s any musical history happening today. It turns out that July 25th 1965 was the date that Dylan went electric at Newport Folk Festival, so I pop on “Bringing It All Back Home”, some of which featured in Dylan’s controversial set. I was all set to listen to a playlist of the actual songs he performed that day but it turns out nobody’s created one on Spotify and since I’m too lazy, I stick to the album. It’s a good mix: some ballads, some stompers and a classic or two. I still love the laughter at the start of “Bob Dylan’s 115th Dream”.

After lunch I decide I should probably listen to something recorded in the last decade, then remember reading an interview with HAIM the other day which means they probably have a new record out. I caught some of their set at Glastonbury in 2014 and enjoyed it so I give their new release, last month’s “Something To Tell You” a spin. I end up adding “Nothing’s Wrong” to my “class” Spotify playlist (eg. good songs) for its Fleetwood Mac-esque soft rock beauty (and those backing vocals). The rest of the album blurred past as I worked and a few songs piqued my interest, but I find myself more interested in the code I’m writing for most of its duration.

With a post-lunch slump setting in, I decide to take a coffee break and head outside. Before, though, I banish an earworm and play “Ghosts” by the Jam, a song I habitually noodle whenever I pick up a guitar. I first came across it via a cover by Ted Leo, but the original version has a neat horn section in the back of the mix which really picks it up. This song also got used in an episode of Eastenders as the funeral music for Kevin Wicks (aka Phil Daniels of Parklife fame). Trivia!

I spend a little time paging through my music collection for an event I’m running tonight, “Off The Record”. It’s a record club (like a book club) with a different theme each time. This month our theme is “A European Union” so I scan through my library for bands made up of Europeans. It’s harder than I thought – turns out I listen to a lot of North American artists. Amongst the Euros I do track down, though, are Joe Strummer and the Mescaleros, The Tallest Man On Earth, Jaga Jazzist and Django Reinhardt. I add these to my playlist for later and leave the office to head to the pub where I run my music event.

On the way there I listen to the ITV Cycling podcast on my phone. They produce a daily show for the Tour de France, recorded by the same staff who produce the TV commentary and daily highlights package for TV. They must do the podcast last and every episode is hilarious because they’re either desperate to wrap up, rehashing stuff they’ve already said on camera, or taking the piss out of each other (probably after a few glasses of wine, too). This might not sound like a great advert but it’s a fun show and the camaraderie between the presenters makes it an engaging listen.

This time I’m catching up on the final episode from Sunday’s stage into Paris, and at one point, presenter Ned Boulting makes a joke about what he can hear in his earpiece from his director when broadcasting live. He jokingly makes a radio fuzz noise into the mic, when suddenly my headphones come loose from the socket and the audio becomes muffled and just emits an irregular clicking noise. I listen to this for almost a minute, thinking it’s an extended joke about how bad their in-ear audio gets, before I realise it’s a problem at my end and plug the cable back in properly. Oops.

Soon I’m at the pub and get the equipment set up for that night’s Off The Record event. Our theme is “A European Union” so we’re listening to music from the continent. I switch on my playlist from earlier for background music but after a while I find Joe Strummer and the Mescaleros a bit too soft (sorry, Joe) so I put on Ted Leo and the Pharmacists (“Shake The Sheets”, perhaps their best record) to liven things up.

Eventually it’s time for our album: each month a group of 20 or so Birmingham music nerds get together and we listen to an album together, then talk about it. It’s an event I’ve been running for two years now and it’s a fun night. This month we’re listening to The Whitest Boy Alive’s 2009 album “Rules” which I’ve never heard before. It’s a danceable, upbeat affair with introspective lyrics and a clean, simple vibe. I enjoy the album, and the songs everyone else plays after it’s done (see the official site for that playlist!). I also contribute a song myself: “Day” by Norwegian jazz fusion pioneers Jaga Jazzist. I can’t stop myself from picking out the piano and guitar notes with my fingers on the table as it plays: it’s that kind of song.

The night draws to a close and I’m probably a few drinks ahead of where I should be, given I have an early flight the next morning. We grab a cab and hear the sound of the city receding behind us as we head home. The last sounds I hear before drifting off are a brief excerpt from the Alan Partridge audiobook—read by Steve Coogan—which is as ridiculous as it is funny.

With the exception of Off The Record this has been a typical day for my music listening, albeit one a little more focused than usual. Deliberating over what to listen to can turn into a Netflix-esque “nah, I don’t fancy that” so it’s refreshing sometimes to just jump into something without thinking too much, like I did with HAIM. Spotify is great at recommending me things I’ve missed, and perhaps I need that gentle nudge to avoid rehashing things I’ve heard a thousand times before. I’ll be checking out the collaborative #harkive playlist to see what other things I missed today.

Five things I’ve learned being on an innovation team

For just under two years now I’ve been a “Digital Guerrilla”, working as part of a team of six in Birmingham, created by the BBC to “pilot and prototype new storytelling ideas”, and help the broadcaster to “engage with its audiences and to deliver unforgettable content”. I’m leaving this month for a new role, but wanted to share some learnings from being embedded inside a huge organisation and being tasked with—that dreaded word—innovation.

1. Ask forgiveness, not permission

I’m kicking off this list with some hypocrisy, because this was something I wish I’d done more of at the BBC. It’s a large, complex and embattled organisation and therefore is famed for its processes, bureaucracy and policies. Most of these are understandable—even laudable—but they can certainly make for challenges when trying to push boundaries.

For example, releasing webapps that use public APIs like Twitter’s or Facebook’s require a custom development agreement to be put in place, because the BBC can’t sign anything granting unlimited indemnity (eg. if our Facebook app broke your computer somehow, the BBC could be liable to pay all your costs). This means that before we can release apps using these platforms, we have to get custom, BBC-specific agreements in place with Legal first.

Other concerns are around editorial policy: some parts of the BBC’s web properties I’ve worked on contain sex/drug reference. In one quiz we built (aimed at a middle-aged audience), we had multiple meetings to solve the (mostly theoretical) issue of an under-16 browsing our quiz and finding a link back to BBC Taster (which sometimes contains this edgy content) and being exposed to it. Lots of people were consulted on this before we signed off on wedging some copy into a text box intended for a survey, which warned curious youngsters not to click any further.

I mention this not to moan about the BBC (which, after all, is trying to protect the license fee payer), but to suggest that the world might not have ended if we’d just put these things out and taken the risk. Two of the apps I worked on were blocked from release at the end of the project for these kind of reasons. Clearly better up-front planning and discussion could have avoided this, but sometimes when you’re being asked to innovate, you have to ruffle a few feathers. Just don’t get sued.

2. Know your audience

Being asked to build things for a demographic you’re not part of is challenging – more so when that demographic is “young people” / millennials / your-epithet-of-choice-here. Everyone kids themselves that they know what teenagers like online (“oh, it’s all about Snapchat, right?” they say confidently), but really, it’s a mystery.

With that in mind, the projects I’m most proud of are the ones where we got out of our comfort zone (and studio) and met the audience face-to-face. Lacking a proper UX process, we did it guerrilla-style: popped over to the local university and plonked our stuff in front of them. Watching a bunch of first years mercilessly tear apart a D&D-style Twitter game we made was sobering but powerful: we learned more that day than in the months of development we’d spent up to that point.

We also got to see the real people behind the glossy personas or the faceless demographic charts. Real people are messy, unhelpful, resistant to pigeonholing and a thousand times easier to make things for when you’ve spent time with them. Every time we put our work in front of people and waited to see if it could stand up on its own, I felt nervous, defensive, proud and informed all at the same time.

And on the projects where we didn’t? I rarely felt much at all. Unique users on a chart are nice, but almost meaningless at an organisation the size of the BBC. We don’t need vanity metrics when we’re innovating, we need to see a real person recognise the value in the thing we’ve built. Get in front of them.

3. Throw things at the wall and see what sticks

I’m a firm believer in the agile/lean manifestoes – release early and often. Innovation should encompass this: you’re supposed to be trying new things and by definition, not all of that stuff will be relevant to your audience. Maybe some of it will become so, but it’s your job to work out what that might be.

With that in mind, life’s too short to lock up ideas in a lab while you perfect them. The sunk cost fallacy quickly creeps into the picture when you do this, too, and we were victim to spending too much time (and cash) getting something done, and releasing it knowing it wasn’t great but had to be launched.

The quicker you can drop professional pride and just get used to putting things out and seeing how the audience reacts, the quicker you can drop the stuff that isn’t working and focus on what is. It sounds obvious, but it’s surprising how hard it can be to switch to this mindset when you’re not used to it.

Case in point: 360° videos. I can’t think of a single other technology where the ratio of interest from publishers to users is so highly in favour of the former. The BBC loves them. Sure, it’s cool the first time you see one, and when the entire world is wearing an Oculus Rift at all times then bring ’em on. But the high cost of production (in terms of both time and money) means you could pilot three or four quicker, more agile ideas for the same cost.

It’s all about not being afraid to set a target for an idea (number of social engagements, time spent on average, or plain-old hits if you want to go all 90s) and then releasing it, interrogating it, and iterating – it’s the digital equivalent of cutting a path through a dense jungle. Let someone else airlift a cement mixer to the forest later.

4. Be a unit

This was the first time I’d worked on a small team – in previous roles I’d been part of teams of a dozen or so, but here there were just six of us.

Geography played its part in challenging us – we weren’t based in a mainstream BBC office (just on our own in Birmingham’s “creative quarter”, Digbeth), not all of our team were located in Brum, and frequent trips to London to work with other teams sometimes got monotonous.

However, the moments when the whole team were engaged on an idea: everyone focused on improving it, testing it, developing it – these were the standouts for me. You’re more invested in the success of a concept when you’ve had a hand in shaping it, and you’ll fight for something you know is a strong idea when you’ve sweated on the details and partnered with your teammates to make it better.

We had a few periods like this – all cylinders firing, everyone contributing to each others’ ideas, everybody willing an idea to succeed. It’s hard to capture and difficult to regain when it’s disappeared, but team unity is paramount and correlates directly to the strength of your output: you need to be greater than the sum of your parts.

5. Innovation is relative

Finally, the dreaded I word. Explaining your work on an innovation team might become a millstone around your neck when you speak to certain folks – they’ll think you’re either trying to be the next Elon Musk, or about to sell them a VR headset. It’s easy to get down about your work and think “this isn’t innovative, someone could’ve done this three years ago”.

Innovation, though, is relative to the organisation you’re doing it in. When I started at the BBC they’d never been able to embed a Disqus commenting widget on a site. Small an achievement as it was (I’m not putting “embedding an <iframe>” up there with “inventing SpaceX”), it represented a step forward in navigating the BBC’s legal/editorial policy framework (see above), and perhaps helped show the organisation that the sky doesn’t fall in when these things happen.

If you’re in a team tasked with innovating within your company, remember that you’re not being measured against the entire digital industry. What are the things your organisation is afraid of or “unable” to do? Prove to them that it’s possible and build those future paths for other people to follow.

By next month I’ll be off on a new role, helping another organisation to challenge boundaries and explore new ways of working. Not everything worked the way I wanted it to at the BBC (though when can you ever say this about a job?) but I learned several useful things about how we work, how we develop ideas, and how to approach challenges in a huge organisation – I’d happily do it all again.

Debunking Private Eye’s “gobsmacking” gender/race accusations

There’s a photo doing the rounds on Twitter of an extract from the current edition of Private Eye magazine. The text concerns the recent Forward prize for poetry, and the chaps from the Eye have decided that the gender/racial demographics of the Forward prize panel chair and the winners of the prize suggest a sinister conspiracy:

“Maliki Booker [the chair of the judging panel] is a British writer of Caribbean parentage, and so it was not entirely a surprise, though still rather gobsmacking, that all three prize winners were women, that two were from the Caribbean […] and that [one winner’s] publisher, Peepul Tree Press, is also Booker’s.”

Was this gobsmacking, though? Did the blokes from the Eye bother to do any number crunching to determine just how surprising it was that a woman chair would select three women as winners?

Short answer: no.

Longer answer: definitely not. Let’s dig in:

For one thing, the chair in question is just one of five judges – and the 2016 panel included two men. They choose three winners each year (in different categories). How much is Private Eye willing to ignore the contributions of the four other judges, none of whom are women from “Caribbean parentage”?

If we look at the lists of past winners and past judges/chairs, we can do some analysis. If we look for panels which awarded prizes to poets of a single gender, there have been three all-male winner lists (1994, 2001 and 2003) and two all-women winner lists (2016 and 2015). The two all-women lists were chosen by female chairs, but 2/3rds of the all-male lists were chosen by female chairs, too.

TL;DR: women are just as likely to choose all-male winners as all-female. Men have never chosen all-women winners (women have done this twice).

We can also see that women chairs show a far less polarised distribution of voting:

… whereas the male chairs massively skew towards a 66% male selection of winners.

TL;DR: men tend to choose other men to win this prize. Women are much more likely to pick a mixture of genders.

Finally, to the Eye’s dogwhistle-like mention of the racial origins of the winners this year. Well, life’s too short to compute the birthplaces of 75 poets (and it looks like the Tories are about to make this compulsory soon anyway), but it’s curious that they don’t mention this for the other years where it’s probable that there was overlap in the countries of birth of the judges/winners. The fact they bring it up at all suggests they think that either a) there’s something suspicious about people from the Caribbean winning an award based on merit or b) there’s an objective “winner” in poetry prizes that will always be selected by any panel of judges, regardless of their interests, origins or reading habits.

Either way, this is shoddy journalism. The data tells us that it’s more unusual for women chairs to pick all-women winners for the Forward prize, and that the only consistent pattern—if any—is for male chairs to pick majority-male winners. That is the scandal the Eye should be complaining about.

A resolution on communication

Talking is hard. So’s writing. Self-expression is sometimes crushingly futile when we try to reduce the mad, beautiful complexity of the human mind into the crude box we call language. Even with the best will in the world we can still mess up, “misspeak”, communicate badly.

In the spirit of “do unto others”, a vaguely new resolution of mine is to tell others when something about their communication has made things difficult, upsetting or unhelpful for me. This is, of course, purely subjective – something that hurts me may not hurt others, and doubtless most times the people in question don’t intend to cause offence. These are the people it’s worth reaching out to, then – if something I said ever hurts or demeans someone else, I’d sooner know about it than not, no matter how hard it is to hear.

With that in mind, here are a couple of recent incidents where I’ve exercised this new power.

I’m a solo developer on a team at the BBC that’s not directly connected to the rest of the organisation – we don’t sit in a regular BBC office or have daily contact with other teams. While this is hugely freeing and means we can work quickly and with minimal restrictions, there’s also the side effect that it can sometimes feel isolated and lonely. At the end of last year I went to an internal developer conference along with probably a hundred or so other BBC technical staff. I didn’t know anybody else there and travelled to a different city for the day.

Some days my introvert nature is stronger than others and that day was definitely more of a “flight” than “fight”. I listened along to the talks but didn’t really feel like striking up a conversation with the groups of folks all around me who were all existing colleagues.

During one talk, a senior architect was asking the audience whether they’d used an internal software tool his team were working on. When almost everyone raised their hand he jokingly changed the question to “okay, who’s not heard of it?”. I raised my hand – then looked back (I was sitting on the front row) to see I was the only person in the room with my hand raised.

Now, probably nobody else noticed or cared, but in my state at the time I was already fighting back feelings of imposter syndrome, “you don’t belong here”, etc. This question all but confirmed it for me: I wasn’t part of this crowd. It took most of my self control to stick around for the second half of the day after that, trying to reassure myself that the talks on programming were still relevant regardless of whether I’d heard of some internal library.

After the event I decided to email the speaker and let him know how I’d felt. I acknowledged that he’d not meant to single me out or poke fun at anyone, and that I’d done the same sort of “put your hand up if…”-style audience participation in talks I’ve given. But I wanted to share with him the realisation that I’d had at that moment: asking those kind of “survey” questions in that sort of exclusive (rather than inclusive) way is liable to isolate some of your most important audience members: the ones you haven’t encountered yet.

To his credit, he replied and agreed with my feedback and pointed out it was an off-the-cuff comment. I felt glad to have shared my feedback with him, though – if I’d given that talk and inadvertantly made someone feel out-of-place I’d prefer to know, and correct it for next time.

The second time I’ve recently given feedback was during a particularly trying exchange of emails. My team got clobbered with some red tape: essentially, we had to undertake a (second) security review of an application we were building for boring, complex process reasons. The man who instigated the review sent our team a fairly unhelpful email (with multiple senior stakeholders CC’d in) which didn’t offer us much support with fixing the problem he’d raised.

Once we’d fixed the issue, I asked a technical question and got back a fairly patronising message from him stating that it was “concerning” that I didn’t understand the issue – an issue that he’d raised. In this reply he’d again copied in some senior folks. I acknowledged my error (which it was indeed) and thanked him on the thread for pointing it out.

I then privately replied to him and pointed out that escalating the email to my boss and the way he’d spoken to me had embarassed me and, I felt, could’ve been resolved with a private message between us. I noted that I didn’t feel he’d approached us with an attitude of wanting to help us get our product live and iron out the issues, which is the policy that particular team are meant to stick to.

Again, to his credit, he replied and apologised and said he hadn’t been out to embarass me – indeed, he revealed his own frustrations that teams like mine were left without clear training on how to avoid some of these issues in the first place. I was glad I’d given him the feedback – it might assist other teams in future if they’re dealing with these situations.

I don’t want to come off here as a special snowflake who’s constantly being offended by well-meaning folks (and then griping to them over email about it). I’m in a fairly unique position at the moment where my team is isolated from the rest of the organisation – often these kind of issues would be resolved over a face-to-face chat. But I do believe that it’s valuable to give—and receive—feedback on how we talk to one another. It’s the worst feeling in the world to find out that you’ve hurt someone without meaning to – I’ve experienced this and remember how awful I felt. But as bad as you feel when you realise you’ve let yourself down, you’d feel worse if you never got a chance to correct it or make up for it.

So I challenge you: if someone you work with or see socially (or anything else) has communicated with you in a way which hurt you, annoyed you or prevented you from doing something, don’t be afraid to (productively, and politely) tell them. Do so in the spirit that you’d like to receive such feedback: from someone who believes you can (and want to) do better. And if you’re reading this and I’ve made you feel like that, I want to know about it too. Drop me a line!

My Atom setup

I recently decided to switch my main text editor for coding from Sublime Text to Atom by Github (mostly because my old work license expired when I changed jobs, but also because I liked Atom’s open-source nature). In the six months I’ve spent with it, I’ve grown to love it and wanted to share a few tips I’ve learned in the form of packages you should definitely install for almost any form of coding.



Really simple – makes files in your sidebar show up with file-type icons. Should just be part of Atom core really.

linter / jshint

You’re linting your code for errors as you work, right?


A bit of a hangover from Sublime Text and probably not crucial but I love it just for familiarity. Again, should just be a core Atom feature.


Useful just to go back to where you were.


Super, super useful if you’ll be using Atom across multiple machines. It uses your Github account to sync your plugins/settings across computers – I use it to keep my work and home Atom instances in sync.

Working with text



Useful if you’re a bit OCD and want your import statements, object definitions or other repetitive code to be beautifully aligned.



Like aligner, but to the nth degree. I use this frequently when working with someone else’s (messy) code or improving things I’ve typed into the browser console etc.



Some days, you just want to feel epic when you code.




This one’s handy to just help you browse for files in your current project.



Gives you a shortcut for a handy color picker meaning you don’t have to leave your editor if you just want a half-decent colour.




I was initially sceptical of Emmet but decided to give it a try when building a few sites from scratch. Being able to type out a single line and get back dozens of boilerplate is great, and its CSS autocomplete shortcuts are nice too.

Visual aids



Super useful for me as I sometimes struggle to find my place when switching between Atom and other windows.



Another Sublime feature I missed – select a term and see where it’s used in other places.



The definitive colour preview package – it’s even clever enough to highlight interpreted variable colours and Sass functions if you enable the setting to do so.

Augmenting Atom



I’d tried tern in the past and found it slow and unworkable (albeit for a massive project), but for smaller things I’ve found this handy – adds IDE-esque features to Atom allowing you to jump to the definition of a variable or function, and adds autocomplete tooltips for your own functions and modules to remind you what arguments they take (even inferring parameter types where it can).

tool-bar / tool-bar-almighty


A set of plugins to add a nifty toolbar menu to Atom allowing easy access to settings, splitscreen views and others.

In all of the screenshots above, I’m using the beautiful (free for personal use) Input Mono font, the Seti UI and the Chester syntax theme.

These are the plugins and settings I use every day – I’d encourage you to try out a new editor for 2016 if you’re stuck on the non-free, slowly-updated Sublime Text. Github are putting a lot of work into Atom and it shows – my only criticism is its slow startup time but I can live with this, and a hackable, web technology-based editor is a welcome change. Give it a try.

Postscript: Kevin Mears on Twitter pointed out a nice Atom feature where you can “star” a package and then install another user’s starred packages. I just used apm star --installed to automatically star all my installed packages, and you can install them with apm stars --user mattandrews --install which will give you all my packages (there are a couple of misc extra ones not listed here, FYI). Thanks Kevin!