The scoop
Rails Girls is a day-and-a-half long semi-annual pro bono event dedicated to introducing the world of software development to women of all ages and all walks of life. Say that three times.
Demand for such workshops is always high, and there’s no easy way of sorting attendance. Previous attempts at short listing applications based on results from a questionnaire sent out to initial registrants has proven inefficient. So, for all intents and purposes, it is first come first serve with 100 available slots for attendees and 50 for instructors.
This is my second time volunteering as an instructor, so I decided to share some of my experiences and takeaways now that the event is over and I’ve had enough time to reflect on how both times went.
An overview of how the workshop unfolds
As a team of three, an instructor and two attendees go through a predetermined workshop tutorial and explore a variety of different tools, tasks and technologies along the way. The workshop covers, but is not limited to, an introduction to HTML, some CSS, with the main project revolving around a simple Ruby based web application.
Having to explain all of these different and unfamiliar to newcomers technologies certainly looks scary (and it totally is the first time), but the key to success is to go well prepared and don’t freak out if things start going south.
Certain areas of the workshop tutorial are not explained in enough details, so instructors are also tasked to teach them through the use of metaphors, mnemonics, and real world examples, then apply them in practice.
End game
Rails Girls aims to boost confidence and engagement for all participants - attendees and instructors alike.
Show your work group that it’s okay to fail and things in programming don’t always work out right on the first try.
Trial and error is part of the journey and should not be discouraging to beginners.
Working in IT has a lot of advantages and long gone are the days of programmers working out of their basements, occasionally surfacing for pizza and sodas.
It’s not realistic to expect that attendees will walk out of the workshop with a solid understanding of everything they’ve tried out over the last couple of days. Your goal as an instructor is to keep them motivated and eager to try out other new things even after the event is over.
Workshop rundown
The first day of Rails Girls is pretty short - it’s more of a half day warm up after work hours. That’s not a lot of time to get something big done, especially after opening keynotes, ice breakers, and what not. Still, it’s usually enough to set the stage for day two when most of the coding happens.
Speaking of setting things up, there are two notable improvements to the event that have been introduced over its previous editions:
-
Dropping local development setup in favor of a cloud based all in one solution (c9.io in our case). This greatly cuts down on windup time, as there’s barely any time wasted on getting a dev environment ready.
-
Switching from Rails to Sinatra. This might seem counter intuitive at first, given that Rails is part of the event name, but not having to explain databases, MVC, and Rails black magic in general makes things a lot easier.
I really like the way the event organizers explained this change to attendees without getting into too much detail about either framework.
“Imagine that Rails is a car, and Sinatra is a bike. They both do the same thing - get you from one place to another. A car is much more convenient, but not as effective and easy to learn than a bike. If you don’t want to waste too much time to get a simple task done, you’ll hop on your bike instead of getting your car out of the garage. Sinatra is our bike.”
A key point of the whole event is knowing when and how much it is worth explaining. After all, the idea is to give attendees a glimpse of what doing software development feels like, and not necessarily try to teach anyone something in specific.
The main topics covered in day one include a console usage crash course, basics of HTML and a brief introduction to CSS. I usually manage to squeeze in some general talk about software development, and an overview of how tasks are structured within a real life working team.
A good first exercise is a simple ‘about me’ static website. It doesn’t take a lot of time to build, and is also easy for attendees to relate to and personalize. If time allows it, we move the source to GitHub pages, so the site can be accessed from anywhere.
My personal observations show that this is the first major achievement for attendees. After just an hour or so into the workshop, they’ve already created their own website, personalized it, and hosted it on the Internet. And this really seems to spark their interest outside of Rails Girls. Three of my attendees said they received a lot of praise after sharing their first result from the workshop with their friends and family. Good vibes all around, and that’s just the first day.
Day 2:
Day two is when things get more serious. It’s mostly a full day at the event venue, with the majority of the time spent coding and debugging.
We first start by wrapping up whatever is left from the previous day before the lunch break.
Things then move to actual coding with an introduction to Ruby and IRB. A couple of hours are dedicated to playing around with strings and integers, exercising loops, methods, and conditionals.
We then move to Sinatra and start building the voting application.
The framework is simple enough to navigate and for what we use it at Rails Girls, there is a very distinct pattern of adding in a new do/end code block to the main app file, linking it to a new view and adding the necessary content to it.
Aside from the main pages, there are a couple of conditional blocks thrown in and a few string interpolations for good measure. You can take a look at the source here.
That about sums up the core part of Rails Girls. Depending on how the event goes, additional features can be added to the application, or you can switch to something else that might have sparked the interest of attendees.
The event comes to an end with a round of lightning talks followed by a very casual afterparty where you can grab a drink or two and hang out with the rest of the instructors and attendees, discuss how the event went and have a well deserved celebration.
My takeaways
My first time as an instructor at Rails Girls went okay, although there were a few things I could have done a bit better. The second one went excellent, though, and I’m pretty happy with the lessons learned in between.
Here are some of my key takeaways from both events in no particular order:
You are dealing with someone else’s time, so make sure the event is worth it
Rails Girls spans two days, and that’s a significant amount of time people are investing into a single workshop.
A lot of the attendees need to skip work or family time to attend, so make sure their time doesn’t go to waste.
The first couple of hours are usually enough to get a good idea of how your study group imagines the workshop will go, so be flexible and try to match their expectations as best as you can.
Otherwise, all that time spent at the venue might not be worth it for both. But more on that later.
Whatever keeps attendees motivated is what works best, really.
Be well prepared
Knowing a little bit about your attendees ahead of the event goes a long way.
The event organizers send all instructors basic information about their attendees, such as prior experience in IT, overall level of computer skills, and some details of their life, such as job and/or field if study.
Use this to your advantage and try to come up with common topics that would help you bridge the gap between what your attendees know and what you’re trying to show them.
Email attendees in advance, go through their registration entries and try to figure out if they have any experience with anything and/or what would they be the most interested in during the workshop. Ask them what their occupation is and try to come up with examples and metaphors that would be close to their realm.
Throw your initial expectations out the window
Teaching is not a familiar area to most of the instructors at Rails Girls, so it’s understandable that people who are volunteering for the first time might have predefined expectations about how the event may or may not go.
Some people expect that everything will go according to plan and they’ll stick to the workshop tutorial.
Others freak out that things might totally go overboard and their attendees would start asking them questions that are outside of the exercises.
The only valid expectation is to think that your attendees have zero knowledge about programming and infinite potential to learn all about it.
The truth is that the way Rails Girls will unfold depends on you and you only.
Some attendees prefer to try and work through the tutorial on their own and only ask for help if they get stuck along the way. Others need a lot more hand holding and explaining to keep them focused. One of the attendees I had wasn’t even all that interested in trying the actual application development part (basically, everything covered in day two) - she just wanted to mingle with tech savvy people for a day and see how the vibe was. And that’s okay. That’s perfectly fine.
Whatever the situation is, your role as an instructor is to first and foremost try to identify what your attendees want out of this event, and what might keep them interested in the long run. What would be their personal best for Rails Girls - try to get the whole app up and running, understand how the back end logic works, or just play around with images, styling, and UI. Again, this part is super critical and nailing down what your attendees expect out of those two days is make or break.
Regardless of what your work plan for Rails Girls is, the end goal is not to try and finish all of the assignments by any means.
A fellow instructor told me that midway into the workshop, one of her attendees found programming way too challenging and wanted to do to something she felt more familiar with. They ended up switching to Excel and spent the rest of the day doing pivot tables and automated reports.
Slow down
The biggest challenge for me is that everything happens very slowly and at times pacing slows down to a crawl.
That might not be a good thing for both sides, and motivation/energy will surely go down unless you steer things in a more fast paced direction. Having to skip explanations for certain things is totally fine and even advised by some of the more experienced instructors.
On the flip side, trying to rush through the whole thing as fast as you can is a guaranteed recipe for disaster. Having the example app up and running without sufficient explanation of what’s going on behind the scenes is certainly going to leave attendees clueless, confused, and probably pissed off. At the end of the day, it’s their free time you’re dealing with, so make it count.
An exercise in flexibility
In the likely event that you’ll be asked to explain something that’s outside of your comfort zone (take CSS for example, I’m not fond of styling), you can always turn this into an educational trick and show attendees how you’d approach something that’s unfamiliar to you - Stack Overflow, Codepen, or plain old documentation are your best friends. Having a list of useful sites, example links and/or small code snippets comes in handy and cuts down on unnecessary Googling around.
Another possible hurdle is the almost inevitable difference in pacing between both attendees. This can either happen right at the start - if, let’s say, one of the girls has some previous experience with HTML or programming, but the other hasn’t done anything prior.
The flip side is also possible - both attendees start at roughly the same level, but end with different pacing once they get to Ruby and Sinatra.
Both situations are somewhat expected and likely to happen, so here are the two ways I tried that helped alleviate the situation.
-
Have the attendee who is skipping ahead do some extra research, or ask her to try and add some additional bit of functionality on her own that’s outside of the workshop guidelines. This should buy you enough time to boost through whatever the other girl is struggling with.
-
You can also be more proactive and try to work as a team of three, asking both attendees to help each other out. This turns the workshop into more of a group assignment, and attendees would find it easier to clarify or explain what’s confusing them.
If someone is falling behind and having trouble keeping up with the tutorial, they’d eventually stop asking questions and would turn from an active participant into a passive listener. You’d probably lose them going forward, and that would effectively turn the workshop into a waste of time. Tackle this by switching to ‘constant question asking’ mode, and have a whole-team approach to whatever is not clear. You’d each be asking questions one another and dance around the issue at hand until it’s resolved.
Be flexible - regardless of how cheesy this sounds.
Taking things further
In short, I highly recommend giving Rails Girls a try - it’s an excellent pro bono opportunity that benefits both sides.
Whether you’re someone who is interested in learning about web development, or someone willing to volunteer at the event, there might be one happening in your area sometime soon.
Last but not least, there are also free weekly study groups that are being organized by the same team and hosted at the coworking place I go to.
Everyone is welcome, and there are always a few instructors around to help out if needed. The groups have no specific agenda, so everyone works on whatever interests them. Be that Ruby, Rails, or something else entirely.
Until next time!