Rails Girls Digital Humanities

This past weekend I coached at Rails Girls Digital Humanities at the Roy Rosenzweig Center for History and New Media. The event was amazing, the women were inspiring, and the tacos were delicious. It was just wonderful to take a first attempt at teaching Ruby on Rails in a community that was so supportive and welcoming! I learned a lot about teaching from the day. Here are a few thoughts on the experience and on how I would be a better coach in the future.

Deep Technical Problems
At my table we ran into a couple problems where Rails refused to play nicely with the version of Windows a student was running. After working on the problem for a while, it became clear that I wasn’t going to be able to solve the issue in the time allotted. I eventually lent the student my laptop so that she could keep learning and building during the course of the afternoon. Of course, this is only a temporary fix, as the Rails issues would come up again when the student got home and tried to continue working. Is the tradeoff worth it? Or did I just delay the frustration until she was home? In the future it might help to have a designated Rails installation expert hanging around that wasn’t coaching to help troubleshoot tech problems like these that show up later, after the installation party is over.

Syntax
Syntax errors often posed the biggest teaching challenge for me. What do you do when you see that the problem is in the syntax before the student does? Suggesting to a student that the issue is with the syntax gave me the feeling that I was withholding information from her, which I can only imagine felt irritating. But I don’t think jumping in to point out mistakes is any good for long-term skill building either. Fellow coach Annie Swafford suggested that I use moments like these to teach the process by which I would find a syntax error, and I could definitely do a better job of this in the future. In the context of following a tutorial like the Rails Girls guides, this would mean a few steps. First, I double-check each line meticulously with one finger on my code and another on the tutorial. Second, I read the offending code backwards bit by bit to get my mind away from thinking about the lines semantically, which often tricks you into overlooking things. As a last resort, I copy and paste the tutorial code over top of my own. If nothing changes, I know there is no syntax error and that I need to look elsewhere. Finally, I search online for answers.

Frustration
It’s important to learn that we all break things. Constantly. I tried to stress again and again that I spend far more time breaking and fixing than I do actually building things that function properly. In the future I might even bring copies of some of my own commit messages (1, 2, 3, 4, 5) to illustrate the point and get some laughs. This feeling of helplessness, obviously, can be incredibly frustrating. Rails Girls DH made me wonder: how much frustration is pedagogically useful? How can we teach frustration in such a way that it doesn’t cause students to shut down? One of the hardest parts of coaching was learning to balance my instinct to help with the need to allow people to struggle. The women did an amazing job working through and learning from issues that popped up, but I wonder if I was doing the best job possible to facilitate their learning. As a coach, do you jump in the moment someone’s face expresses annoyance? Or, do you wait for them to reach out to you? I think at times I was too willing to read facial expressions and jump in to help, possibly out of a feeling that I wasn’t doing enough. Students should learn to feel confident and independent in their tech abilities, and they will only develop these traits by dealing with and pushing through their own frustrations. They should feel that they can ask for help, but they should also learn when they can handle something on their own. In general, I think the women I worked with were better at knowing when to ask for help than I was at knowing when to offer it.

So, if I were coaching again, I would do the following differently:

1. Bring an extra laptop.
2. Learn more about the Rails installation process and known issues with different operating systems ahead of time so that I am better equipped to troubleshoot such things.
3. Talk more about processes: of troubleshooting, of asking for and finding help, and even of conceptualizing new projects.
4. Strike a more satisfying balance between jumping in and letting students explore independently.

I’m already looking forward to the next Rails Girls DH event!