Philip Guo (Phil Guo, Philip J. Guo, Philip Jia Guo, pgbovine)

Hacker School Residency

My one-week immersion in project-based learning
Summary
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:

  • Research brainstorming: I timed my visit for exactly when I was starting a new project on tools for teaching programming. And what better group to brainstorm ideas with than highly-motivated hackers who are fully immersed in learning and teaching programming?

  • Interacting with students: Since I'm spending this year preparing to become a professor, I need as much practice as possible interacting with students in a variety of settings. That's the only way for me to get better at teaching, mentoring, and project advising. Since Hacker School students aren't (usually) undergraduates, I could interact with more diverse sorts of students here than I did back at school.

  • Having fun: Finally, I treated this trip as a one-week vacation to New York City ... a vacation where I spend 8 hours each day talking about programming! I came to Hacker School because I wanted to have fun, not because I needed to do it out of some sort of professional obligation. As more work-related obligations fill up my calendar in the coming years, I still hope to make time to attend events like this because I want to, not because I need to (or, worse, ought to).

Daily Check-Ins

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:

  • what they did yesterday,
  • and what they plan to do today.

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 ...

Impromptu Pairing

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:

  • After check-ins – Like I mentioned in the previous section, daily check-ins are a natural launching point for pairing.

  • After talks – Facilitators, residents, guest speakers, and even students give tech talks throughout the term. These talks sometimes inspire students to pair up and dig deeper on projects related to the discussed topics. For instance, when I gave a talk on Online Python Tutor last year, afterward I paired up with students who wanted to extend its functionality.

  • Kitchen or lunchtime chats – Technical conversations often start during snack breaks in the kitchen or when students are out at lunch, and those sometimes incite pairing sessions afterward.

  • Online chat – Everyone at Hacker School uses a common chat app (think IRC on steroids), and sometimes students post requests for pairing on there. Here's an example post: “Any Java experts willing to help me package up a fairly complex project for use in Clojure? I am ignorant of the Maven/uberjar arts.

  • Office hours – Facilitators and residents hold formal office hours, and students book time slots using an online reservation system. More on this in the next section.

Here's one personal instance of pairing throughout my week:

  1. The weekend before my arrival, I sent an introductory email to all students telling them about my current research task – creating a knowledge map of Python concepts – and encouraging them to pair with me to work on it.

  2. Katie, a former astronomy Ph.D. student, replied to my email with interest. We paired up on Monday and Tuesday to catalog Python concepts from introductory textbooks such as Learn Python The Hard Way and Think Python.

  3. Along the way, I realized that Python bytecode analysis would be useful for my research. Since Katie wasn't familiar with bytecodes, I gave her a brief introductory lesson, which morphed into an hour-long digression about compilers, interpreters, assembly and machine code, CPUs, memory, and register versus stack machine models! I ended up scribbling all over her poor notebook:

  4. Katie grew intrigued by Python bytecodes and told Denis about our explorations. Denis got excited as well, so the two of them paired on Thursday to create EnglishPython, a prototype tool that explains the basic semantics of a Python program to a beginner by abstractly interpreting its bytecode.

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.

Office Hours

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:

  • Human documentation – Some students needed technical help with a specific part of their project. So I either explained some concepts to them or, more often, pointed them to online documentation that explained far better than I could. This sort of interaction felt like the more mundane parts of office hours for a university class, but I still tried my best to be helpful.

  • Career counseling – In particular, several students asked me about the tradeoffs of pursuing a Ph.D. in CS versus working as a professional programmer, which is something that I've thought a lot about. Even though I love rambling on and on about such topics, I don't know how useful or actionable my opinions were to students.

  • External validation – Some students wanted to show off their project to me and get some external validation that they were doing something meaningful and interesting. For those meetings, I acted more like a cheerleader than a critic, trying my best to pick out the most encouraging directions and motivate them to focus on those. In an ideal world, everybody would be driven solely by intrinsic motivation; but here on Earth, I do see the value of external validation, since that boosts morale and keeps students going even through the inevitable unglamorous slogs of any project.

  • Pair programming – Some students needed help writing a particularly tricky bit of code, so I sat down with them and did traditional pair programming as the observer. For instance, I worked with Sumana to write a snippet of Python code to read lines of text from stdin without any buffering delays:

    import sys # stdin is an attribute of sys
    l = []
    while True: # required to avoid buffering delays
        a = sys.stdin.readline()
        if len(a) == 0:
            break # EOF
        l.append(a.rstrip()) # figure out how to strip newlines
    
  • Design consultation – Some students wanted feedback on how to design, say, data visualizations or GUIs, so we hashed out design ideas together on the whiteboard:

  • Project scoping – One of the most important roles of an advisor is to help students properly scope their projects. Otherwise students might find it too daunting to get started or get stuck on irrelevant edge cases. For example, I met briefly with Katie and Denis to scope down their initial plans for the EnglishPython bytecode analyzer so that they could quickly get a first prototype working.

  • Teaching – Some students wanted to learn a specific programming-related concept in more depth. For instance, after Katie spent some time pairing with me to work on my research project, she scheduled an office hours appointment to learn more about Python bytecodes.

  • Hanging out – By far the most engaging meetings were just hanging out and chatting about technical topics of mutual interest. Those conversations resembled the best sorts of interactions in academia. For instance, Julia Evans and I talked extensively about Python data science workflows and mining command histories to gain insights into how experts use command-line power tools. She blogged about our chat afterward and even made an app to visualize Git command workflows!

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:

  • Katie and Denis demoed their Python bytecode explainer
  • Facilitators Allison and Tom each demoed their own Python auto-importers that imports modules on-demand at runtime without requiring the programmer to write pesky import statements (like residents, facilitators also spend a portion of their time working on their own projects).
  • Sumana demoed a command-line tool that highlights systemic bias in Wikipedia articles.
  • Procedural music generation with the ChucK music programming language
  • Starcraft-playing AI bot using Clojure
  • Real-time video processing in the browser using a laptop webcam and HTML5 canvas, which resulted in some gnarly visual effects:

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.

Serendipity Hub

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:

  1. People all share a common goal: to get better as programmers,
  2. but they come from diverse backgrounds and thus provide different sets of knowledge and ideas,
  3. and, most importantly, they are willing and able to try out new ideas that they learn from one another.

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.

Parting Thoughts

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:

  • Undergraduate education – How can instructors engage students to the degree that I saw at Hacker School even with the usual constraints of grades and mandatory coursework?

  • Ph.D.-level education – How can professors foster an environment that ameliorates the isolation and uncertainty of grad school, while keeping students focused on producing academic research output?

  • Technology companies – How can managers tap into engineers' intrinsic motivation and pride in their craft, while keeping them focused on shipping products that deliver value for the company?

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.

Created: 2013-11-14
Last modified: 2013-11-20
Related pages tagged as programming: