Back Original

Recurse Center reflections

The Recurse Center is where self-directed programmers go to push themselves, learn from each other, and have fun. In the fall of 2025, I traveled to New York and spent 12 weeks there building software for fun.

In the beginning, I planned my work using a bottom-up approach — first deciding on a topic I wanted to learn more about, then structuring my work around that goal. The main example of this was my debugger-from-scratch project. Towards the end I focused more on the finished products I wanted to see, and what I would learn along the way became more of a secondary concern. This resulted in a Playdate game prototype and an Internet-connected receipt print server.

Major projects

Reflections

On demo-driven development

RC has a tradition of encouraging anyone who is currently in-batch to give 5-minute lightning talks (which take place every Thursday) about whatever they're hacking on at the moment. This immediately became my favorite thing about RC. For 80% of my time at RC, I was working towards some sort of presentation or demo. This meant that I prioritized work that would be fun to talk about.

My presentations weren't nearly as polished as I'd hoped, but since they were all 5-minute talks given in a friendly and supportive environment, I ended up being okay with a little sloppiness, as long as I was getting my work in front of people. I'm usually shy about presenting my work, so this was a welcome change-of-pace for me.

On pair programming

People seem to have varying definitions of the term "pair programming." For me, pair programming is basically just sitting down with someone and writing some code together, whether it's from scratch or for an existing project. Ideally there's good communication and enough mind-melding for either person to take over typing at any given point. It didn't come naturally to me, but it's pretty normal at RC, so I asked people to pair with me frequently. It wasn't always a fruitful experience, but when it did go well, it felt like I was really connecting with the other person on a deep level, which is noteworthy for an activity I consider to be pretty antisocial.

From a practical standpoint, pair programming helped me break through some of the analysis paralysis I often feel when working alone, while also forcing me to add structure to the work. In other words, I tended to scope out work more thoroughly in advance of a pairing session, because I really didn't want to waste my partner's time. Perhaps just the presence of another person made a healthy dose of project management seem more salient.

I'll admit I haven't paired much since leaving RC, but it's a tool I know I'll reach for in the future. Even when I decide to program solo, the experience of trying to get better at pair programming has shown me that I can set myself up for success, even when no one else is around. Since my RC batch I've experimented with keeping a work journal, which feels similar to pair programming in some ways.

I don't claim to have pair programming figured out, but I'm glad RC fosters an environment where it's easy to try it.

On limitations

During my batch, I noticed that I enjoyed working with limited technology, whether it was old hardware, low resolution displays, limited colors, minimal rulesets, or just low-level programming. Aesthetically, I like doing a lot with a little. In an era saturated with mind-bogglingly powerful hardware and proportionally complex software, it's fun to see how far you can push something that seems hilariously simple in comparison.

I also found myself doubling down on self-imposed time constraints. Before RC I was already a big fan of game jams: events where people get together and make games from scratch in a weekend (or a month). So, naturally, at RC I ended up hosting recurring events in which I challenged myself and my batchmates to create e.g. procedural art in 1 hour, or a Playdate game in 4 hours, or whatever. It was a struggle at times, but I usually came out of it proud of what I accomplished, and I enjoyed the often-improvisational nature of the end products.

Permission to create

Basically the main great thing about RC was that I was empowered to have ideas and manifest them. For better or worse, there wasn't anyone around to tell me "no" (this is a feature of RC, not a bug :), and there were a ton of people around me cheering me on. So I made things that were interesting and valuable to me, not worrying too much about how useful they might be to others.

Parting thoughts

RC helped me rethink how I want programming to fit into my life. I'd gotten used to thinking about programming in the context of professional work, so it was refreshing to explore programming in the context of a community of self-driven individuals. I'm glad I had the opportunity not only to focus deeply on programming, but also to try out different ways of engaging with programming beyond my natural inclinations; sharing my in-progress work, collaborating with others, and leaning on the community for support.

If you're interested in joining the Recurse Center, you can use my referral link!