The BBC is a pretty large organisation. Today it employs around 20,000 people (actually around 35,000 when you include part-time and fixed-term contract employees) across a huge number of divisions. The BBC Careers website typically has over 100 vacancies posted on any given day. Before I joined the BBC, I found the sheer scale of it a bit intimidating. Usually I can get an idea of what it’s like to work for a company by reading their job advertisements and their engineering blogs, but with the BBC I was almost completely clueless. In this post I hope to shed some light on what it’s like to work as a developer or tester for BBC News.

Just a small disclaimer first: from an engineering perspective, the BBC is not like most other companies — it’s more like dozens of smaller companies, each with their own engineering department, working towards a common goal. News, Sport, Programmes, iPlayer, Radio… As digital products, these are all built mostly independently of each other. I work for BBC News, so a lot of what I’ve written may not apply outside of BBC News.

Teams & projects

Note: When I say “BBC News”, I mean “BBC News and BBC World Service”. The 30 or so World Service sites run on the same Responsive News codebase as BBC News. For this reason, the World Service and News teams consider themselves to be part of the same overarching team.

There are about 6 BBC News development teams at any one time. Teams tend to form around projects which can last anywhere between a month (building a small routing service for the BBC’s RSS feeds) to 9 months (rebuilding the BBC News front page with a new technology stack). As well as developers, each team typically also has a dedicated tester, business analyst, project manager, and product owner.

In the past, teams were relatively static and people didn’t move around much between projects. More recently though, the teams have been shuffling a lot more. We don’t have a formal team rotation system in place at the moment, but it’s easy to move between teams if you want to work on something new. I’ve worked on 3 different teams over the last two years.

As well as collaboration between these BBC News teams, we also regularly collaborate with teams from all around the BBC. In the last 3 months alone, my team has worked with:

Learning & personal development

BBC staff can attend BBC Academy courses for free. There are so many courses available covering subjects across journalism, broadcasting, technology, management, and personal development — just to name a few. You can even earn a MSCS (Masters of Science in Computer Science) by completing Academy courses over a 22-month period.

We give a Pluralsight license to every new starter.

We have an office library, and an annual budget for purchasing new books.

We run a developer gathering every month where developers and testers from BBC News and other teams around the BBC give technical talks and open the floor to discussions.

We run a similar but less technical town hall every fortnight where people from all around BBC News (including editorial staff) give 5 minute lightning talks about what’s going on in their world.

There is a budget for attending external events & conferences.

Most teams have at least one dedicated learning day every two weeks where everybody is encouraged to spend their time learning something new.

On top of learning days, we encourage everybody to dedicate a couple of days each month to personal development.

We have regular personal development reviews to make sure everybody has what they need to achieve their personal goals.

Working hours & annual leave

The BBC has a “core hours” system where you are required to work between 10am and 4pm. Other than that, you can pretty much work whichever hours you like so long as you work all of your contracted hours (usually 35 hours per week). I come in at 8am every day and leave at 4pm. Some of my colleagues come in at 10am and leave at 6pm.

Working from home is common, and is done at your manager’s discretion. Many people work from home one day each week.

Overtime is actively discouraged. No project is more important than your well-being!

Taking annual leave is encouraged, with enough notice. If you work on a project with a hard deadline like an election or sporting event, your manager might ask you to avoid taking leave in the weeks leading up to the deadline, but this is not mandatory.

Working environment

All BBC News engineering staff are located in New Broadcasting House. The entire building is accessible, and has the usual amenities including showers, toilets, and tea points, which are all also accessible.

Most of the web & apps engineering teams work in an open plan office space alongside the UX teams. There’s plenty of natural light, and there are a few adjustable standing desks available. Everything is set up for hot desking, but in reality people tend to sit in the same area to work with their team.

If you find open spaces are detrimental to your productivity, there are plenty of high-backed sofas and (mostly) sound-proofed enclosures scattered around the area. There are also several semi-enclosed “train carriages” that seat up to 6 people which are great for collaborative working.

Technologies

Most of our products are web-based and are written in Ruby, JavaScript, and PHP alongside the usual HTML & CSS (usually Sass). We also have some non-web projects which tend to be written in Java and Scala. Teams have the freedom to use whichever technologies they like, provided there is sufficient justification. Here’s a sample of technologies which I’ve personally worked with so far at BBC News:

Other perks & local discounts

Being just down the road from Oxford Circus puts us somewhat dangerously close to dozens of really great shops, restaurants, cafés, and bars. Many of them offer a discount to BBC employees.

The BBC runs a centralised benefits scheme which offers things like:

Secure bike storage is available, or you can just lock your bike to the railing outside the building.

The Joel Test

Here’s how BBC News scores on The Joel Test:

  1. Do you use source control?
    Yes. We use Git for almost everything, and SVN for a very small number of legacy systems.

  2. Can you make a build in one step?
    Yes, all applications can be built in one step. Older applications have a separate deployment process, while newer applications are deployed to integration environments automatically.

  3. Do you make daily builds?
    We practice continuous integration, so there are usually hundreds of builds happening every day.

  4. Do you have a bug database?
    Yes. We aim to keep the backlog tidy, and will often close minor bugs which are not likely to be fixed.

  5. Do you fix bugs before writing new code?
    Not always. Most teams will prioritise bugs which affect more than 1% of users. Other bugs are typically left at the bottom of the backlog and eventually closed.

  6. Do you have an up-to-date schedule?
    Yes. Schedules range from broad 1-2 year goals to month-by-month feature delivery.

  7. Do you have a spec?
    We have Business Analysts who work within our teams to define specifications and acceptance criteria.

  8. Do programmers have quiet working conditions?
    Not by default, but quiet areas are available.

  9. Do you use the best tools money can buy?
    Yes.

  10. Do you have testers?
    Yes.

  11. Do new candidates write code during their interview?
    Yes.

  12. Do you do hallway usability testing?
    Yes. UI changes are reviewed by our UX teams, and Accessibility Champions are embedded in each team.