Technical Outreach Workshops: Needlessly Frightening at the Beginning

- 6 minutes read - 1187 words

One of the organizations that I’m most proud of helping out is Railsbridge. It aims to increase the diversity within open source software development, particularly women. Twice now I have worked with wonderful and amazing people in these sessions.

#
Typical scene of getting laptops set up (source)

In these activities I have encountered a powerful enemy to successful teaching that we, as organizers and teachers, should remain vigilant against: negative confirmation bias.

Negative confirmation bias is when a student walks into a situation expecting that s/he is not going to succeed and then proceeds to look for data to back up that negative view. Why students have this negative view is a subject for another post, but it is my belief that it is at the heart of why there is such poor diversity in high tech.* At development workshops / boot camps, students encounter a dangerous confirmant of their negative bias in one the earliest steps: “Bootstrap the setup using git.”

Facilitators must take an active role in reminding students that the installation / bootstrap step bears no inherent reflection upon their ability to enjoy, learn from, and perform well in the class.

It’s surprising since planners and facilitators work so hard to make so many other aspects of the student’s engagement easy so as to counter the possibility of negative confirmation. Specifically, Railsbridge sessions do a great job:

  1. Delivering an energetic environment that checks: “I knew developers were boring, I don’t belong there.”
  2. Saying “welcome” upon check-in that mitigates: “Everyone ignored me, I knew I didn’t belong there.”
  3. Pre-communicating the transport situation that checks: Couldn’t park, probably didn’t belong there anyway."
  4. Building “pods” where informal collaboration occurs that checks: “*No one saw I was confused, I knew everyone there was smarter than me. I knew I didn’t belong there. *”
  5. Providing power strips, snacks, job prospects, etc.

But then we run the risk of glossing over something that seems very simple. We command:

“git clone a respository so that we can all start on the same page.”

This is a simple operation for anyone who has it as part of their daily workflow – something that we do with the casualness of deleting a file. But it is easy forget that this culminating activity is built upon a series of installations and configurations. To wit:

  • “Git clone a respository so that we can all start on the same page.”
    • git clone http://github.com/some/repo railsbr
      • get git
        • get [homebrew](http://mxcl.github.com/homebrew/)
        • get gcc and its libraries
          • get gcc from the Kenneth Reitz bundle OR
          • get gcc from XCode for Lion OR
          • get gcc from a legacy XCode
      • Tacitly understand the concept of a SCM
      • etc.

The challenges, tweaks, and reliance on facilitators’ judgment that “Oh don’t worry about this, it’s not fatal” or “Oh, right, we need to copy XCode from the USB key” can easily upset the student’s steady growth in confidence at the most critical, incipient point. Facilitators would be wise to handle this particular snag carefully.

The last session I participated in focused on essential web development skills: HTML, CSS, Javascript, and jQuery. git has absolutely no direct relationship to style of development.** Yet as we stepped through this stack of activities, I could almost hear the biases finding confirmation: “If I can’t get this working and the thing hasn’t even started yet, there’s no way I’ll figure out the rest.”

BUT once the students got past the installation snarl, they were well on their way and, from the feedback, it seems all the students (and teachers!) learned a lot and had a great time. It is absolutely essential that facilitators recognize this weakness in our curriculum and set expectations around it properly.

Big Nerd Ranch founder Aaron Hillegass has a great section in the beginning of his Cocoa programming for Mac OSX. I learned a lot from Aaron several years ago and I think of this story whenever I get disappointed or let down in my battles learning anything. Heck I’ve even repeated a paraphrase of it to some of my students at events like this. Here is is from the source:

“I used to have a boss named Rock. Rock had earned a degree in astrophysics from Cal Tech and had never had a job in which he used his knowledge of the heavens. Once I asked him whether he ever regretted getting the degree. “Actually, my degree in astrophysics has proved to be very valuable,” he said. “Some things in this world are just hard. When I am struggling with something, I sometimes think ‘Damn, this is hard for me. I wonder if I am stupid,’ and then I remember that I have a degree in astrophysics from Cal Tech; I must not be stupid.”

Recommendations for Organizers

If organizers use git or other bits of hacker-friendly technology to get your students bootstrapped, it is imperative that you explain that success with git has no inherent bearing on success with web development in general, ruby, or rails in particular.

It’s also worth bearing note that this applies to many of the other macroscopic activities that happen at workshops. rails g migration renameUserToClient runs on a similar “stack” of assumptions required to get the framework. The student will likely lack the familiarity required to discern the difference and conclude that:

difficulty bootstrapping a tool == difficulty using the tool == I am stupid

Here are some approaches that I’ve tried. Obviously, no approach is perfect for all students, but here are some ideas.

  • “This is magic, this is weird stuff and it’s something you’ll learn, but for today, let’s just follow the instructions and not worry about the particulars. It’s not programming, it’s just a tool.”
  • “The goal for us, as teachers, is to get everyone on the same page. This is just administration, not really coding $TECHNOLOGY_NAME so much. But we need you to help us get your machine ready and we’ve chosen one of the most difficult ways possible to do it (ha-ha).”
  • Use the “stack” metaphor above to explain that all of these little steps add up to completing the one simple task of getting the student on the “same page” by cloning a repository
  • Explain only as much as the student asks for. For example: “What’s git?” It’s a way for synchornizing files from a master source. We want all of the students to have a synchronized “base” state. NOT: It’s a DCVS that uses linked lists, has lightweight branching, and no designated HEAD.

The hard part is to become interested, to wake up early, to find parking / take transit, and to have the courage to actually open the door and say “I don’t know, but I want to know.” A bunch of noise about libraries should not halt that process or that progress.

Footnotes:

* Approximately 28% of high tech work is female; 2% in open source.

** In Railsbridge’s other sessions on Rails the linking is more obvious as one must use git to deploy the code to public servers. But acumen with an SCM certainly has no necessary correlation to success in the field of software