From July 5th to September 20th of 2016, I spent a majority of my waking hours at the Recurse Center, and I’ve been postponing writing about it ever since. It’s difficult to organize your thoughts immediately after such a big thing has ended. In fact, I’m still not exactly sure what I mean by big. Attending RC feels like one of those turning points in life, resembling the societal stereotype of graduating from college or getting married. There’s a tradition of Recursers writing “return statements” (typical silly programming joke) to reflect on and summarize their experiences. When I was considering applying I found reading these both useful and inspiring. Before and during my batch I used them to help think more about what I wanted to work on and learn about. So, here’s my attempt.

What exactly is the Recurse Center? If you’ve never heard of it, the best place to start is the user’s manual. When I’m asked to describe RC, a few things come to mind. At its heart is a 6 or 12 week program that’s best described as a “writers retreat” for programmers. Attendees come from a wide range of experience levels and backgrounds. There are no teachers, curriculum, or grades, and you can work on your own toy ideas or existing open source projects. Actually, if you really wanted to you could just spend the whole 3 months talking about programming with everybody. As long as you’re consciously working to improve as a programmer, you’re succeeding. The word “consciously” in that sentence is a key point. At RC there’s a strong culture of thinking more generally about programming and the learning process. Asking and deeply exploring questions such as “what programming topics are worth learning about?” or “what can I do to become better at learning new things” is strongly encouraged.

The large and growing alumni community is just as important as the retreat itself. As of early 2017, the number of alumni is nearing 1,000. They form a rich network around the world, both online and in person. At this point I’ve learned not to be surprised when I read an interesting blog post and go on to find that its author is affiliated with RC. The community forms an excellent support network and provides opportunities for continuing to learn and grow as a programmer. Living in New York, I’ve also enjoyed spending time with friends I made during and after my batch. One frequently repeated quote that resonates strongly with me is that RC is the world’s best programming community with a three month onboarding period.

The thing that most surprises people about RC is that it’s free to attend for everybody. The only expense is whatever it costs you to survive in New York City for three months. The natural question, then, is how can they possibly pay the bills? Once you’re a part of the community, they will help you get a job at companies that they have previously negotiated recruiting agreements with. If you end up taking one of these jobs, the companies pay RC a recruiter’s fee entirely separate from your salary. That said, the jobs staff is also more than happy to aid you in finding a programming job you’ll love, even if it isn’t at one of these companies. Because of this financial arrangement there is a strong alignment of incentives between RC and the alumni.

Most people showing up to RC on the first day don’t quite know what to expect. That makes sense – there aren’t too many similar experiences to compare it with. One common emotion is a sudden rush of doubt about whether you deserve to be there. Despite that, the RC staff seem to do a remarkable job at choosing attendees with a very small amount of signal – you probably do belong even if you’re aren’t sure. Later in the afternoon on my first day I remember sitting down, opening my computer, and thinking, “oh, ok, hmmm, what do I do now?” This reflects the beauty of the whole thing – nobody will tell you what you should be doing and no activity is mandatory. One important aspect of RC that helps with acclimation is that people come for 3 month “batches”, and these batches overlap with each other for 6 weeks at a time. The group that has already spent 6 weeks in the space is a great resource for help getting settled. However, it’s important to note that if you can’t afford to spare 3 months there is the opportunity to do a 6 week half-batch instead.

There isn’t exactly a “typical day” at RC because of how unstructured everybody’s time is. However, there are some things that are generally consistent. The official working hours are 10:30am-6:30pm. I found this useful because it enforced some sort of routine – just having an expectation of showing up to a specific place at a specific time was enormously useful for my productivity. This is, of course, completely optional. There were people in my batch who arrived at 9am everyday, and others who arrived at 2pm (or later). People at RC often joke that you could have just about the same experience if you just sat at home and programmed for three months. While funny (and perhaps somewhat true), I think this underrates the value of having a dedicated space for programming and a group of peers that share your interests and goals.

