What’s the point of hiring junior developers? Joseph Wynn, a former Principal Software Engineer in the BBC News website team shared the following thoughts on Twitter recently:
As a junior-level developer myself, I was quite encouraged to read that. It made me reflect on my time at BBC Design & Engineering since I started in September 2016.
I’m currently on the BBC’s Software Engineering Graduate Scheme, which is a two year long scheme for anyone who has a Computer Science related degree. The scheme is a great way to enter the BBC as a junior-level Software Engineer, but with the added bonus of being able to move to a different team every six months with opportunities to grow a variety of technical and soft skills. I have recently finished my first year in scheme, where I served in BBC Sport’s services team and BBC Children’s responsive website team.
I don’t think there is any other scheme like this in the world that allows you to get Web development, mobile and Smart TV app development, backend service development and embedded systems development under your belt in the space of two years in the same organisation; all while getting to know some pretty amazing people and highly skilled teams along the way.
A bad first impression
During my time at Uni, I’d worked in two digital agencies — one as an unpaid summer placement and one for a sandwich year. Both gave me real hands on experience, but both followed a strict waterfall process and I very much felt like a cog in a small machine, locked to my chair and unable to chat or stand up unless it was to pop to the toilet or have lunch. It was quite a draining experience to work for them. I’d always been passionate about Web development, but my time there caused me to worry that I might not actually enjoy it as a profession.
So unsurprisingly, I wanted to make sure that my first job post-university would be somewhere where I would feel happy and work not on my own, but with an agile team who love what they do and care about quality.
I had high expectations when I applied for the BBC and, to my surprise, it was exactly how I imagined to be. I found the culture to be very relaxed and supportive, and I certainly didn’t feel like a cog in a machine locked to my seat. I was a junior-level developer, but no one expected too much or assumed too little of me. No manager assumed I could just be placed on a project, instantly understand its system and start churning out code. My input was valued, and my team were invested in helping and developing each other equally.
Creating the right culture
Recruiting experienced software developers is difficult — even for a large trusted brand like the BBC. But experienced developers have to come from somewhere, right? They were all at a junior level once! When many businesses in our industry are so unwilling to take on and nurture junior staff, we shouldn’t be surprised that software teams are struggling to hire senior developers. But as we’ve already seen, there is so much value in having a junior developer on a team.
Culture is the key to ensuring that junior staff (and more senior staff) can grow and flourish in an organisation, thereby benefiting the organisation in return.
There’s a lot of history behind how the BBC has evolved into the workplace it is today, but much of this stems from our values.
Let’s have a look at each of these values and see how they impact digital teams at the BBC.
We are one BBC; great things happen when we WORK TOGETHER.
If there’s one word I hear a lot in BBC Design & Engineering teams, it’s ‘communication’. We have many tools and processes to provoke discussion and make sure we all know and agree on what we’re doing. And for developers in particular, it’s important for us to not feel shy or incompetent for needing to ask for advice. In the teams that I’ve worked in, we always remark in retrospective meetings how good it is that we so regularly talk to one another to discuss our approaches to solving problems or ask for help. Everyone is always willing to stop what they’re doing and offer their time to help.
Likewise, many teams at the BBC practise pair programming, which is a fantastic way of sharing knowledge and keeping up code quality. I always find it keeps me more focused compared to working on my own, because I’m having to convey my thoughts out loud.
Of course, it’s not just developers that I’m working with. There are many types of roles in a digital team and each of them have a key part to play in our work. It’s even in the Agile Manifesto, where we read ‘Business people and developers must work together daily throughout the project’. There have been many times where I’ve been fortunate enough to sit with Business Analysts to help flesh out a ticket’s acceptance criteria or work with User Experience Designers to prototype their ideas. Even having the opportunity to do that as a junior-level developer makes me feel valued.
‘The most efficient and effective method of conveying information to and within a development team is face-to-face conversation’.
Finally, one of the main reasons why digital teams like to have developers from the graduate scheme is because it allows for ‘cross-pollination’. As we switch to different teams every six months, we bring with us experiences of the processes, approaches and technical knowledge of the teams that we have previously worked in. Teams risk becoming ‘silos’ if we don’t communicate with other teams across the BBC to share knowledge and see how and why they do things differently to ourselves.
We RESPECT each other and celebrate our diversity so that everyone can give their best.
Even though the BBC is a hierarchically structured organisation, it can actually feel quite flat. No matter whether someone is a senior or a junior, their opinion is valued and listened to. This attitude affects both the big decisions that are to be made and the general day-to-day work. It also affects how we interact with one another. No senior manager in the BBC has their own office; everyone sits together and everyone is able to approach one another equally (the Director General even shook my hand once! 😲).
Even when pair programming with a senior developer, a junior developer is not simply watching their counterpart do the work. Their lack of familiarity with the system means they are able to think from a different perspective and ask questions, so they should be encouraged to think out loud and voice their opinions.
I think GDS’s ‘It’s ok to…’ poster applies very well to the BBC as well. Often for a junior developer in a large organisation, it is easy for them to imagine that their team have lofty expectations of what they are capable of doing, when that is not really the case.
The saying ‘there’s no such thing as a stupid question’ also applies here. Asking questions is encouraged, and it’s not unusual for more senior members of the team to ask questions just for the sake of junior developers or new developers in the team.
CREATIVITY is the lifeblood of the organisation.
Software development is a creative process. There can be hundreds of different ways to accomplish the same thing, and teams need to work together to discuss the best method for approaching a problem. New developers will bring in an outside perspective and are less likely to be set in their ways about ‘how we normally do things around here’. To embrace this, it’s important to have a culture that takes everyone’s thoughts equally into consideration.
Developers are not only expected to do their day-to-day work, but are also expected to be learning. Many teams implement ‘10% time’ where time is allocated to learn something new or work on a relevant side project. An organisation that is willing to invest in the growth of its creative teams makes them more likely to stay in the organisation long term. Junior developers should be set learning objectives to encourage them to specialise in different technologies and soft skills.
We take pride in delivering QUALITY and value for money.
User research, pair programming, code reviews, automated testing and manual testing are all processes that ensure we are delivering a quality product to our audiences, and it’s important for junior developers to have involvement in each of these. They should not only be receiving feedback, but giving feedback as well.
AUDIENCES are at the heart of everything we do.
At the BBC, the products we work on are made entirely for the purpose of educating, informing and delighting our audience without any motives to monetise them. But regardless of the needs of your organisation, the needs of your user should always come first. It is still important to understand and serve your audience so that they see a value in using your product.
When I was in the Children’s Web team, the Children’s UX team would often invite local kids to evaluate our ideas and prototypes, and developers were encouraged to attend and observe for themselves how the children reacted to various prototypes. We would often push out quick prototypes in A/B tests and our team’s Business Analysts would evaluate whether our changes affected user behaviour the way we expected.
TRUST is the foundation of the BBC; we are independent, impartial and honest.
There is nothing worse than a work environment where managers don’t trust their teams. There’s a reason why this value is at the top of the list on the back of our ID badges! Just as our audiences need to trust our content, we need to be able to trust one another. This is the core tenet of our culture. Without this, you cannot feel happy, settled and enabled to fulfil the rest of the values.
Junior developers, like everyone else in a digital team, are trusted to manage their time, work independently, have permissions to access all of our development environments and APIs and help and train newer members of the team. Likewise, we don’t point the blame at someone if they mess up; we trust them and assume they have the best intentions with every action they take (and hopefully we don’t have any systems that can be taken down with one accidental command line operation).
While it’s fantastic that junior developers are given a platform at the BBC to grow such a wide skill set, this counts for nothing unless the teams have a culture that give attention to the value that less experienced developers provide and a desire to build them up. Have you thought about how the values at your organisation help developers to grow?