My First 6 Months

My name is Zephaniah Flynn and I am a Software Engineer and a proud member of the Radio and Music Services team (RMS) at the BBC. For those starting your software engineering/development journey, whether you’re a recent graduate or perhaps looking into a career change, here’s a look into my first 6 months and some of the challenges I had to overcome. Hopefully it’ll give you an insight into the life of a software engineer.

My technical background includes experience in: Advanced Scala, Akka-http, Akka-streams, MySQL, PostgreSQL, Java, AWS, CI, MongoDB, Play! Framework, cloud computing, technical architectural design, RestFul APIs, TDD and much more! Before starting at the BBC, I had around 18 months experience using the Scala programming language. My other skills at the time included building Restful APIs, Jenkins and a small amount of front-end experience, although I considered myself primarily as a backend engineer. Anyway, that’s enough about me — let’s get on to the juicy bits!

First challenge

I decided to dive straight in and one of my first tasks was to create a new endpoint for one of my team’s APIs. In the RMS team, it’s our job to provide metadata through our APIs to the client teams for BBC Sounds. To say I was suffering first day jitters was an understatement, and I had numerous things running through my mind, but I was ready to deal with whatever came my way.

The first Jira ticket I picked up read “Create polling endpoint for summary version of broadcasts”. Let’s break this down:

· Create polling endpoint: This indicated that the new endpoint would be built from scratch and would serve as a new feature for the client team.

· Summary version: This indicates that the endpoint will respond with a JSON response that consists of a new object that is similar to a current one but only provide the essential metadata needed for the functionality to work.

· Broadcasts: If you navigate to https://www.bbc.co.uk/sounds/play/live:bbc_1xtra you will see what is currently on-air and what is next. This is the current outcome of this ticket and displays a short summary of what broadcasts are up next.

The reason why all this was requested in the first place is because here in the RMS team at the BBC we prioritise YOU — our lovely viewers and listeners alike. We want to supply your daily radio fix without consuming loads of your valuable data.

For instance, the original endpoint, used by the web (your internet browser) responded with a file that was around 6–8kb with a response time of 200–250ms and we lowered this to 1KB with a response time of 100–150ms. The original size and response time doesn’t sound a lot but imagine every time you select a network, or listen to something else it takes up nearly 6 times as much data than it would have - it stacks up! Just like every time you order a cheeky takeaway, the money slowly leaves your account.

Firstly, I had to work out how my team’s architecture worked and what components provided our clients with the data they needed. So I will break this down in terms of my first ticket.

I had to understand their domain with objects like a broadcast, playable item and a programme. Here is an example of a broadcast object in JSON:

Here you can see I had to close the programme attribute, as it is too big to display in this section and emphasises why the current broadcast object is too big — the programme object has about 100 name/value pairs.

Secondly, I had to understand the CI pipeline and the architecture. However, I didn’t have to fully understand the implemented infrastructure from top to bottom as it wasn’t 100% necessary for this task and I wouldn’t have enough time to study it all. As long as you can get started and implement in a way that is of a good enough standard for the team, that’s all you need to worry about. Having knowledge of the whole picture comes with experience and that will grow over time.

Imagine having to learn the whole domain of BBC Sounds — that includes hundreds of different types of objects each with their own versions. This domain is always expanding as new features are introduced and is challenging to manage and learn at first. All of this effects what is expected on client side and is really hard to deal with when it comes to serialisation and deserialisation of JSON responses. However, we are looking into different libraries that will help manage this automatically, like refined types and type class deviation.

In hindsight, I found that my first task was a good starting point as I gained familiarity with the domain, some of the infrastructure and the use cases related to the task, and somehow I completely it successfully! The response times were low (averaging at 30ms) the JSON response was smaller in file size which was perfect for the mobile team. Here is an example of the shorted broadcast object which we named “broadcast_summary:

I was delighted with the work I produced, even if it was my first ticket, and it very satisfying to see the work actually being used. It is also now being used by millions of people and I can take pride in that, as well as everyone working within BBC Sounds.

Since then…

I have worked on several other areas of which include other RMS features, engineering improvements, hack days and general maintenance of our services. Some of these tasks include:

· Adding caching to our broadcast service

· Auditing for GDPR

· Adding support for personalisation in multiple services

· Search API Improvements for clients

· Investigating response time problems

· Making improvements to our infrastructure

Personally, I prefer development tasks to bug fixing, investigations or other slight improvements. Coding is the highlight of my job, knowing you can go away and produce something for the business to use is very exciting for me. Also knowing I can go to work and do what I love is an experience everyone needs to have at some stage of his or her life. I am just grateful I have had the opportunity to feel like this at this stage in my career.

If you’re interested, here are some of the different technologies we use in RMS:

Reflecting on my first six months

I have come a long way from my first ticket back in April 2018 and I can honestly say the experience working with the RMS team at the BBC has developed and improved my skills as a Software Engineer.

As a Software Engineer you are always learning. There are a ton of things to learn, at the same time there always new developments you need to be across, whether it be different technologies, programming languages and/or new paradigms to help find resolutions for daily tech challenges.

With experience I have learned how to deal with a diverse set of bugs, think of solutions to a required feature or to increase efficiency and reduce cost across our infrastructure.

Between all the ups and downs — another late nighter or that ‘just give me another hour’ midweek feeling, as well as the gained experience — I have hopefully gained the respect of my colleges and trust from the more experienced and senior developers on my team. So when going into a new working environment, don’t worry about the things you haven’t learnt yet. As long as you dedicate time to continuous learning to further the skills you need to improve your coding and technical ability, just commit to working as hard as possible it will come together eventually.

Future aspirations…

My Tech leads and I have set tasks I must accomplish and this includes the implementation of a new service. This service will need an improved architecture, several stages of implementation and maintenance. As I am striving to be a senior engineer, I would have to own a service and this is the task that will take me there!

Overall, I have enjoyed my time so far at the BBC, it’s a wonderful place to work and I can’t help but feel very accomplished with the work I have done, knowing MILLIONS of people rely on the services we deliver… absolutely mind blowing.