Sophie Haskins

blog.sophaskins.net | personal essays

github twitter rss
My week at the Recurse Center
Jan 28, 2018
6 minutes read

What is the Recurse Center?

The long answer is: see how the Recurse Center describes itself.

A shorter answer is that, to me, its most important attributes are:

  • it’s a retreat for programmers to focus on honing their skills
  • it’s self-directed learning, not a curriculum of lectures and assignments
  • it happens in batches of attendees who start at the same time and (usually) finish at the same time
  • attendees have a variety of skill levels - some have been programming much less than a year, some have been programming more than three decades
  • its social norms are structured to make it a safe place to say “I don’t know”, to ask questions, and to learn. It’s not a place to show-off or brag of your nerd-dominance

Why did I go?

I’ve been on the periphery of the Recurse Center (a.k.a. RC) for years. I worked at Etsy when they first provided space for RC’s Summer 2012 batch - through that relationship, I:

  • interviewed several Recursers for full-time positions after their batch was over
  • regularly had lunch with participants while RC was in session (because they shared our office space)
  • eventually became close friends with some of the Recursers and added new RC-filled spheres to my social scene

All of the RC-ers I’m lucky enough to be friends with are incredible people - they’re smart, considerate of others in their actions, curious, and creative. I want to be like them when I grow up!

I had never attended, though. Three months for a batch is a long time! I’ve had a few years of trouble finding the right job (thankfully I’m feeling happy and settled now) and that meant I seldom had money saved up in-between jobs to go to RC and comfortably look for a job.

In November of last year, RC announced that they’d be experimenting with “mini” one-week batches. Being away from work for just one week felt very reasonable - it’s about as disruptive as going to a conference, but much more educational! It seemed like my time had come!

My project

Over the years I’ve picked up bits and pieces about how pre-emptive multitasking works - a few details about timer interrupts here, a couple bits about saving registers there. My goal in my week at RC was to deepen my knowledge of multitasking.

Exploration started with the sources. I poked around, grepped for words that I knew, and tried to find the code that implemented parts of the process I knew about. One of my batchmates pointed me towards Robert Love’s Linux Kernel Development - an amazingly well written exploration of the internals of the Kernel. I dove in and took lots of notes!

Boosted by what I had learned in the sources and reading that book, I started doing experiments. I learn best when I can see the parts moving - my hope was to run various workloads and see observe how they are run. I wrote a program that does configurable amounts of busy work, a script to scrape some statistics about scheduling, and a few different scenarios. From there I was able to make some fascinating graphs

Most of my results were as expected (if you run identical processes, they get scheduled similarly; if processes do less work, they end up with less time on CPU) which is rad! I did have one suprising result - when running both a “full” load and a process running using the IDLE scheduler I expected the IDLE process to get no CPU time, but it got some! Something to dig deeper on!

Conversations

In only one week it’s hard to go too deep in to a project. For me, the conversations I had and relationships I built were more important. I spent a lot of time listening to what others were working on - and learned so much by doing so. My batchmates were able to work on projects that they were deeply curious and excited about because of RC’s structure. The social rules make a space where they could share and be vulnerable about what was frustrating or exciting or surprising or new.

I got to hear about generative puzzles, ReactJS, the insides of LLVM, 8-bit game programming, map generation, debugging tools, distributed file systems, pure-CSS graphics, first steps in functional programming, encryption, and much more. I was able to share expertise with Kubernetes, distributed systems, and serve as a rubber-duck.

Feelings

The night before my batch started, I was re-reading the RC User’s Manual and having doubts. Some doubt was my suspicion of the “unschooling” movement, something I heard echos of in RC’s self-driven design. A bigger part was the mission itself: “to get dramatically better at programming”. Did I even want to get better at programming?

A lot of bad things in the world have been created by programmers: software for operating drones that bomb civilians, data-mining that violates privacy, companies that “disrupt” by dropping vast amounts of capital in to a market without any intention of building a sustainable business. A lot of bad people love programming: open source thought leaders who harbor deeply racist views, authors of popular databases who discuss their sexist ideas openly, neo-reactionaries leading functional programming conferences. The norms of programmer culture still revolve around using needless complexity as a cloak of wizardry. I don’t think programming skill is particularly important in my job, so why am I even doing this?

My fears were not realized. That may be what programming is in the world, but that’s not what it is at the Recurse Center. I am still skeptical of replacing organized schooling with self-directed unschooling, but the Recurse Center isn’t a replacement for anything - it stands on its own. Through the emotions of my batchmates, the incredible safety to learn provided by the social rules, and the focus provided by taking time apart from work I re-learned to love programming. As I took the train home after my final day, my thoughts were:

There can be good in programmers. There can be joy in programming. I want to find those things - I want to continue to learn and to share and to share in.


Back to posts