Most of my time at RC was, unsurprisingly, spent on the computer, either writing code, reading code, or reading about writing code. I also spent a lot of time having interesting conversations with my batch-mates. Recursers will often give seminars or talks on various subjects. There are also recurring weekly events organized by people in the batch. The staff do not take an active role in sustaining these. They are created by attendees and alumni, and the job of making them happen is passed down as people come and go. Over time some traditions do fade, but the lack of structure means they can be resuscitated at any time, and new ones can arise to take their place.

One thing I truly did not anticipate being an important part of these three months wasn’t related to programming at all. Having grown up in Boston and lived in Atlanta before, I thought that my experience with big metropolitan areas meant that New York would be different in scale, but not on any more fundamental level. I was definitely wrong. At the beginning I arrived in New York unsure of whether I’d like living there full-time. In the past when I had visited I was sometimes overwhelmed by the typical things: noise, traffic, crowds. However, the experience was completely different with a permanent place to sleep.

I stayed in a tiny room in Brooklyn, away from Manhattan and near the calm and green space of Prospect Park, yet just a 25 minute ride on the Q to SoHo. Over the course of three months I learned every detail of the streets around RC. In particular, I grew to love Chinatown. There are so many small shops and delicious cheap food is around every corner. At times it can feel as though you’ve been magically transported to a foreign country. More generally, this is something I love about being in New York. The diversity that is present everywhere is invigorating. Every time you walk on the street you are never short of interesting sights, sounds, and smells, especially if you open your senses and pay attention that what’s around you.

One of my favorite parts of every week at RC was code dojo. Anybody who’s interested shows up and ad hoc pairs are formed. Everyone then works on a small programming problem for about an hour and presents their solutions to the group. I like pair programming because it takes the common conception of writing code as solitary pursuit and turns it on its head. When you can work with others who have more experience than you or who can potentially bring a different perspective to a problem, it’s possible to learn a huge amount in a short period of time. If you have more experience than the other person, the effort of explaining something can help you understand it in an even deeper way. For obvious reasons, pair programming is quite common at RC, and many alumni tend to wish they had done more of it during their batch. I found code dojo to be a great way to make myself spend more time pairing. Through 12 dojos I learned many new Python tricks, wrote a solution in Pyth, and picked up some basics of Go and Elixir. Several of my closest friendships at RC began as pair programming sessions.

Another weekly feature at RC is Thursday presentations. These are an informal opportunity to show your batch-mates what you’ve been working on. There’s no pressure to present, but it’s a great way to get practice talking about technical subjects in front of a friendly and sympathetic audience. In all collaborative pursuits, being able to communicate what you’re working on is often nearly as important as being able to do the work itself. In science there is a strong culture of presenting your work – even as an undergraduate working in a lab I was expected to present every few months in front of the entire group. When trying to improve at technical presentations, there is fundamentally a bootstrapping problem. Without some experience it’s hard to have the confidence or the skills to give a talk to a bigger audience. But, it’s hard to get that experience without a venue to practice presenting. Meetups are one solution to this problem, but giving presentations at RC is a way to accomplish the same goal without having to do your first few talks in front of complete strangers.

One core part of RC that I haven’t touched on yet are the social rules. Much has been written about them elsewhere, including in the User’s Manual. I will say this: the social rules and the environment they create are critical to the functioning of RC. The combination of no “well actually”s and no feigning surprise creates an environment where you never have to make it appear like you know more about a thing than you do. In fact the effect goes beyond this, to the point that admitting your ignorance is actively encouraged. Doing so opens the possibility for somebody else to teach you something new. Also, it’s likely that you’re not the only person present who would like to learn more, thus the group as a whole benefits. The degree of radical openness at RC expanded my perspective on the spectrum of openness that’s possible in any collaborative situation. This felt especially significant as somebody who has spent time in scientific research where people so often go to great lengths to hide what they don’t know about for fear of being looked down upon.

A common question I get when I tell people about RC is “what did you work on”, especially from other programmers. This is difficult to answer because my dominant memories are not about specific projects that I finished. Instead, I think of the things I learned both about programming and myself. I also think of the people I spent 12 weeks hanging out and talking about programming with. So much of this learning wasn’t “this is how Python does this thing,” but rather learning how to think about programming, talk about programming, and learn about programming. As a purely self-taught programmer who hadn’t spent much time working with other programmers before, all of these were areas where I had plenty of room to grow. My perspective on what exactly programming is – all the different kinds of things computers can do – was expanded drastically.

