The Recurse Center User's Manual
About this document
This User's Manual was written for admitted Recursers to help them navigate and understand the Recurse Center. We've decided to publish it in the hope that it will give the outside world a clearer picture of what the Recurse Center is like. You can read more about our motivations on our blog.
- Welcome to an unusual experiment
- The environment
- Traits of an awesome Recurser
- Pair programming
- Annoying stuff we debated including
- Struggling and mental health
- Jobs, recruiting, and how we make money
- Other resources
- Contact information
- A brief history of the Recurse Center
Welcome to an unusual experiment
The Recurse Center is unlike the rest of the world. This guide is designed to help you get settled in and get the most out of your batch.
One of the things that makes the Recurse Center different is that it's largely self-directed. This means you won't have someone telling you what to do, learn, etc, while you're here (though we do have a few social rules). This self-directedness is baked into the core structure of the Recurse Center, and is why we don't have grades, exams, curricula, or even classes. It comes from our belief that people learn best when given the freedom to explore what most interests them.
This doesn't mean the Recurse Center is a vacuum. The facilitators are here to help everyone in the batch learn as much as possible. We've been running the Recurse Center since the summer of 2011, and we've learned a good amount about what strategies have and have not worked for different types of people in the past.
In addition to the facilitators, you also have the rest of your batch to help you. Recursers come from a tremendously diverse set of backgrounds: Some people come to the Recurse Center and only have a few months of programming experience. For instance, maybe you're learning Python and are just getting a grasp on basic programming concepts. Other people come to the Recurse Center and have programmed professionally for a number of years. For instance, maybe you have a computer science degree, and want to dive deep into an open source project you've started but haven't had time to fully develop.
Regardless of how much experience you have, we admitted you because we believed you would be a positive influence on the batch, and we think being at the Recurse Center can help you dramatically improve as a programmer. This is really important, so we'll say it again: Everyone is here because we want them to be here, so if you're reading this, don't worry about how much more or less other people in your batch know. You are here because we want you to be here and believe in you.
Another thing that makes the Recurse Center different is the amount of focus it gives you. It's rare to have such a large, uninterrupted chunk of time to focus on just one thing. Even at work, most of us have multiple responsibilities and priorities to juggle.
Ideally, that's not the case at the Recurse Center. One of our goals is to remove as many obstacles in the path of growth as possible. Giving people three months to focus on becoming better programmers is a huge part of that.
(A funny thing we noticed a few batches in: the Recurse Center is as much a social hack as anything. You could quit your job and spend a few months programming for its own sake, but most people would consider you pretty weird. Coming to the Recurse Center is much more socially acceptable than sitting at home for three months. Of course, we also think we offer way more benefit than just being an easy answer to tell your friends and family when they ask what the heck you're doing with your life.)
Another obstacle we try to remove is fear. We think this is one of the most pernicious impediments to education. In most of the world, but especially school and work, people are afraid of looking stupid. This fear frequently keeps us from asking important questions like "how does that work?" or even just "why?" Worse, it keeps us from saying "I don't understand." That means many of us muddle on with a half-baked or entirely incorrect understanding of core concepts. This is particularly bad with programming, because these misunderstandings compound, and over time become harder and more embarrassing to admit to and address.
Did you know there's a well-documented phenomenon in which highly qualified people go through life feeling like they're a bunch of frauds and don't deserve the things they've achieved? It's common in work ("I can't believe I made it past the interviews. Surely someone will figure out I'm wildly incompetent and fire me soon!") and school ("Everyone here is so much smarter than me. I got in on a fluke."). This is called impostor syndrome.
This is why saying "I don't know" or "I don't understand" is a positive thing at the Recurse Center. It's an opportunity for you to learn something new, and for someone else to help you with it (or vise versa).
Another way we try to remove obstacles to learning is by having a small set of social rules. These rules are intended to be lightweight, and to make more explicit certain social norms that are normally implicit. Most of our social rules really boil down to "don't be a jerk" or "don't be annoying." Of course, almost nobody sets out to be a jerk or annoying, so telling people not to be jerks isn't a very productive strategy. That's why our social rules are designed to curtail specific behavior we've found to be destructive to a supportive, productive, and fun learning environment.
No feigning surprise
The first rule means you shouldn't act surprised when people say they don't know something. This applies to both technical things ("What?! I can't believe you don't know what the stack is!") and non-technical things ("You don't know who RMS is?!"). Feigning surprise has absolutely no social or educational benefit: When people feign surprise, it's usually to make them feel better about themselves and others feel worse. And even when that's not the intention, it's almost always the effect. As you've probably already guessed, this rule is tightly coupled to our belief in the importance of people feeling comfortable saying "I don't know" and "I don't understand."
A well-actually happens when someone says something that's almost - but not entirely - correct, and you say, "well, actually…" and then give a minor correction. This is especially annoying when the correction has no bearing on the actual conversation. This doesn't mean the Recurse Center isn't about truth-seeking or that we don't care about being precise. Almost all well-actually's in our experience are about grandstanding, not truth-seeking. (Thanks to Miguel de Icaza for originally coining the term "well-actually.")
No back-seat driving
If you overhear people working through a problem, you shouldn't intermittently lob advice across the room. This can lead to the "too many cooks" problem, but more important, it can be rude and disruptive to half-participate in a conversation. This isn't to say you shouldn't help, offer advice, or join conversations. On the contrary, we encourage all those things. Rather, it just means that when you want to help out or work with others, you should fully engage and not just butt in sporadically.
No subtle -isms
Our last social rule bans subtle racism, sexism, homophobia, transphobia, and other kinds of bias. This one is different from the rest, because it covers a class of behaviors instead of one very specific pattern.
Subtle -isms are small things that make others feel uncomfortable, things that we all sometimes do by mistake. For example, saying "It's so easy my grandmother could do it" is a subtle -ism. Like the other three social rules, this one is often accidentally broken. Like the other three, it's not a big deal to mess up – you just apologize and move on.
If you see a subtle -ism at the Recurse Center, you can point it out to the relevant person, either publicly or privately, or you can ask one of the faculty to say something. After this, we ask that all further discussion move off of public channels. If you are a third party, and you don't see what could be biased about the comment that was made, feel free to talk to faculty. Please don't say, "Comment X wasn't homophobic!" Similarly, please don't pile on to someone who made a mistake. The "subtle" in "subtle -isms" means that it's probably not obvious to everyone right away what was wrong with the comment.
We want the Recurse Center to be a space with as little bigotry as possible in it. Therefore, if you see sexism, racism, etc. outside of the Recurse Center, please don't bring it in. So, for example, please don't start a discussion of the latest offensive comment from Random Tech Person Y. For many people, especially those who may have spent time in unpleasant environments, these conversations can be very distracting. At the Recurse Center, we want to remove as many distractions as possible so everyone can focus on programming. There are many places in the world to discuss and debate these issues, but there are precious few where people can avoid them. We want the Recurse Center to be one of those places.
Why have social rules?
The goal isn't to burden everyone with a bunch of annoying rules, or to give us a stick to bludgeon people with for "being bad." Rather, these rules are designed to help all of us build a pleasant, productive, and fearless community.
If someone says, "hey, you just feigned surprise," or "that's subtly sexist," don't worry. Just apologize, reflect for a second, and move on. It doesn't mean you're a "bad" person, or even a "bad" Recurser. As we said above, these rules are meant to be lightweight. We've all done these things before. In fact, we originally adopted a no well-actually policy for our company because Nick and Dave well-actually'd each other all the time.
Traits of an awesome Recurser
Here are three principles we believe in. If you're living up to these principles, you're doing well at the Recurse Center.
Be rigorous. Understand how and why your code works. Understand your tools. If you're working with a framework (like Sinatra or Flask), learning to use it is just scratching the surface. Go deeper. Learn how it works.
Strive for greatness. You're all at the Recurse Center because we believe you can be great programmers. Becoming great takes a lot of work. All of us who work at the Recurse Center are trying to become great, too. We don't think we're there yet.
Reflect on your progress. We're all getting better at programming, but we should also be getting better at learning. Reflecting looks different for different people, but we recommend two primary things. First, write a blog! Even if no one else reads it, writing prose is a great way to crystallize concepts in your mind and deepen your understanding. Second, get code review! It's so much easier to get better when you're getting feedback and advice.
Ok, enough with all that. Now onto the real reason you're probably reading this: What the heck should you do with your time here?
The answer to this question will vary significantly from person to person. In general though, a good question you should ask yourself is: How can I make the three months of my batch the three most productive and educational months of my life?
A few words about this guide
This guide is a primarily a collection of things we've found to be useful over the years. Nothing in this guide should be treated as gospel, and all of it is subject to change. If you find other strategies work better for you, great! (But please make sure to share them so we can include them in future versions of this document!) What works for some people won't necessarily work for everyone.
If you're relatively new to programming
- Choose a text editor that is easy to learn and stick to it. If you're not sure which one to choose, Sublime Text is powerful, intuitive, and available on Mac, Windows and Linux.
- Avoid large frameworks like Rails and Django until you've got a decent grasp on the language you're using.
- Write lots of code. The specific code you write is less important than that you write lots of code.
- Don't worry about choosing the "perfect" project. It's easy to let the perfect be the enemy of the good when it comes to project selection.
- Have your code reviewed regularly, ideally by someone who knows the language you're working in well.
- Pair program, ideally with people who know the language you're working in well.
- Develop a good mental model of your code.
- Become a systematic debugger.
- Write small programs from scratch.
- Give yourself progressively larger challenges. For example, write a project you think will take an hour, then an afternoon, then a day, then two days…
- Become comfortable with your tools, but don't go overboard yak-shaving. Learn to use git, GitHub, a text editor and your language's debugger.
- Avoid distractions.
If you already have a good grasp of at least one language
- Learn a second (or third) language well, ideally one that's very different from the one you know best (e.g., if you know Python, it's probably more educational to learn Go or C or Scheme before you learn Ruby).
- Have your code reviewed regularly.
- Review other people's code regularly.
- Pair with people of all skill levels. You can learn a lot pairing with people at or above your level, and pairing with people who aren't as experienced (having to explain things to someone else forces you to deepen and clarify your understanding of them).
- Find the things you've always been a little scared of – e.g., multithreaded programming – and learn those (assuming they actually interest you).
- Avoid distractions.
If you're really experienced
- Contribute to open source projects, especially well-established ones with high code-quality standards.
- Consider starting your own open source project. Two good ways to find ideas: Scratch your own itch, or factor out code you've written multiple times previously into its own library.
- Continue doing most of the things above, including having your code reviewed by (and working with) stronger programmers. If you need help finding them, either inside or outside of the Recurse Center, we're happy to help.
- Avoid distractions.
Most alumni wish they'd spent more time pair programming during their batch. We learned this after the second batch, and have shared this fact with every batch since. Despite this, lots of people still tell us after their batch that they really wish they'd paired more.
What is pair programming?
Pairing means two people working on the same code using a single computer. The latter part – using only one computer – is important, because pairing is about actively collaborating and not just two people working on the same project or sitting next to each other.
At any given time, one person will be the "driver" and the other person will be the "navigator." The driver is the one sitting in front of the keyboard actually typing the code. The navigator sits next to the driver and reads the same screen. The navigator is there to talk through ideas, direct the driver, and think about how the code currently being written fits into the larger project. You should switch roles (i.e., driver and navigator) regularly, minimally every two hours, and ideally even more frequently. Switching regularly helps with knowledge transfer, ensures that both people get to drive and know what's going on, and helps keep everyone energized.
Sometimes you'll hit a wall. For example, you could run up against a concept neither person understands, or not know what library is best to use for your project. In these cases, it's ok to take a break from pairing. If you do this, you should time-box it, e.g., "Let's spend 15 minutes on our own researching what the best library for this is, and then report back with what we've found." The important thing is to explicitly agree to take a break and set a specific time when you'll check back in. The one thing you should not do is pretend to keep pairing but really default back to just working next to each other. It's easy to do this and waste hours without even noticing it.
Another advantage is that the navigator can catch a lot of small errors immediately (typos, missing semicolons, incorrect variable names, etc). It's faster and easier to fix bugs the moment they're introduced than at any subsequent time, so this ends up being a big win. Plus, as the saying goes, with many eyes, all bugs are shallow.
Pairing is great for knowledge transfer and can help with everything from learning a language to picking up editor or command line tricks.
Also, it's fun!
One thing to consider before pairing
It's good to make sure you have similar (or at least compatible) goals before you start pairing. If one person thinks the goal is to learn Python, and the other thinks the goal is to fix a bug as quickly as possible, you can run into friction. Making sure you're on the same page or at least know where each other is coming from helps everyone get what they want.
Annoying stuff we debated including
We want everyone to be at the Recurse Center because they want to be here. And we want everyone to be happy, productive, and fulfilled in their work and time here.
We don't want to (nor could we) enumerate every thing people "should" or "should not" do here. Instead, we prefer to assume everyone here is a responsible, respectful adult, and trust people to act accordingly and be able to work through differences as they arise.
Alas, people are complicated, and even reasonable people can have different ideas about what is respectful, and these pesky facts remain true despite our best efforts to simplify the world and abstract away the messy details of reality.
That's why we've included this section to lay out some broad expectations for how people will behave at the Recurse Center, and why they should (or should not) be here.
The first and most important thing: You should be here because you want to be here, not because someone else wants you to be here. It doesn't matter if that someone else is your parent, boss, or the President. Life's too short to be here for any other reason.
You should be here primarily because you want to become a better programmer and spend the majority of your time here programming and doing things directly related to programming.
So if you wake up one morning and realize the Recurse Center isn't where you want to be in your life right now (or isn't what you thought it was when you applied), talk to us! We won't be offended if it turns out we're not a fit for you.
Also, we all have trouble focusing at times. You will almost certainly have trouble focusing at some point during your batch. That's normal, but when you do, please try not to distract others.
Wait, this all seems really vague. Would you be more specific?
Well, we could ask you to pick up after yourself, be respectful of speakers, and keep conversations on-topic in the Recurse Center space during the day (i.e. if you want to take a break and chat about your weekend, go grab a coffee). But we think you all know that already. Just be respectful of your peers and act like the mature adults all of you are.
Struggling and mental health
The Recurse Center sometimes appears to be a place where everyone constantly has an amazing time, is perfectly productive, and instantly makes new friends. In reality, it's not always sunny. This section exists to acknowledge Recursers' struggles and encourage everyone to seek support from the community for all kinds of problems and feelings. If you're considering applying and worried about any of these things, we hope you see this section as a show of support, not a deterrent to coming to the Recurse Center. Here are some of the things that Recursers commonly struggle with.
Recursers are sometimes lonely. They may have moved away from their friends and families to come to the Recurse Center, and making new friends here takes time and energy. They're sometimes overwhelmed by meeting so many new people. Recursers sometimes feel guilty about spending time away from their children or other people they care for. If they have a long commute or a rigid schedule, they may feel excluded from after-hours social events.
Recursers sometimes feel that everyone else is being much more productive than they are. (This is often a manifestation of impostor syndrome.) It's easy to see only the people who are doing particularly well, but in reality everyone's productivity ebbs and flows.
Recursers sometimes struggle with the lack of structure. If you're coming from a more structured environment, expect this adjustment to be challenging at first.
Recursers sometimes struggle with mental health issues like depression. Smart, self-motivated people can have mental health issues, and there is no shame in getting support in dealing with them.
If you're struggling at the Recurse Center, you're not alone. You can reach out to facilitators, start a conversation on Zulip or seek support from professionals. The Recurse Center community wants to help you, whether you're in your first day here or your batch ended years ago.
Jobs, recruiting, and how we make money
The Recurse Center exists because companies pay us to recruit. Without this money, the Recurse Center could not exist, and if we're being completely honest, at any given point we are usually teetering on the edge of financial disaster (just kidding! Sort of). A lot of how we run the Recurse Center can be understood in the following way: We don't run the Recurse Center so we can recruit, we recruit so we can run the Recurse Center. Much of the world – mostly internet trolls – doesn't believe us when we say that. That's ok, but it's important that you do, and if you don't believe us now, we hope you will by the end of your batch.
(None of this is to say we don't want to make boatloads of money. We really hope to some day! At some point, the Recurse Center is going to need to make a heck of a lot more money than it currently does, if only to pay our employees market-rate salaries.)
So how exactly do we make money? Right now, we have recruiting agreements with a small set of companies, and for each Recurse Center alum they hire, they pay us 25% of that person's first year salary, excluding bonus, as long as that person stays at the company at least 90 days. It's not always this simple – there are annoying special cases where we don't get paid or we get paid less than that – but that's the gist of it.
The way companies get introduced to our alumni is an evolving process. In the past, we've hosted a "job fair" where we've invited programmers from companies we work with to come talk about why their companies are good places to work. We usually provide dinner and drinks, and give everyone an opportunity to meet and talk with each other.
We also give companies we work with accounts on recurse.com. There they can see your profile and get in touch with you if they're interested in talking. Similarly, you can look at a company's profile on recurse.com and get in touch with them if you want to talk. You can control whether companies can view your profile or contact you in your jobs settings.
If you are looking for a job after the Recurse Center or as an alum, we ask that you look through the Recurse Center first. Our survival depends on placements, and it costs nearly $12,000 for us to host each Recurser.
We generally encourage people not to think about jobs until the last couple of weeks of the batch. That's because when you start looking for a new gig, it can quickly become the top idea on your mind, which means becoming a better programmer won't be the top idea on your mind, which means you'll get less out of your time here. We host jobs events near the end of every batch where you will have the chance to meet company representatives.
(That said, if you're stressed out about jobs, or you can't get them off your mind, we're happy to chat with you earlier in the batch if you'd like. Just ask a facilitator or reach out via your private jobs dashboard.)
Even if you don't go looking for them, job opportunities can and will find you during your time here. Friends will ask if you want to join their startups. Recruiters will contact you (some even specifically target Recursers). Heck, even random people at meetups will try to hire you.
If you don't want a job after your batch, that's totally cool. But if you are going to take a programming job, either immediately afterwards or further down the line, please make your best effort to take a job through us. The Recurse Center's survival depends on it. If you're an alum working for a company we don't recruit for, we also ask you not recruit Recursers to work with you.
Jobs dashboard: Use your private jobs dashboard to chat with Nancy and Sonali and to keep track of the companies you're interviewing at or considering.
Jobs profile: Update your jobs profile to share your background, projects, skills, and work preferences with companies.
Company browser: Browse and research companies RC works with.
Jobs settings: Set your visibility and contact preferences for companies.
The short answer to "Can I bring a guest?" is no.
Our goal is to create a safe environment that is conducive to learning. Having unfamiliar people coming and going makes that harder, doubly so if they haven't been introduced at checkins.
There are four kinds of people you'll see at the Recurse Center other than members of the current batch: alumni, exceptional programmers who will enhance the Recurse Center (e.g., residents and speakers), programmers from companies we work with, and prospective Recursers who we have explicitly invited. We do our best to announce guests ahead of time and make sure they're introduced at checkins, stay for the entire day, and know our social rules to minimize disruption. We will make exceptions, but only under unusual circumstances.
This might sound heavy handed, but it's not meant to be. If you have any questions about the policy, please let us know.
Alumni are welcome to come code for all or part of the day on Thursdays.
Alumni are also welcome at the Recurse Center in off-hours (anything other than 10am - 7pm, Monday - Friday). During this time, the Recurse Center space is available for programming, and for social events. No guests are allowed, unless the event is specifically advertised as open to guests. Whether an event is open to guests is at the discretion of the faculty and will be announced ahead of time. There will be at least one faculty member at any social event that is open to guests and all guests must agree to follow the social rules.
As we ask of everyone at the Recurse Center, we ask that you work on open source software while you're here (i.e., don't work on proprietary code or code that you couldn't pair on or share with others). We also ask that you introduce yourself at checkins and on Zulip so that other Recursers know who you are.
Additionally, alumni in from out of town are welcome to visit on other days if Thursday doesn't work for them. If you're an alum and have an upcoming trip to New York, let us know! We'd love to have you back.
Most alumni do not have keys to the space. A small number who have agreed to take on additional responsibilities to the Recurse Center community have access to keys.
If you are in one of the current batches and would like to give your immediate family or significant other a peek at our space, you may do so during off-hours. Please keep the visit brief, be conscious of the other people in the space, and accompany your guest at all times.
Residents are nice, smart, accomplished programmers who come to RC for one or two weeks. You can see past and upcoming residents on our residents page. While here, they work with Recursers in pairs or groups, and often hold seminars, lectures and workshops.
We have residents to add energy, ambition, and domain expertise to RC. We want RC to be the best place in the world to become a better programmer, and getting the opportunity to work with someone who you admire or who is an expert in a specific area of programming you're studying can be hugely helpful.
What we look for in residents
There's no single right way to be a resident, and we try to invite residents from a diverse range of programming and personal backgrounds. Here is a list of qualities we look for in residents. It's not a checklist; it's probably impossible to find all these qualities in one person. Treat it more like a set of positive indicators. While there are probably other indicators we're missing, we think this list does a pretty good job of identifying good residents.
Has contributed significantly to a free or open source project. There's a lot to be learned from working on a big software project with a large group of people, and there's a lot to be learned from people who do that on a regular basis.
Has truly deep programming experience. Think multiple decades of experience working on hard technical problems. If you don't have this sort of experience already, the next best thing is to learn from someone who does.
Has written a book. This is a proxy for being an expert on some topic. Having written a book is not a prerequisite for expertise, just a good indicator of it. Learning from someone who's "written the book" on a topic can be great fun.
Has done significant research. While computer science isn't the same as programming, there's a large overlap. Getting to talk to and work with computer science researchers can be like getting a glimpse into the future of programming.
Thinks deeply about education. We love having residents who care about education as much as we do. RC is a great environment for experimenting with new educational ideas that can't be tried elsewhere.
Gives good seminars or workshops. Sometimes the best way to learn something is in a seminar or workshop from soneone who knows it really well. Both Recursers and residents regularly hold workshops on topics that they know a lot about.
Gives good talks. Residents generally give a talk on the first day of their residency. These talks can be engaging, entertaining, and thought-provoking and serve as an introduction to the RC community.
Has held an important position at a major tech company. Some programming problems can only be experienced at scale, whether that's building practical distributed systems or getting an engineering team of thousands to effectively work together on a single code base.
Are super nice and excited to work with people. Energy and enthusiasm are infectious. Residents who really enjoy programming and are excited about helping people become better programmers make RC a more exciting environment and inspire everyone to be their best selves.
Are well-known programmers who would attract great Recursers. The pithy version of this is "Internet famous." If a resident is well-known enough to convince more great people to apply to RC, our community gets better and everyone at RC benefits.
How to become a resident
Residencies at RC are by invitation only. Members of the RC community can suggest new residents on Community.
This section of the User's Manual has been modified for public release. In it, we talk about the various software and services we use to communicate. We've excluded the details because they don't give substantial insight into how the Recurse Center works and could conceivably cause headaches for us if they are revealed. We've included a summary below.
We use Zulip, an open source chat service, for real-time chat. It's great for asking questions, getting code review, organizing lunch trips, etc. If you're just getting started, you'll be shown a quick-start tutorial to get you up to speed. There is also a shared Google Calendar for events and various pieces of custom software we've written to handle all the little things that come up (RSVPs, dietary restrictions, etc.).
Everyone who attends the Recurse Center has access to Community, a private discussion forum for Recursers. Community is used for announcements, discussion, and social events.
Community is private. The only people with access are Recursers, facilitators, and residents. Content is not publicly searchable. While they may be online, the conversation on Community is akin to private talk amongst friends, so please use good judgement before sharing things people write there.
Please don't post job listings for companies that do not work with the Recurse Center.
This section contains the email addresses and phone numbers for all Recurse Center employees, and is only visible to members of the Recurse Center community.
A brief history of the Recurse Center
- Fall 2006. Nick and Dave meet during their Signals & Systems class.
- Summer 2007. Nick and Sonali meet at Shakespeare in the Park (Sonali is friends with one of Nick's coworkers).
- Spring 2008. Nick and Dave begin having "business meetings" after work to discuss starting a company.
- May 2010. Nick and Dave quit their programming jobs to start "OkCupid for jobs".
- June to October 2010. Nick and Dave live in Mountain View, CA and do Y Combinator. Paul Graham calls them "self-indulgent" for wanting to move back to New York.
- Fall 2010. Sonali starts working with Nick and Dave on weekends.
- February 2011. Sonali leaves her cushy corporate job and salary to join the team full-time!
- June 2011. Dave has a long talk with Paul Graham, Sam Altman and Paul Buchheit about a "school for hackers" and returns to New York ecstatic about the idea. We invite a small group of people to be part of an experiment called "hacker school" (we didn't capitalize it because we considered the name temporary – we weren't sure how we felt about calling it a "school").
- July 16, 2011. A third of the people who committed to doing the batch drop out two days before the start.
- July 18, 2011. The first day of "Batch" (aka the summer 2011 batch). The batch has only nine people including Nick, Dave, and Sonali, and is five weeks long. It's hosted in a small room at NYU with no windows. Alan is a Hacker Schooler and tries to explain monads to a very confused Nick and Dave. Sonali is the only woman.
- August 2011. John "workmajj" Workman suggests "Never graduate" as Hacker School's informal motto.
- September 2011. The second batch begins. We're hosted at Spotify in a slightly larger room with no windows.
- February 2012. The third batch begins with 20 Hacker Schoolers; Tom is among them. The batch is hosted at The Huffington Post. Danielle Sucher becomes the first Hacker School alumna.
- May 2012. We hire Tom and Alan as contractors to help facilitate the summer batch.
- June 2012. The summer batch begins with 53 Hacker Schoolers, among them are Allison, Zach and Mary. The batch is 45% women, and is hosted at Etsy.
- August 2012. Tom and Alan become regular employees and are joined by Zach and Allison.
- October 2012. Jessica McKellar, Peter Seibel, Alex Payne, Stefan Karpinski, and David Nolen are the first Residents.
- February 2013. We get our own space in Manhattan! The US government agrees that Mary is "extraordinary" and grants her a work visa.
- September 2013. We move to an nicer space with lots of natural light and no fruit flies.
- May 2014. To encourage traditions to persist from batch to batch, we move to overlapping batches.
- June 2014. We hire our first dedicated operations person, Rachel.
- November 2014. Allison goes west to join Dropbox: An unusual goodbye.
- March 2015. We change our name from Hacker School to the Recurse Center.
- May 2015. Michael Nielsen joins the Recurse Center to help build a research lab.
- August 2015. Allie (W'13) and John (S'11) join RC as facilitators; Nancy joins as our first full-time Jobs Counselor.
- – Initial public release.
- – Flesh out social rules.
- – Add contact information.
- – Add advice on text editors.
- – Add description of policy for space and modified guest policy.
- – Use "Hacker Schooler" instead of "student." More updates to guest policy.
- – Add translations section
- – Change fourth rule from "No subtle sexism" to "No subtle -isms" and flesh out explanation.
- – Remove ableist language. Update history of Hacker School.
- – Update with details of new mailing list system.
- – Add Rachel. Add struggles section.
- – Update with details of Community, which has replaced the mailing lists.
- – Additional notes for internal perks section.
- – Update references to Hacker School and Hacker Schoolers to the Recurse Center and Recursers.
- – Add Allie, John, and Nancy; update history.
- – Add Residents section. Publicly link to Zulip.