I recently finished my batch at the Recurse Center in NYC and I’m happy to say it was one of the most productive times for me in terms of learning, making things, and collaborating with others.
In RC tradition, this is my return statement, reflecting on my time and experiences there.
Almost all of RC is unstructured time and it’s up to you to figure out how to best allocate it. You have the autonomy to work on anything you want, but that also means you might feel pressure because you feel like you’re not getting enough done.
These are two sides of the same coin, and I learned to “debug” my routine just as I would a program. On really productive days, I’d pause and ask myself what worked; on bad days, I’d pause and try and figure out what might have gone wrong.
RC’s physical space is awesome, and it quickly became a place to learn and work with others. I think it would be hard to achieve the same effect and velocity without a dedicated location.
RC is very thoughtful about its culture in a way that optimizes for learning, growth, and really becoming a better programmer.
“No feigning surprise,” for example, means people can ask questions that might be simple, and not worry about someone responding with “you don’t know about that?” No backseat driving means you can ask someone a question without someone across the room interloping in the conversation and giving an answer.
I was constantly impressed by the quality of people attending. RC has no requirements to have been programming for X years or hold Y title, rather, they try to select people who are curious and driven. I felt like these two traits mattered a lot more than prior experience and knowledge.
I paired with as many people as I could. Pairing is interesting for at least two reasons:
1) you get to collaborate with others and can get more done on certain types of tasks/problems. You’re constantly working together on something and sharing expertise.
2) This one was less obvious, but in hindsight was just as important: you get to see how other people approach and solve problems. Example: going in I knew a little about gdb , but never really saw it used to its full potential until I paired with someone who was an expert.
I chose to work through an algorithms book before my interview so that I’d be prepared. My interview ended up being a lot more practical than theoretical, but I feel like spending a few days brushing up and re-learning CS fundamentals helped me a lot and gain confidence as a programmer.
I became a lot more comfortable jumping into and reading other people’s source code. Previously, I’d rely heavily on docs and trial-and-error, but something clicked for me, which seems really obvious in retrospect: for a lot of languages (especially python and ruby), you can just pop open a library’s source code to see how it’s implemented.
Now that I’m reading a lot more source code, I feel like I write I’ll make things that are more expressive with fewer lines of code. It’s also a great way to learn from other people’s work: you quickly learn new styles and patterns.
I did a study group for Nand2Tetris, which was a great way to learn the really low-level fundamentals of computing. I really enjoyed studying physics because it felt like the “low-level” language of reality, and it helped me develop an intuitive understanding of things I studied in engineering school. I feel the same way with understanding the low-level abstractions of how a computer works.
If you have any questions about RC, feel free to get in touch and I’d be happy to share more. And if you’re interested in applying, here’s a link you can use.