The Guardian Digital Department has worked with our Education Centre to deliver a new educational programme, the Guardian Coding Workshop.
Set up by the department’s diversity group, the workshop aimed to introduce people from lower socio-economic backgrounds to the tech industry. Attendees were recruited through the Guardian’s community partners like the Copenhagen Youth Project, and charities like Generating Genius and the Social Mobility Foundation. Ages ranged from 17 to 26, including sixth-form students and people in full-time employment.
While there are many technical courses, workshops, and meetups available throughout London, they mostly focus on young children or people who already know the basics. Courses and bootcamps that do offer free opportunities for adults are often incompatible with working life. This means they are only practically available to people who have the financial security to live without working for long stretches of time. The aim of our workshop was to get people started by removing the barriers of the availability of a space for learning, access to computers, the cost of eating while attending a course and conflicts between course times and working life.
Figuring out what to teach
This was challenging. We had four developers from the department volunteer to decide what we should teach. Involved were Gareth Trufitt, Susie Coleman, Max Spencer and Natalia Baltazar. We met up for an average of two hours every other week. As Susie wasn’t able to teach on the day, Jon Norman stepped in to mentor, and help finish off the workshop.
As no one had experience developing a curriculum, we struggled. The only things we accomplished in the first few months was coming up with who would attend the workshop, and which language we would teach.
Two months away from the workshop, still undecided about what would be taught, we finally decided to instead adapt an existing curriculum. Natalia reached out to Gregory Loyse who used to teach Python at City Lit in London. Using his original curriculum as a starting point we all dived in, changing it to suit our needs.

The most important thing for us was to replace the majority of the technical language, especially for the first day. The last thing we wanted to do is overwhelm students using terminology they wouldn’t know yet. The technical terms we did keep we made sure to explain as plainly as possible. We ran sections of the course with non-coders and updated the language and exercises where things were confusing.
It was also important that there were lots of small activities or challenges throughout the day to keep people engaged. We spent much of our time creating small programming problems. It was important to challenge the students, but not introduce too many new concepts at once.
The next problem to solve was how we wanted to start each day. Since our goal was to show the students what it feels like to work as a developer, we didn’t want them just sitting at the computer all day. It was essential that we also had them collaborate with each other. For this reason we created two offline morning challenges.
Another addition to the workshop is that two volunteers each day with different positions in the department come down and present a quick talk on their job, and how they got to where they are now. The goal of these quick talks was to demonstrate the diversity of ways people who work in tech have entered the field.

In the end it all came together and we felt good about what we had accomplished. By now the pain and stress of developing the curriculum has just about faded. Maybe we will even do it all over again next year.
What was the course like to teach?
When the students arrived in the morning, it was great to see that they were as excited to be there as we were. After making our introductions and getting everyone set up, we jumped into the workshop, starting with our offline challenges.
We designed these challenges to work as both fun ice-breakers for the students to play around with and as pointers toward the problems we’d be tackling programmatically later on.
One challenge involved the students using a restricted set of instructions to guide a turtle figure through various mazes on a grid. This went down really well and the final task - constructing a maze to be solved by the other teams - injected a (probably) healthy dose of competition into the mix.

During the challenges and the course, we encouraged the students to work in pairs or small groups as much as possible. Working in this way meant that each student had someone on their level that they could ask for help and it generated a lot of self-led discussion throughout the workshop. As mentors, it was often tempting to jump in and provide the answers, but letting the discussion play out naturally led to a far more fluid and rich learning experience.
The talks from volunteers across the Guardian digital team demonstrated to the students just how varied the roles can get within technology and led to some great discussions around how to get into those areas. Talking with the students afterwards also helped us to understand more about what they wanted to do and where their interests might lie.
Overall, the students were really keen to learn as much as they could during the workshop and patiently worked through a lot of the material we’d prepared. Unsurprisingly, it turns out that teaching the fundamentals of programming in three days is quite difficult, but the students seemed happy with the variety of the content and made a lot of progress regardless.
From our perspective, it was really refreshing to see people learning the concepts we are now so familiar with and grappling with them in entirely novel and insightful ways. It was a lot of work and there are of course areas that we can improve, but we think that each student left with a better idea of what being a developer is like and the possibilities open to them.