Just over 6 months ago I was a part of a larger team that introduced the first ever Rails Girls event to Kampala (a 2 day event ran by ThoughtWorks). The event was hosted at the Outbox Hub, a floor above the ThoughtWorks office, and with help from the GirlGeek Kampala group (which was a key partner for reaching the female tech community in Kampala). You can read a write up of the event over at evelyn’s blog.
The event was a big success, with numbers exceeding our expectations and a great buzz throughout the whole weekend. In spite of this, I’ve always had mixed feelings about such events. There are definitely many benefits; they provide an opportunity to bring together the tech community and provide a ground for communication and relationship building amongst peers. They’re also great at showcasing/introducing new technologies and getting people excited. This was the main motivation behind this event, it was designed to demonstrate the speed at which someone with no prior knowledge can get a web application up and running, and it’s a goal that it achieved admirably.
However, there didn’t seem to be anything the attendees could do with this knowledge. Sure they could try to read up on their own and try to teach themselves, but that can be quite frustrating and the likelihood of people going to that effort seemed low. Some of those that attended loved what they saw and wanted to learn more, but did not come from a technical background/had no programming experience, making it even less likely that they would succeed through self learning.
A couple of weeks after the event, with the help of Christine, a then recent hire at ThoughtWorks and one of the founders of GirlGeek Kampala, we arranged for some of the ladies who attended to come in for a discussion on how, if at all, we could try to take things further. We wanted to see how we could use the excitement and buzz that had been created by the RailsGirls event to put into motion a more long term program to help educate and train local female techies. This was after all what we (ThoughtWorks) were in Kampala to do. Our aim was never to just start an office and tap into the local markets, but rather play a key part in building and growing the tech talent in East Africa.
It was clear from this meeting that there was a strong desire and appreciation for more learning opportunities. The discussion led to ThoughtWorks committing to running a free, and open, Ruby/Rails training course, targeted at the female dev community in Kampala, which has since become known as Ruby Fridays.
The event has been running fairly regularly (with the odd break for public holidays or when I’m on personal leave) for the past 6 months, along with the help of some fellow colleagues. What follows here are some of the more unique philosophies that the program employed, which I believe make up the most effective way of running such training.
Start from the start
In order to keep the training as inclusive as possible, we assumed that everyone in the first session had zero programming experience. We started right from the basics, using a combination of tryruby.org and “learn ruby the hard way”, in fact it was probably a couple of months before we even got onto the concept of objects. By doing so we were able to ensure that every attendee felt comfortable and that we didn’t start off at a pace that discouraged anyone; this was particularly important for the target group of our training.
We knew that there were some people present that did have some experience and were currently studying for a CS related degree. So we used this as an opportunity to try and encourage a sense of community and collaboration amongst the group by asking the more experienced attendees to take the time to help get their colleagues up to speed.
Evolving course structure
I didn’t want this to be a set course structure, with fixed timeframes for achieving certain goals or a fixed end date. The idea was for this to be a safe, comfortable and fun place for people to come and learn some new skills. Given that we were starting from the beginning and were covering many aspects of programming I wanted the course to evolve naturally based on how the group was progressing.
There was a basic idea in place: to start with an introduction to code. Move onto ruby basics, functions/classes etc. Then move on to source control via git. Web application basics, followed by an introduction to rails. Deployment to Heroku and then adding more complex functionality to the application.
These high level objectives weren’t broken down into a weekly schedule. Instead we would plan it week by week, seeing how much we had learned the past week and deciding how to best proceed based on that. It greatly reduced the overhead, requiring only an hour or so of planning a week to prep the session and also meant the course could adapt very easily to the requirements of the group.
We haven’t gone far down the testing path yet, but we have introduced the concept. It’s not necessary to introduce a tool like rspec to introduce testing. We’ve started with a very basic introduction to testing involving creating methods that just output a string (so the “assertions” are manually checked by just calling the test-like methods). This meant we could emphasise the importance of testing early on without muddying their early learning with more complex code.
No deadlines, no failing
This for me is a key aspect of this course. This is a free training organised to help encourage and attract females in Kampala towards programming. There is absolutely no need for any deadlines to be set or any exams or grades. The sheer fact that these people are willing to consistently give up their friday evenings to come into an office to learn about programming entirely motivated by their own curiosity and desires makes every single one of them a winner. We go at the natural speed of the group, with zero expectations. There is no goal in mind, we’re just there to help.
Understanding the how, not just the what
With framework like Rails, it is easy to fall into the trap of understanding what needs to be done, without knowing how it does it. by simply memorising magical incantations (generators) we can build up a web application without ever really understanding anything about the underlying technical complexities of what is really happening. This is, in some ways, how the weekend RailsGirls event is organised. It makes extensive use of generators and gems and shows you have to achieve a great deal without doing an awful lot. This is great for generating excitement, but it’s less great for learning about application development.
We took the opposite approach. The excitement has successfully been generated already, it was now time to go into the details. I wanted everyone to understand how things work. That’s another reason for the fluid nature of the course. It was essential that we took the time to explain exactly what was going on. We avoided all use of generators and gems as much as possible and relied on hand written code as much as possible. Great pains were taken to explain how the routes file works, for example, and how exactly the controllers/views/models all tie together in as much detail as we possibly could.
This was one of the factors that we still don’t have a great solution for. The style and informality of the sessions means we can, and have, made time for recap sessions when people miss sessions. However, as it is entirely voluntary, and given that there is no formal qualification being received at the end of it, we have commonly found some inconsistency with the attendance, which can lead to difficulties trying to maintain constant progress. The inconsistency has led overall progress being significantly slower that it could have been.
We did the best we could with the situation and accepted that this was a reality, and tried our best to not allow it to lead to frustration. Also, given that the bulk of our attendees were students, we also realised early on that any “homework” or extra reading that we set was rarely completed and was not a reliable method of progress.
With my time in Kampala now coming to an end, Ruby Fridays is definitely one of the endeavours I’m most pleased with. There were a couple of colleagues here in the office that would help in the running of the sessions, and I’m confident in their efforts to keep the training alive after I leave. I’m excited to hear about how it goes and hope that it continues to grow and inspire.