Recently I’ve been thinking often about growth vs. fixed mindsets when it comes to learning. Being at RC convinced me that a focus on having a growth mindset can apply equally well to communities and organizations. It’s readily apparent that the RC staff are constantly seeking for ways to improve. There are of course connections between this and the fact that RC is technically a for-profit startup trying to find its way. But I think in large part it bubbles up from the growth mindsets of the individuals who attend. If you’re constantly thinking about how you can improve as a programmer, it’s natural to start thinking about how the environment you’re working in can itself improve. There are frequently new experiments, some of which are quite drastic, and things are rarely accepted just because “that’s the way we’ve always done it.” Even though they’ve been part of the community for a short period of time, Recursers in the current batch are encouraged to give suggestions for improvements.

Aside from the formal structure of the social rules, RC convinced me of the value of working with and spending time with nice people. I’m not sure there is that much more to say about this – obviously “nice” is by definition subjective. There have been efforts to somehow formalize this idea in things like the “no asshole rule,” and perhaps the social rules are an approach to the same question. Personally, I found that my productivity went up as a result of not being around jerks, and that probably means I should continue to put myself in similar situations. I think a greater degree of self-awareness also came hand in hand with this. I’d say I’m generally a more sensitive person than I was before I started RC, or at least I do my best to be careful of the effects and unintended consequences that my words and actions can have on others.

I think one skill that many people pick up at RC is an improved ability to work independently. RC is more or less an exercise in unsupervised working and learning, so it makes sense that three months of practice might lead to some improvement. From my point of view, one of the most valuable traits you can develop to be successful at working on anything independently is persistence. In addition, programming itself requires a particular type and quantity of persistence. The experience of programming is mostly having things not work, right up until the moment when they finally do. Programming also seems to follow the Pareto principle in that 20% of the code takes up 80% of the time. Working on something on your own inherently requires persistence – after all, nobody is telling you what to do, and your source of motivation has to come from within. This seems to be something that most programmers are perpetually dealing with, and the excitement to work on your own projects definitely ebbs and flows.

Every programmer is familiar with the feeling of being stuck. In addition to persistence, it takes a particular set of skills to unstick yourself when you don’t know what to do next. Getting over these hurdles seems to be one of the skills that sets apart more experienced developers. They have a lot of experience being stuck, they’re comfortable with the feelings involved, and they have a set of strategies to get themselves out. I think the second point is particularly important. The feeling of being stuck can be really uncomfortable, and the tendency is to want to just escape that feeling, even if it means shying away from the challenge involved. It can be so tempting to switch to an easier task or go do something else entirely, and the discipline to avoid doing that is critical. Another skill involved in being stuck is knowing how and when to ask for help. Julia Evans and others have written a lot about this, so I can just say here that I learned a lot at RC about getting help from others.

Something I valued while reading other return statements was the personal advice to those who are either about to start a batch at RC or are currently attending. So, what advice do I have for future Recursers? When it comes to Advice on the Internet™, I think it’s important to be aware of the inherent connection between advice and the personal experience of the person giving it. You might ask several people their opinions about how to “do RC well” and get different or conflicting opinions. Ultimately, the first thing to remember is that there is no one right way to approach your batch (oops, I guess that sentence is subject to the same caveat). If you’re spending 3 months at RC, hopefully you showed up strongly motivated to improve as a programmer. There are so many different ways to improve as a programmer and “making computers do things” contains a multitude of possibilities. Here are a few specific pieces of advice, but note that they are not necessary to make the most of your time:

