As we did last year, we held our first RailsBridge of the year as part of Rubyfuza. Big, big, thanks to Rubyfuza for sponsoring the venue and the food! 🙌
I had the chance to chat to Coraline (squee!), of the RailsBridge board, on the day about how we run our workshops. The things that we do that are more than just what you read in the docs. The extra bits that we add to try and help create a nicer learning environment.
The first change we make is that we run a one day Saturday workshop: no InstallFest on the Friday night. Running one a half days has proved tricky to get enough teachers and sponsorship. More importantly, many of attendees come via public transport. Asking them to pay for two trips to the venue is not so great, and expecting them to go home late on a Friday is simply not safe for them.
The downside of this change is that people have to spend some of the morning doing the InstallFest. We think the trade-off of reaching a wider audience is worth it, so we try and help people through the InstallFest a little more than we would otherwise. We’ve talked about using VMs or Docker, but they both feel like they add another abstraction and barrier to getting down to the actual business of coding.
The shape of the day
The shape of each piece changes a little each time, but the main shape of mixing workshopping with (learning- and learner- focused) activities is the same.
- Introduction activity. Share your answers.
- We print out and laminate the steps for the activity: we put them on the wall so that people don’t have to remember what each step is. This activity gets students thinking about their own goals for the day, and it gets them to talk to some other learners in the room. We do this as people arrive, to soak up time waiting for the rest of the group.
- Opening presentation.
- I’m a fan of minimalism and presentation-zen-like slides, so we use a simplified, fewer-words-more-pictures, presentation to start the day with (rather than the upstream standard one in Materials for organisers). The content of this is based on attendee feedback: they wanted an overview of the course and how the pieces fit together. At the start of the presentation we talk about the text editor for writing code, the terminal for issuing commands, and the browser for seeing the results of your work. In the middle of it, we stop and take a walk (to get attendees moving and listening) to a wall for a Technology Intro thing.
- Technology Intro. We talk through the technologies that the students will be using on the day, formed as a bit of a Q & A.
- Workshop. Attendees work through the docs at their own pace, with mentors hovering around in case they want some help.
- Mid-morning break.
- Lightning talk. This time, Dani gave her great talk on becoming a developer.
- We added a lightning talk as a break, based on attendee feedback. We found that without a break people powered through the day and ended up overtired at the end. They also said that they wanted to hear more from people in developer jobs: they chatted to them during the day, but they wanted more. We combined these two things by having a lightning talk by a developer!
- Afternoon activity. Three most important things.
- This activity gets people moving after the post-lunch slump, talking to each other, and reflecting on what they’ve learned so far. As with the other activities, we put laminated A4 things up on the wall so that people don’t have to remember a bunch of instructions.
- Afternoon break.
- Afternoon activity. Hey buddy. We ask the attendees to set themselves a SMART goal.
- We’ve noticed that people end the course at different times, so having a closing activity right at the end of the day means some people miss out. To try and have everyone doing the activity at the same time, we’ve moved it up to the afternoon break.
- We explain SMART and why it’s better than a vague, non-specific goal. Then we ask them to exchange contact details with someone else in the room, with the promise to follow up in one week. The thinking behind this is that by telling someone about their goal, they’re slightly more likely to actually do it. On top of that, their SMART goal buddy will follow up with them in a few day’s time, giving them an additional nudge to keep going.
- Feedback activity. Short, anonymous, survey.
- We’ve added and removed the survey a few times. We’ve had lots of questions, we’ve had few questions. When we’ve removed it, we’ve replaced it with an activity that focuses on the students. The thinking was that the feedback is for us, and the workshop should be all about them. However, it is useful to gather feedback so that we can improve the workshop. For this one, we added it back with just two questions. It’s anonymous, so we hope people tell us the truth!
- What was the best thing about the workshop?
- What could we do differently for the next workshop?
- Close. Stickers for everyone! 🎉