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 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, just that the structure we provide is optional, not mandatory. 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.
The rest of your batch is here to help you get the most out of your time here. Recursers come from a tremendously diverse set of backgrounds, so everyone has something to learn from their peers. 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 multiple decades. For instance, maybe you have an ambitious project idea you've always wanted to work on but have never had the time to start.
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 RC 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 unwelcome, 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.
Sometimes pointing out that someone broke a social rule can be challenging or feel awkward. If you don't feel comfortable pointing out to someone that they are consistently breaking a social rule, ask a facilitator for help.
Code of conduct
The social rules don't cover harassment or discrimination. For that, we have a code of conduct enforced by the RC faculty. All members of the RC community are expected to abide by our code of conduct.
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 requires a lot of work, so make sure you're putting work in. Focus, be ambitious, don't get complacent. Becoming great takes a lifetime, and there's always more to learn.
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.
What should you actually do while you're at RC to make the best use of 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 my time at RC the most productive and educational of my life? It's also tremendously helpful to connect and collaborate with the people around you. The primary educational value of RC is peer-to-peer. The best resources you have to learn from are your batchmates and the broader RC community, so make sure you're taking advantage of them. Don't hesitate ask people to tell you more about their work or for help with your own. Recursers are friendly and eager to make connections with other people who share their interests.
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! 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. That is to say, debug by gathering information, making a hypothesis about what's wrong, and testing your hypothesis, as opposed to just changing things until it works.
- 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).
- 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.
- Avoid distractions.
If you're really experienced
- Continue doing most of the things above.
- Figure out what it means to push yourself, then do so. Introspect and be honest with yourself. Determine what your biggest weaknesses are, and then work on strengthening them.
- Work on something ambitious that you're not sure you can accomplish. One way to be sure you're doing this is to try and work on something new to the world.
- Don't let yourself get comfortable.
- Seek out collaboration and conversation with people who know the things you want to learn. Don't hesitate to look beyond your batch if necessary. There are more than 1,200 people in the RC community. If you need help finding someone to talk to about your interests, please don't hesitate to ask faculty. We have deep knowledge of the RC community and can almost certainly point you in the right direction.
Most of the advice in this section applies to all Recursers, but is especially important for those with more experience, since the more experienced you are, the easier it is to stay within your comfort zone, not push yourself, and work on things you're already good at rather than focusing on your weaknesses.
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.
RC can sometimes appear to be a place where everyone is productive, totally comfortable in the environment, and feels great about themselves and their work. The reality is not always so sunny. This section exists to acknowledge Recursers' struggles and to encourage everyone to seek support from the community. 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 things Recursers struggle with:
Recursers may have moved away from their friends and families to come to RC, 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.
Living in New York can be difficult for some who travel here to attend RC and aren't used to living in large, dense cities. Finding temporary housing in New York is challenging, and Recursers sometimes end up in less than ideal living situations while far away from their support networks.
Recursers sometimes feel bad about their work and their progress on it, or like everyone around them is more productive than they are. It's easy to see only those who are doing well, but everyone's productivity ebbs and flows.
Lack of structure
Recursers are often coming from more structured environments, like work or school, and not having imposed strucutre can be a large, overwhelming adjustment. Recursers sometimes struggle to decide what to work on here, and feel like they're imposing by asking others for help.
Six weeks into a batch of RC, the next batch of Recursers shows up and the previous batch leaves. This transition can be jarring for the Recursers experiencing the transition. Recursers struggle with half of their RC friends being suddenly gone and replaced by a bunch of new faces, or with the culture of the space changing.
Because the tone of discussion at RC tends to be very positive, about RC and in general, it can sometimes be difficult to express negative feelings or talk openly about struggling. Recursers sometimes feel like they're alone in not having a great time at RC, and that they have no one to talk to about it. This can lead Recursers to feel alienated, or like they shouldn't have been admitted, or don't belong here. If you're struggling at RC and you're feeling like this, know that other Recursers have also struggled and felt alienated at RC; you're not alone. You can talk to your batchmates, reach out to faculty, or start a conversation on Zulip. The RC community wants to help you, whether it's your first day here or your batch ended years ago. And if it turns out RC isn't a good fit for you, that's OK too. Please come talk to us, we won't be offended.
Some Recursers struggle with mental health issues, which can add an extra level of complexity to navigating their time at RC. Smart, self-motivated people can have mental health issues, and there is no shame in getting support in dealing with them. Don't hesitate to reach out to us if you need help. While we don't have anyone on faculty who is a mental health professional, we will do what we can to connect you to people who are, and other resources you may need. Several members of the RC faculty are also trained in mental health first aid.
Jobs, recruiting, and how we make money
RC makes money by recruiting. We have partnerships with more than 100 companies, who pay us to hire Recursers for programming jobs. If you're interested in getting a job, we'll work with you to understand what you're looking for, match you with our open jobs at our partner companies, refer and introduce you to them, and help you prepare for interviews and negotiate offers. If a company we partner with hires you, they pay us a fee (usually equal to 25% of your first year salary) provided you stay at the company at least 90 days. This fee is paid out of the company's recruiting budget and does not come out of your salary. Recruiting fees are RC's only source of revenue. There's no obligation to get a job thought RC, but if you are interested in a programming job after your batch or at any point in the future, please get in touch.
We see recruiting and education as integrated parts of a whole, each of which gets better as the RC community gets bigger, more diverse, and more active.
To learn more about getting a job through RC, you can read Career Services and our jobs advice, get in touch with us on jobs chat, or book a one-on-one to talk to us.
Advertising jobs to the RC community
Please don't post job listings for programming roles on Zulip or Community. This makes it harder for RC to succeed as a business and adds to the noise on our forums.
The one exception to this policy is the contracting stream on Zulip, where you're welcome to post about freelance and part-time contracting work, as well as internships, since RC only recruits for full-time jobs.
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. If you work at a non-RC company and would like to start recruiting Recursers, or if you work at an RC company and want to know how you can help hire more Recursers, please email us.
Jobs Chat: A private jobs dashboard where you can chat with RC faculty 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.
The Booker: Book one-on-ones with us to talk about your job search.
Company browser: Browse and research companies RC works with.
Jobs settings: Set your visibility and contact preferences for companies.
The Recurse Center is open to current batches with key fobs 24 hours a day, 7 days a week (except as otherwise announced on Community, e.g., during certain special events). Alumni are welcome to visit RC on Thursdays, Fridays, Saturdays and Sundays, as well as off-hours (before 10:30 am and after 6:30 pm on Mondays-Wednesdays). See the guests section for more information.
We don't have assigned seats. You're welcome to work wherever you like throughout the day and the duration of your batch. If you need a standing desk or another type of set-up because of health reasons, please let us know and we will accommodate you.
Church is a designated quiet room: please don't pair program, work in a group, or host a seminar there. If you'd like to give a talk, host a seminar, or eat lunch in a group, we recommend you use Hopper, Lovelace, or Babbage. Hopper is best for larger groups and louder activities like lunch and social events, since it's the biggest room and at the front of the space.
Noise and volume level
RC is shared space intended for becoming better programmers together. This requires both relative quiet (so that people can focus) and talking (so that people can collaborate and form meaningful relationships).
What does “relative quiet” mean? Not as quiet as a library (which aims for total silence) but quieter than the typical coffee shop. We’re all responsible for maintaining an appropriate volume: First by not being loud ourselves, and second by kindly letting others know when they’re being loud.With the above in mind, please:
- Speak softly. If it’s too loud for you to speak softly and still be heard, the space is too loud. Please ask others to speak more softly, or ask faculty to do so for you if you’re not comfortable.
- Be considerate of others at all times, including nights and weekends. Use Hopper whenever possible for socializing, and schedule gatherings and events after 7pm (and as late as reasonable).
- Don’t do things that generate distracting noise—e.g. don’t have loud conversations, slam doors, play musical instruments, etc.
In addition to being a place to program, RC is also a shared social space. Movies nights, board game nights, and other group activities are valuable and an important part of the RC experience. In order to support both these social events and ample time for focused work, please do not run potentially loud events between 7am and 7pm either on weekdays or weekends.
We make an exception for some official RC events, specifically:
- Thursday presentations, which start at 5:45pm and are often followed by game nights and job fairs.
- The first day of a batch, which has social activities throughout.
- Occasional panels and workshops, which we host on Fridays.
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.
You'll occasionally see non-Recursers in the space (e.g. maintenance workers sent by our landlord, employees of our partner companies, etc.). We do our best to announce guests ahead of time, make sure they're here only as long as necessary, and make sure they 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.
We host Alumni Nights on Wednesdays 7:00pm-9:00pm, with optional check-ins and check-outs for alumns to discuss what they're working on, and Alumni Thursdays, where alumni are welcome to program for all or part of the day. We ask that alumni not enter the space between 5:30 and 6:30 on Thursdays to avoid disrupting presentations. In addition, alumni are welcome in the space to program any time other than 10:30am-6:30pm on Mondays-Wednesdays, which we reserve for current RC Retreat attendees.
Alumni are also welcome to host and join social events in the space on Saturdays, Sundays, and before 10am and after 7pm on Mondays-Fridays. 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 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 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.
We occasionally host evening events that Recursers are allowed to bring guests to (i.e., everyone is allowed to bring a guest as a +1). We'll note specifically on event announcements whenever events are open to guests.
When you bring guests to +1-friendly events, please make sure they wear name tags and are familiar with our social rules.
Exception for RC employees' families
We have an exception to our guest policy for RC employees, who are allowed to bring their immediate families (including significant others and children) to RC even during events that are not otherwise open to guests. Attending evening events on a regular basis is part of many RC employees' jobs, and this exception makes it a little easier for RC employees with families to attend.
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 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.
Our residents program is currently suspended, and we don't plan to have future residents. Instead, we have replaced the program with week-long mini retreats, a new way for people to become full members of the RC community without first attending a six or 12 week in-person retreat.
Read about why we stopped our residents program.
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 someone 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.
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.
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.
Zulip and Community are private. The only people with access are RC faculty and members of the RC community. Content is not publicly searchable. While they may be online, these conversations are akin to private talk amongst friends. Please get explicit permission before you share things people write on Zulip or Community outside of RC. You're welcome to share links to public content (e.g. a link to someone's blog post).
This section contains links for Recursers to apply to do an additional batch and to recommend applicants.
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.
- March 2016. Allie and John transition to our dev team. James (S'13) and Lisa (S'12) join RC as facilitators.
- June 2016. Rose (W'14) joins RC as a facilitator.
- September 2016. Allie moves on to work at Etsy, and John starts a new job at Eave. Lisa moves west and joins Pluot.
- February 2017. Rose leaves RC. James begins transitioning into a new role with more focus on making improvements to the Retreat.
- March 2017. Zach moves out of New York, and becomes our first remote employee. We relaunch our website with a snazzy new design.
- July 2017. Alicia (F1'15, F1'16) joins RC as a facilitator.
- January 2018. We introduce one-week mini retreats.
- – 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.
- – Add more information about the space; fix outdated jobs section.
- – Add Admissions section.
- – Add research lab note to guest policy.
- – Add Lisa and James.
- – Add Facilitators section.
- – Update facilities info for phone booth revamp & space reorg.
- – Add Rose; update history.
- – Update guest policy to cover +1-friendly events and RC employees' families
- – Update history, mail policy
- – Add noise and volume level section
- – Clarify when to host social events
- – Add code of conduct
- – Add Alicia; remove Zach
- – Update advice section
- – Add Alumni Nights
- – Add note and link to the Issue tracker
- – Update to include mini retreats
- – Improvements to jobs and recruiting section; update history
- – Update to strengthen and include Zulip in sharing guidelines