Hacker School Residency
My one-week immersion in project-based learning
November 2013 (postdoc)
I describe my week-long visit to Hacker School, a unique self-directed educational environment in New York City for people who want to improve their computer programming skills. It is a rare kind of serendipity hub where people have interesting chance encounters with new knowledge on a daily basis.
I just spent four days in New York City as a resident at Hacker School. During my visit, I split my time between working on my own research, sometimes with help from students, and working with students on their software projects.
This article summarizes what I did, what I observed, and what I learned throughout my residency. In short, it was an incredibly stimulating week that left a lasting impression on how I think about programming, education, and research.
[Note that in March 2015, Hacker School changed its official name to Recurse Center.]
What Is Hacker School?
Hacker School is a three-month-long program where students learn to get better at programming by working on their own projects. There is no set curriculum, no homework, no exams, and no grades. Instead, students self-direct their own learning and are very loosely advised by the eight Hacker School organizers (called facilitators), residents such as myself who visit for one or two weeks at a time, and sometimes by fellow students or alum. Read the official description for more details.
Hacker School is currently located on one floor of an office building in lower Manhattan, New York. Most people work on their own laptops in an open space, and there are conference rooms around the perimeter for private meetings. The sound levels are actually reasonable for an open-plan office, because most people are busy programming, not schmoozing.
Enrollment is free, but admission is selective. The main criteria for applicants is that they need to love programming and have a genuine desire to get better at it. The current Fall 2013 batch (Oct–Dec 2013) contains 59 students ranging in age from 19 to 58 years old, and with anywhere from a few months to many years of prior programming experience.
I hesitate to give an example of a “typical” Hacker School student since they come from such diverse backgrounds. But if I were forced to, I would describe the typical student as a college-educated professional who has worked for 5–10 years, saved up enough money to go without income for a few months, and then quit their job to devote time for personal intellectual development.
What do Hacker School students not look like? They're not programmers looking to spend three months prototyping their next startup product or businesspeople seeking a technical co-founder (or, worse, an exploitable code monkey). This place is not a startup bootcamp or incubator.
Why did I come to Hacker School?
A year ago (Oct 2012), Hacker School invited me to visit for a day and give a talk on my Online Python Tutor project. Students had been using it to learn Python programming, and one recommended me as a guest speaker. I had a great visit and was thrilled when they invited me back as a resident during the Fall 2013 term.
I had three main goals for the week:
Mornings at Hacker School are usually quiet. Students trickle into the office throughout the morning and get some work done before the official start of each day: the 10:30am daily check-in.
At 10:30am, students congregate into groups of 4 to 6 and spend a few minutes each updating their group on:
These daily check-ins get students to reflect on their progress and make some short-term plans. Updates are ultra-casual and definitely don't feel like delivering nerve-wracking formal status reports to a stern professor or boss. Nobody is grading students on what they say or doling out participation points.
For those thirty minutes or so, the office is abuzz with lively chatter, and afterwards students are primed to start working on what they were just discussing with their peers. It's such a simple yet effective ritual to kick-start the day: Students talk about what they plan to do, and then they go off and try to do it.
I spent each morning checking in with a different group and observed that another major benefit of daily check-ins is to get students unstuck before they dig themselves too deep into a hole. For example, if a student mentions, “ugh I was struggling to get X working yesterday,” somebody else in the group would likely suggest an online tutorial to read or a facilitator or fellow student who would be the best person to help resolve that problem. Then after check-ins end, they walk over to that student's computer and try to debug together. That's how impromptu pairs often form ...
So if Hacker School doesn't have a curriculum, how do students learn? Often by pairing up one-on-one with facilitators, residents, and fellow students.
If you glance around the Hacker School office, you see lots of people “pairing” – working together in front of a single computer or whiteboard. Of course, pairing isn't mandatory; plenty of people work alone for extended periods of time.
Pairs form in various ways, ranging from spontaneous to planned:
Here's one personal instance of pairing throughout my week:
The above example, and many more like it that occur every day, illustrates how learning typically happens at Hacker School – in an impromptu, on-demand, project-based, and often peer-to-peer way. In general, this very pure form of learning only seems possible when students are highly motivated and when mentors work hard to maintain a safe and comfortable atmosphere.
Finally, although I'm a huge fan of on-demand learning, I mentioned one potential shortcoming at the end of an article from last year, Teaching Programming To A Highly Motivated Beginner: Students might develop superficial, how-to knowledge that barely suffices to solve their particular problem at hand without deeply mastering the underlying concepts. I'm still not sure how to balance the tradeoff between taking the time to develop rigor with making continual progress on one's project.
Pre-planned meetings can be helpful for, say, introverted students who might not find themselves in as many impromptu pairings. Thus, facilitators and residents regularly hold office hours, and students sign up for appointments using an online booking system.
I scheduled three hours of office hours each day, usually from 3pm–6pm, which mimics my routine back at school of reserving afternoons for student meetings. Here were the main types of office hours interactions, ranked from least to most engaging:
One final thought on office hours is that thirty-minute meeting slots seem ideal, since I can't stay engaged for longer unless I'm having a super-stimulating conversation. Also, since I scheduled office hours at the end of my workdays, I tended to get super-tired toward the end, which was a bit unfair for those students.
End-of-week Project Demos
At the end of each work week (Thursdays at 5:30pm), students gather around the presentation area to demo their progress over the prior week. Participation is optional, but it's a great way to get encouragement, feedback, and perhaps even rally fellow students to join one's project.
With 59 students, it's infeasible for all students to present every week. So students sign up using an online system and specify their own (reasonable) time limit, which is then enforced by a large countdown timer.
Most presentations were either brief code walkthroughs or graphical demos, projected on a large wall display. I was impressed by how well-spoken and eloquent most of the presenters were, even though demos were unrehearsed. Here were some representative demos:
Demos were a fun and social way to end the week. People lingered around afterward to ask questions or to make plans to go out together. I'm happy that I got to observe an entire week's worth of activity, from Monday morning check-ins to Thursday evening demos.
However, one potential downside of over-emphasizing weekly demos is that students who are working on “less flashy” projects might not want to demo as frequently, since they will get upstaged by the more graphically-engaging projects. Again, there is the age-old tension between making demoable projects and spending time digging deep into programming concepts that might not lead to visible outcomes. Ideally, one would work on highly visible demos with technical depth, but this is not always possible.
Hacker School is a rare kind of serendipity hub where people have interesting chance encounters with new knowledge on a daily basis – during check-ins, lunch and coffee chats, pairing sessions, and online via the internal chat app. Even more importantly, people are able to turn around and quickly implement new concepts that they just learned in their projects and then show one another, thereby spawning even more opportunities for further serendipity. I know this sounds cheesy, but it was beautiful to witness this virtuous cycle of incidental learning happening over and over again throughout the week.
Three unique properties of the environment make all of this possible:
To ensure the first two properties, facilitators spend a ton of time thinking about admissions. Without a batch of students who are here for the right reasons and get along with one another, there would be no Hacker School; even a few bad apples can spoil the whole batch. To me, this is the main challenge when trying to scale up Hacker School to serve more students, or branching off into multiple physical campuses.
However, the final property – people being willing and able to try out newly-learned ideas – is what makes Hacker School special. Both in regular school and at the workplace, people are so busy focusing on their immediate task at hand – doing homework, studying for exams, writing the piece of software that they're paid to write, creating reports for the boss – that even if they hear stimulating new ideas at a talk or a lunchtime chat, they can't easily put aside what they're supposed to be working on and play around with what they've just learned. That's why talks often result in a lot of head nodding and hand clapping, but not much follow-up action. Most people are already stuck on a fixed heading and cannot seize serendipitous opportunities. But at Hacker School, students have three months to do just that! The closest approximation to this experience is being in a well-funded Ph.D. program with an open-minded and supportive advisor.
Freedom As Paralysis
All of this freedom, paradoxically, leads some students to feel paralyzed: There's always someone giving a lecture on something cool or demoing shiny new code to try out, so one can spend all day just dabbling in superficial knowledge and not making any forward progress on one's own projects.
Thus, the biggest challenge for students is devoting time to focus and march forward on one's project while, at the same time, not just having tunnel vision and ignoring all of the interesting learning possibilities every day that they can't as easily get after Hacker School ends.
The facilitators face a complementary challenge – how do they give students the freedom to thrive but maintain enough structure to make sure nobody slips through the cracks? The worst-case scenario is a student stuck in a rut or paralyzed by distraction for an extended period of time.
I had a fabulous visit and am still trying to mentally process the almost 10,000 words of notes that I jotted down throughout the week. Besides getting a ton of new ideas about both research and teaching, I also couldn't help but get inspired by the genuine enthusiasm of the students and facilitators. I really hope they can sustain this program well into the future, even as they face the inevitable challenges of scaling and financial sustainability.
What can more traditional institutions learn from Hacker School? Obviously they can't completely replicate this unique atmosphere, but can they adapt bits and pieces to improve upon the status quo? For instance:
I don't claim to know the answers, but I have a hunch that what I witnessed over the past week will undoubtedly influence how I approach teaching, research advising, and project management in the future.
Last modified: 2013-11-20