A new chapter

People keep on asking if I’m excited to be starting a new job tomorrow. Oddly, I don’t think I am.

I am keen to do well, to make a difference, to learn, and to be recognised for achievements, but it’s not translating into excitement right now. I am starting to find myself very slightly nervous, though, which I think is healthy.

It’s been a good summer. You don’t recognise, when you’re a child, what the gift of six weeks of holiday in the summer actually mean – not until it’s gone. This year, since I had a packed August full of days off, when I found a new job I asked if I might start in September rather than mid July, and I have had two months of glorious freedom, watching my savings shrink throughout.

I didn’t do everything I wanted to this summer. I never took skating lessons or sailed a dinghy across our nearby lake. But I went to the theatre a few times, I took some photographs I’m pleased with and I generally relaxed. I had planned to bone up on javascript and get more familiar with newer technology for the job, but I’ve eventually foregone that in favour of having a stress free time. Likewise I didn’t blog on the topic of work, coding, testing and websites. But that’s ok.

It all ends tomorrow and my primary regret is out of my control – for the last week I’ve been ill with a horrible cough which I’m going to be taking to the office on my first day. I’d normally take time out until fully recovered, but I’m nearly there and failing to turn up on your first day can’t be a good start.

So, I’m packing a work bag (brand new, like a Back to School weekend!), checking out my route, and wondering who I’ll meet and how it will go. One of these days I’ll let you know, too.

Leaving the BBC

I joined the BBC in 2006 after a spell of unemployment. I was nervous initially, wondering whether I’d fit in, or meet the expectations of my new colleagues, and whether my skills were strong enough. I settled in quickly though, and set to work crafting elaborate templates for editorial staff to use to produce flat HTML. After moving from a company that used an Oracle back end and embedded Perl in the web pages (in a similar way to how PHP first started embedding code), I was a bit surprised to be crafting XML as the most dynamic part of the pages we created.

One day (ha!) I’ll write up some of the many things I did in my time at the beeb, but the relevant part here is that after a long time as a dev I wasn’t finding any route forwards, and I was working at a location I hated because of the commute it imposed. Only after we moved back out of Broadcast Centre and back to the centre of London, did I recognise how much of an impact it had been having on my work life balance and mental health.

I switched roles along the way and found a voice as a respected tester who was quickly promoted to be a senior and a lead. I’ve enjoyed being part of the “leadership” of iPlayer Radio on the web, but there are many changes afoot, the most personally impactful being a relocation back to W12. As soon as that was announced I started looking for an alternative, as I’d told myself “never again” and I like to keep my promises. Especially when they’re to me!

Although I looked at both dev and test positions, it was a development role where I found success and I’m heading to GDS in the autumn. I always said that people who finish one job on Friday and start a new one on Monday are doing it wrong. I had some holidays booked for August, and my notice period expires in July, so I’m taking a summer to have fun before knuckling down – although I do want to spend a bit of time brushing up my out of date javascript.

I wrote a big handover document before I left the BBC, and I am planning to turn some of that into blog posts in the near future, so hopefully that will be of interest. Meanwhile, though, I’m doing super fun things like discovering a wasp nest in the garden and getting stung.

Maybe I’m doing it wrong…

I’m listening OR how test can be the audience advocate

As Frasier Crane was wont to say, “I’m listening”.

I’m the test lead for the iPlayer Radio websites. I get into work by 8am most days. I have my breakfast at my desk and ease into the day doing the following things:

Looking at the results of the automated tests that ran the previous night.
Catching up on email
Reading messages from angry people.

Where there are problems showing from the test automaton I investigate the causes. Software is a fickle beast and often things have timed out as the tests ran because the test environment is slow, or empty caches have cause temporary glitches, or Browserstack decided not to listen when we called it. Sometimes we find actual bugs and I’ll spend some time isolating the problem in order to raise a bug ticket. If we’re lucky there will be nothing to report and the tests will all be green.

Reading email informs me of the state of the product, the team, the department and the company. It contains details of deployed code, Jira ticket state changes and plans for future direction. I flag things that will need follow up action such as requests from my line manager or pull requests that need a code review, and I check my schedule for the day.