• Keep making forward progress. It’s easy to be stressed about whether you’re working on the right thing, and if you are, that’s good! It means you’re being intentional and thoughtful. At the same time, you can end up biased too far in this direction. A solution is to focus on making progress of some sort every day regardless of what exactly it is. Then, come up for air maybe once or twice a week and decide whether you’re accomplishing your larger goals. If not, the solution is easy: change what you’re working on! At one point during my batch I was feeling kind of stuck, and one of the facilitators suggested that I intentionally start (and not finish) five things in a week to make starting a project feel like less of a big deal. This was a great way to build up some forward momentum. There are no prizes for finishing things – it’s all about learning the most you can. As a sidenote, “finishing things” is itself a skill you can improve at. If that’s something you’d like, well, then just kidding – there are definitely prizes for finishing things!
• If it sounds like a thing you might enjoy doing, consider keeping a daily or weekly list/journal of how you spent your time. It will be easy to forget the smaller things that you worked on and learned. Perhaps somebody will ask you in the future “what did you work on at RC” and you’ll have an easier time answering if you actually wrote it down. At the very least, it will be fun to go back and remember what you did in a few months or years. This is also another good way to help identify if you’re stuck and/or if you’re accomplishing your learning goals.
• You will probably write less code than you planned to and finish fewer projects than you thought you would. That’s ok. This is something many people at RC have trouble with – perhaps everybody just shows up with overly high expectations. It’s easy to think, “this is going to be so great, I’ll be able to work without distraction on whatever I want rather than what somebody is telling me to do. I’m going to be more productive than I’ve ever been in my life.” While it’s true that some people get a lot done at RC, 12 weeks isn’t long, and you’ll inevitably feel yourself being pulled in a dozen different directions at once. During my batch I learned about the basics of network programming, cryptography fundamentals, wrote some C code for the first time, dabbled in some other programming languages, learned about various models of concurrency in Python, and finished part of a web server/web framework (also in Python). Many of the little things I worked on were unrelated and very few of them resulted in a big, tangible piece of finished work. However, when viewed through the lens of accomplishing my learning goals, all of these projects served their purpose.
• If you’re trying to grow as a programmer chances are good you’re working on something new or outside of your comfort zone. As Martin Kleppmann describes, everybody at RC is a beginner at the thing they are working on. When you’re trying to do something you haven’t done before, making forward progress can be difficult. It’s easy to get discouraged when you imagine some other programmer doing the same project easily. One big realization I had at RC is that when you see an experienced programmer writing code fluently and it looks like it’s flowing out of their fingers fully formed, that means they have probably written something similar before. Maybe a good exercise to drive this point home would be to go back to a project you’ve worked on in the past and write it again from scratch. My guess is you’ll be shocked by how much faster you are.
• Embrace living in New York (if it’s your thing). Don’t come into the space every Friday. Go exploring. Eat all of the food. Maybe even do some touristy things. But, you don’t have to do any of the above if you feel like just focusing on programming, or if the city overwhelms you. There’s so much going on that you’re inevitably going to miss out on something; do whatever you feel is right for you in the moment.
• Get to know your batchmates. Talk with them about programming. Talk with them about whatever they did before RC. As I mentioned before, many of my favorite moments came from talking about programming with people who know more or have more experience than I do. You will also see faces you don’t recognize in the space, especially on alumni Thursdays. You should get to know them as well. Luckily, you have a natural icebreaker: just ask them what they worked on during their batch or what they’ve been working on since.
• At some point the time will come where you realize that you’ll have to go back to the real world soon, and it’s common to have a mid-batch slump as a result. Being at RC is a unique and freeing experience, somewhat magical and set apart from the real world. It can feel like it will be over before you really get to fully experience it. After RC ended, I realized that 12 weeks is actually the perfect length of time. In the months since, I’ve revisited and consolidated so much of the learning I did at RC. Concepts that didn’t stick right away formed new connections and built upon themselves later. Also, a big part of what makes RC great is alumni going out into the world to share the social rules and openness towards learning with those who haven’t had the chance to attend themselves.

Towards the end of my batch, I started to panic because it felt like I hadn’t finished everything I wanted and that I probably wouldn’t be able to. Eventually I came to what was ultimately the most important realization of my three months. The RC motto is “never graduate.” I understand it as having two meanings. The first is that you are always a welcome member of the community even when your batch has ended. The second is that you don’t have to stop doing the things you started doing at RC just because your batch is over. You can keep working on the same projects and applying what you learned in everything you work on, programming-related or not.

And of course, there’s always the option of doing a second batch…