Providing opportunities to learn coding, regardless of background or job title improves diversity

The Government Digital Service (GDS) employs a lot of people who write software for a living, and a lot of people who don’t.

Not everyone needs to know how to code to do their job, but many people would like to learn if they had the chance.

GDS’s purpose is to help government work better for everyone.

That means a diverse group of people need to be able to participate in conversations about technology and digital government.

Providing opportunities to learn technical skills like coding, regardless of background or job title, helps bring more diversity into our discussions and helps us make decisions that better reflect the society we serve.

We recently ran a series of learning sessions where we taught people who’d never written any code before how to build a simple website using Ruby, HTML and CSS.

‘Making coding more accessible’ at the GDS unconference

In April, GDS ran an all-staff unconference where colleagues were invited to suggest things to talk about. 

Among many other things, we discussed how spreading knowledge of coding across the organisation could help build empathy between teams and roles, and make people more productive. And how it could help empower a more diverse group of people to get involved in technology.

Many people learn to code in their own time, but expecting people to do so creates a hidden kind of discrimination: if you have family to look after or personal commitments in you free time, then you can’t spend it learning.

Ben, a product manager at GDS, told us: “I’d love to learn more about coding but have zero time outside of work…”

If we’re serious about improving the diversity of people who are included in discussions about technology and digital government, then we need to make sure everyone has the chance to learn, regardless of their background.

Following the discussions we held at the unconference, we came up with the idea of ‘learning to code’ sessions at GDS.

Learning from the community

We knew that the Civil Service and the wider community had done similar things before. Several departments run coffee & code sessions, a group at Defra have been running a ‘learn to code’ beta, and many GDS colleagues help out with codebar (which GDS occasionally hosts). In the community, initiatives like codebar, Rails Girls, Django Girls and Node Girls help people from underrepresented backgrounds learn and participate.

What we did and how we did it

We had the big vision of ‘making coding accessible’ – now to implement it within 3 months.

This is where our experience of working on an agile development team came in handy as we applied the following principles. 

Agree a goal and narrow the scope of work

Coding isn’t just a skill – it’s a whole new world, which meant an ‘introduction’ to coding presented endless options. Do we want them to be able to build a thing? Understand the web? Learn a programming language? 

We decided that our goal was for students to get a feel for coding – simple as that. This might sound woolly but we didn’t want to set the expectation that people had to finish building something in order to achieve success from these sessions. 

Define our users

Luckily, we have a large community of software engineers to volunteer as coaches. We prioritised female colleagues and colleagues from ethnic minority backgrounds to attend as students. These demographics are the most underrepresented in tech. And although this is also a known issue at GDS, we were happy to see that many of the coaches who took part in the pilot were actually from the underrepresented groups.  

Work together in the open 

Keeping each other in the loop on all of our ideas and tasks was important to us, so we discussed progress on a weekly basis. This kept us on the same page and set a nice cadence to keep things moving. 

There was no point in reinventing the wheel. We talked to GDS codebar volunteers to get ideas on session format, and we crowdsourced ideas from other software engineers on what content to include. The coaches collaborated on the content for the lessons using GitHub and we discussed our plans for the lessons on Slack. 

Iterate, iterate, iterate

We pitched the course as a pilot (or an alpha, if you will). This gave us the breathing space to make mistakes, test things out and have a starting point for feedback.

There was a mini retrospective of what worked well and less well at the end of each session to help improve the next session. 

Feedback from the sessions and our survey responses will inform how we run the course next time. 

What our students did

There’s lots of excellent educational material on learning to code available under a Creative Commons licence. We based our content on the codebar tutorials and JumpstartLab’s Ruby in 100 Minutes, but we adapted the content to feel a bit more familiar to civil servants.

Our students built an ‘Apply for a barking permit’ website – something a bit silly, but still familiar to those of us working on digital services for government. You can find our ‘learn to code’ tutorials published on the web.

In 3 one-hour sessions, we paired students with coaches and let them work through the tutorials. The coaches were asked to follow the codebar effective teacher guide, which asks you to:

• explain that it’s ok to make mistakes
• let students have a go at answering the questions first
• use pen and paper or go to a whiteboard
• take it slow

People worked really hard, and it was amazing to see just how much progress they made in such a short time.

In keeping with GDS tradition, we got some stickers printed to celebrate the end of our pilot. 

How it went for the organisers

Hong: “As a delivery manager, I consider myself a non-technical person working on a very technical team at GDS.  The team members are inclusive, supportive and lovely but sometimes I find the work intellectually intimidating and ostracising.

Taking part in the sessions as a student gave me a fresh perspective on my own role as well as elevating my respect for theirs. I have a greater understanding of the need to limit ‘context switching’: coding took so much of my energy and focus. Also, the nature of coding itself requires you to be clear, structured and logical, so I’ll be more conscientious in how I communicate work to my team. 

Overall, the sessions were super fun, the atmosphere was great, and it reinvigorated the joy I have for working at GDS, where empathy is at the centre of our work.”

Richard: “I’m a senior developer and the technical lead of a complex product at GDS (GOV.UK Platform as a Service). Like many developers, I sometimes assume that people will magically understand technical words and concepts that a non-developer would have no reason to know. Coaching people who’d never written code before helped me understand how other people see what we do, and build empathy with my colleagues.

At the same time, I was really impressed with how quickly people learned – in less than 3 hours, they were able to understand the abstract concepts of computer programming well enough to build a simple web application. It was enormous fun watching people learn, make mistakes, and work through them.”

Feedback from our coaches and students 

Anonymous student: “It was eye-opening in ways that I did not expect. It was like going for a lunchtime walk through a Japanese park (complex, elegant, beautiful and on the other side of the planet)!”

Syed Bokhari – delivery manager: “Great fun, very informative and well run! I have even greater respect for the work that our fantastic developers do!”

Andy Hunt – reliability engineer: “It was fantastic to see how quickly students understood the material and began developing new skills. I think it’s proof that anyone, of any age, can learn to code.”

Emily Young – security analyst: “I’ve never really taught anyone before, and the joy you get from sharing something that’s important to you and seeing a student succeed is really quite wonderful.”