The “angry” people are also found in my inbox, collected together in reports from the people who manage our audience feedback. I subscribed to these lists in order to see first hand responses from the audience before it gets filtered through more people or deprioritised out of existence due to more pressing concerns. There isn’t always time to get through it and when I’m otherwise busy I may skip this part of my routine. I try to leave them unread if I haven’t glanced through it. Why? Because I want to know where our products are failing, and ideally I want to know early. One of the core principles of working for the BBC is accepting that “The audience is at the heart of everything we do,” and yet only a few of us see the direct messages they send for our consideration. To my mind, this insight is all part of promoting quality and it can cover both the functional failures and areas where we’ve made assumptions in building that haven’t worked out for the audience.

There’s an argument to be made that says that flippantly calling them angry is at odds with that ethos, but sadly the truth is that you do need something of a thick skin to read the messages about the product you have worked on. The BBC is something of a behemoth. Nobody can tell you the answer to the question “What’s it like to work at the BBC?” because we only have experience of our own corner and departments, teams and experiences differ massively. There are thousands of workers, a multitude of departments, and even the website isn’t run, as many think, by “a” coding team so we don’t necessarily know what the rest of the web teams are doing. As such, sometimes things aren’t as joined up as they might be, and for an audience member it’s quite difficult to submit a complaint or comment using the website while ensuring it will reach the right people. Sometimes the logs show that somebody started out wanting to compliment something, or make a benign comment but the prolonged and confusing route to submitting a message leaves them so incensed it turns into a complaint along the way. That aside, people who contact us are often angry because they believe that we don’t care about them, that their experience is a universal one, and that their problem could be easily fixed if only we weren’t such idiots. We are accused of being incompetent, called derogatory names and belittled in many of the messages we receive. Not all, by any means, and I can’t imagine we’re unique in this.

That aside, it is still good to consume these reports. Sometimes people have a good understanding of what’s going wrong and submit a message akin to a thoroughly researched bug report explaining the workarounds they’ve found, the exact time the issue started for them, or details of things they’re tried with or without success. Others are less helpful, simply reporting things like “I wanted to let you know the radioplayer doesn’t work now” – we don’t know what doesn’t work, under what circumstances, or whether it has ever worked for this user. All the same, even that can be helpful if we see a number of similar reports around the same time.

And then there are the times when a sole user alerts us to something we’d missed. It’s something that, as a single report, might take a little while to filter through to the devs, but with the team’s eyes directly on it we’re able to recognise things that look odd and investigate further, and if there’s a real issue we can step up and turn around a fix very quickly. My colleague, our tech lead, Alex, wrote about one such instance at length in his own blog post recently: https://medium.com/@alexgisby/on-live-incidents-and-process-ee7a4d83c5f7

We spotted another issue recently whereby the pop out player, the main interface on our website for listening to content on a desktop machine, had stopped autoplaying – again, this was initially an issue we saw in the logs, and through our own testing and investigation we were able to confirm that it was not, as initially though, a problem on Firefox for the PC only, but it was related to the very latest version of Firefox that had been drip fed into the wild during that week. We worked out where in the code the failure was and alerted the team who was able to do something to mitigate against it. A full fix will come later but in the meantime we were able to feed back to the audience facing staff that for the majority of users there were workarounds: the two main ones being to use an alternative browser, or to press the play button after the window popped up. It might sound ridiculously obvious but our own behaviour revealed that it wasn’t. Having the autoplay just work was such an entrenched idea for our own team that we sat there dumbfounded when it didn’t, and just stared at the “loading” message wondering how long it would be there. We discovered that a large number of people facing the issue were able to work out for themselves that pressing the play button worked, since there was no noticeable drop in the number of connections on that browser from prior to the rollout. For us, and for the audience members who were regular users of the software, our immediate conclusion was “its broken” and many wrote in to say so.

This was another area where I intervened. From viewing the logs I was able to see the standard response that was being sent out to our users after the workarounds were discovered and I was a little stunned to note that while we offered two options as workarounds, the first was to use an alternate browser and the second was to press the play button. I pointed out that we ought to offer the path of least resistance as the first option and that downloading and installing new software, or even switching to software you have but don’t prefer is a far more jarring experience than simply pressing play. While we planned to switch the message around, the fix came in in the meantime and it wasn’t necessary, but the point stands: our team is empowered to make decisions and champion them, from fixing bugs in code, to optimising the audience experience outside of it.

One of the most rewarding parts of working at the BBC is to be able to step beyond the standard definition of your job role and get involved in other areas where you can see a way to add value. Keeping that finger on the pulse and direct line to the audience lets us enhance the quality of our product.