Continuing with the theme of looking back over the past few months here’s a quick writeup of my experiences so far running the RapidFTR codejams here in Kampala.
I arrived here early October 2012, at that time I think there had been 1 code jam already (well, technically 2, but I think the first was more of an introduction to RapidFTR and Unicef as well as a meet and greet with Rebecca Parsons, our CTO who was visiting at the time). This was fortunate for me as I was able to get involved at an early stage and see the growth of the jams.
The Ruby/Rails community here in Kampala wasn’t that active from what little we know, and so the decision was made for the first code jams to focus less on RapidFTR and instead concentrate on building up some of the local developer talent and teaching Ruby/Rails to the attendees. This proved to be a difficult (rewarding too, and a little frustrating at times) task. I really enjoyed running the jams, I’ve always been passionate about training and thoroughly enjoy it; plus as I’ve mentioned in previous posts I was excited about getting to spend time training the developers in what we consider to be good development practices and sharing some of the little knowledge that I have in the hope of growing the local technical community.
The plan was to hold these every 2 weeks, however that became difficult to do. It was either illness or public holidays, then there was the Christmas break, and the biggest obstacle of all was the University exams. A large majority of the attendees at the jams were students from the various local universities and around early December we discovered that they would soon be entering exam season. This led us to take the decision to put the jams on hold for a few weeks, it didn’t seem right to carry on doing them – many of the students may still have attended and this wasn’t the message we wanted to send out to them. We wanted them to be focused on their exams and so we decided to remove a potential distraction and restart the jams in the new year (After I returned from my trip back home to London)
The irregularity of the events diminished some (not all) of their effectiveness. The attendees were being presented with a lot of information, we covered topics such as introductions to Ruby, Rails (including a 2 day Rails training event over a weekend), CouchDB, TDD etc – most of these were new topics for the group and it was quite a lot to digest. Trying to pick this stuff up with such large gaps of time in between is not the most successful or efficient way to learn a new technology, so a fair number of the sessions would start with a big chunk of time spent going over previous content. In addition to this we would have new people turning up and so would have to try to get them up to speed while still trying to make progress with the regulars. Going forward there are definitely things I would do differently if I was to do something like this again.
I was proud of the fact we took the decision to try to train people that were interested, however I’m not sure we should have done it as a “code jam”. A more intense course with shorter gaps would be a better way to go, perhaps 2 or 3 weekends in a row, with a more disciplined/concrete attendee list. This would take considerable planning, but then again the way we ran the first few jams also took considerable planning, its just that the planning was spread out over a longer timeframe.
Despite these setbacks, I hope at least some of those that attended were able to get something out of it. At the end of the day some of the responsibility needs to rest with the attendees, we can try our best to share what knowledge we have, but its down to them to put in some of their own time to learn, there is only so much you can get out of a a few hours in the jam – to really learn required personal study and effort. And we did see this, there are those that clearly did put this time in and would even come visit us in the office during the weeks to ask questions and clarify their understandings.
After a series of these jams, today saw our first “real” code jam – no more of us standing at the front talking, writing code on the projector, giving code problems – today we sat down as a group, jumped onto mingle, and started picking up defects. It’s nice to finally see development taking place on the codebase. I can’t say for sure just yet how much work we’ve gotten done, the jam is still taking place when I decided to take a break to write this post. However it’s a nice shift to see people working and having to solve the problems on their own. There’s a few of us here from ThoughtWorks to help people out and answer questions, but people are also trying to figure things out for themselves too. After the initial training it make sense to stop pushing information and change it to be pull based, let people take the code and start picking up stories, and we’ll still be here to try and answer any questions and provide help when it’s asked for.
We have 20 people today at the code jam. I can’t predict how steady the number will be in the future, I have noticed that the attendance has shifted somewhat, some (by no means all) of the attendees seem to have not turned up since we announced that we will no longer be running them as training sessions, but we also seem to have some new faces. But this is based on 1 data point (today) so things could change. At the end of the day every person that contributes to RapidFTR helps contribute to a great cause. I hope those that who attended in the past got something out of it, and I hope those that continue to attend find it a fulfilling experience.