Yesterday I helped out at the first ever RailsBridge held in Lexington. We had twenty-five people sign up as attendees and maybe ten volunteer coaches, including myself. It’s intended to be an all-day session introducing women to programming, specifically by having them create a simple Ruby on Rails app. I gave the opening presentation, which you can find on SlideShare and also download as a PDF. It introduced the ladies to programming basics, and had them walk through several examples in IRB. Friday night we held an InstallFest where everyone brought their laptops and we helped them get stuff installed, including RailsInstaller in Windows, Git, Sublime Text 2 as an editor, and Node.js in Windows to have a JavaScript runtime. They also made a couple basic Rails apps that were no more than scaffolds, committed them to local Git repositories, and published them on Heroku. This was to prepare them for Saturday, when they did the same thing but with a more complex Rails app.

I was super pleased with it. Awesome Inc hosted us, CirrusMio provided lunch, and everyone was very helpful. The attendees seemed happy with it, too. I talked with one lady, a teacher in maybe her late forties, who said we looked less geeky than she imagined, and that we were all very welcoming. She commented “you just look like normal people.” Imagine that! :) Another lady who worked in communications and looked to be in her thirties was excited about what she could do with a Rails app at her company. She was trying to learn something so she could create simple internal tools. Our attendees spanned the gamut age-wise, with one child who was maybe twelve all the way up to one older gentleman who looked like someone’s grandfather. Most attendees were women in their twenties to forties, though.

I liked it when they would ask me why something worked the way it did, or for what purpose they were running a command. It’s a challenge trying to think of how to explain CS terms without using jargon. I explained Git by comparing it to zipping up your files and saving the archive with the date in the name, then doing that repeatedly so you can always unzip a particular date and get your stuff back the way it was. I explained migrations by telling the students they had just described what kind of data they want to store in the database, but in order for anything to happen, they had to run rake db:migrate to cause the Rake program to look for any new descriptions of changes and make them. When I said that, one lady said “you can write an email but it’s just a draft; to actually go anywhere, you have to hit Send.” One woman wanted to know if there was a list somewhere of all the methods she could use in Ruby; I sent her to RubyDoc. :)

Us coaches had to learn what assumptions we had about general computer knowledge, too. For example, when working in the terminal, we didn’t consider that the students wouldn’t have a mental mapping such that when their term said C:\Sites, that equated to looking at that folder in Windows Explorer. Or that doing cd directory_name was equivalent to double-clicking a folder in Windows Explorer. We also taught several basic Windows shortcuts, like Ctrl-S to save in Sublime Text 2, Windows-→ to stick a window to 50% of the right side of the screen, and Alt-Tab to switch between two running programs.

We actually ended up leaving early because the students finished their Rails apps. One lady had come down from Indianapolis to help out because she is going to run her own RailsBridge session in Indy. I think she got a good feel for how it will work, and especially important is she learned what to do differently. Having a cheat sheet for each student showing basic syntax for variable assignment, arrays, hashes, loops, and method calls would be great. During the exercises in my presentation, some students would have trouble doing variable assignment when we’d already moved on to loops, or they’d forget the syntax to make an array of strings when I had moved from that slide. That and telling them up front that they would receive a copy of my slides would have greatly reduced the amount of writing some people were doing.

The Indy coach, being a programmer herself, now has a better idea of where non-programmers are at in terms of what they know and how much you can gloss over when teaching them. You forget as a programmer that even things like variable names can be confusing to a beginner, because they don’t know if that sample variable name you used has some special meaning to Ruby, or if the programmer arbitrarily chose it. Hitting Enter after every command in a terminal is also something that isn’t obvious. Some other things we had to clarify because of student questions or mistakes were:

• You shouldn’t put quotes around a number if you want it to act like a number–the very fact that you quote it makes it a string.
• You shouldn’t quote variable names, or they cease to be variable names.
• To do variable assignment, just the variable name has to be on the left-hand side. You can’t write 3 + 5 = sum for example.
• The concept that when you deploy to Heroku, you’re just pushing up the framework of your application, not the database. This stemmed from one lady creating some records in her local Rails app, deploying it to Heroku, and wondering where all her data went.

There were other tracks in the RailsBridge curriculum that we didn’t do but that I think could make for good future sessions. The HTML, JavaScript, and CSS track in particular could be enjoyable and of use to web beginners around town.