We've finally got enough interview data for the Hacker School Book Project that we can start seeing some patterns in the stories people tell. I've gotten fascinated by a cluster of ideas that relate to apprenticeship-style learning. This blog post describes some of my thoughts-in-progress on the topic.

Originally, scaffolding, fading, articulation, and reflection) because it describes a lot of the techniques Hacker Schoolers use to teach each other. When the actual interview data came in, I rapidly realized that while I was seeing these techniques a lot in the Hacker School space, people didn't talk about them in the interviews. So I've switched gears, and have these themes/codes instead.

Apprenticeship-related themes in Hacker School Book interviews (so far)

  1. accidental learning
  2. legitimate peripheral participation
  3. making thinking visible (cognitive apprenticeship)
  4. zone of proximal development
  5. talking like a programmer
  6. stage performance of programming

What do these words mean? Well, we can think of Hacker School as a place where people learn through (cognitive) apprenticeships. Instead of listening to lectures about programming, Hacker Schoolers learn by actually programming with other programmers. This ultimately helps them engage more deeply in the broader programming community of practice that stretches beyond the walls of Hacker School.

Several apprenticeship-related big ideas pop up in the stories Hacker Schoolers tell. First of all, Hacker Schoolers engage in lots of accidental learning of things they didn’t intend to pick up; a chance comment on a mailing list, a glance at someone’s screen, or a lunch conversation will spark a new idea. Second, they offer and take opportunities for legitimate peripheral participation, which refers to the creation of “entry points” where novices can usefully contribute to a real project.

Third, Hacker Schoolers make thinking visible to each other as a way of both teaching and learning; they present and demo, coach others through tasks while pair programming, work together to break down large tasks into simple ones, and so forth. They often do this as a way to help each other stay in their zone of proximal development, where they stretch their abilities by working together on things they can only do with assistance. In the course of this collaboration, they don’t just make their thoughts understandable to computers in the form of code; they also make their thoughts understandable to each other.

By making their thinking visible, Hacker Schoolers practice talking like a programmer, where using the right vocabulary words (“functional programming,” “z-buffer”), technologies (git, IRC/Zulip, bugtrackers), and conversational etiquette becomes just as important as writing the code itself. They get to experiment with their stage performance of programming and the choices they make about conveying aspects (humility, confidence, experience, etc) of their programming “persona” to others through their behavior.

Where do I want to go with these ideas?

This set of themes is very, very early and unformed -- my thoughts are changing constantly as more people interview each other and more data comes in. That having been said, I feel like there's something here -- at least an indication that this is a useful way (among multiple useful ways!) to think and talk about about what's going on at Hacker School.

One thing I'd love help/ideas on: I'd like to find a better way to phrase the "stage performance of programming" code, which draws from performance theory -- the idea that we all perform roles (as if we were actors in a play) and portray ourselves as "characters" by doing certain things. For instance, part of my "performance" as a programmer might be always wearing t-shirts with a software company's logo on them, so I'll be seen as knowledgeable about and connected to nifty software startups. Or I might always talk really fast, with lots of long technical words, because I think it will make other people think I'm smart (...but it just makes it harder to understand what I'm saying).

In fact, a lot of the Hacker School social rules can be seen as ways to gently steer away from certain kinds of "performances" so that other (healthier, more hospitable) "performances" of programming can emerge. Things like "well-actuallys" and "feigned surprise" are negative because they're putting on a show -- doing something in order to get a certain reaction/status from someone else. So this idea of "performance" at Hacker School seems like a very important one.

However, I worry that the phrasing "programming performance" makes people think of "how good am I at writing code?" instead of "what behaviors do I adopt so other people see me in a certain way?" Can anyone think of a better way to word this?