a blog by Sara Farquharson

Lessons learned from a Recurse Center mini-batch

A few weeks ago I impulsively applied for the August mini-batch at the Recurse Center. I’d been idly daydreaming about attending Recurse when traveling to New York seems feasible again, assuming I could figure out how to make it work with my job. I then realised that the one-week mini-batch would only require me to take a week’s vacation, and this year’s virtual events meant I wouldn’t even have to tack on the stress of travel!

My 5-day batch in mid-August was over in a flash, but I had a lot of fun. Here’s some things I learned, in no particular order:

Lesson 1: RC isn’t just for coding wizards

I stressed out quite a bit about applying, because I had in my head that RC was for “real” programmers who do things like write compilers and start open-source art projects and understand Haskell and finish any of their side projects. Mostly this was because everyone I talked to who had been through RC seemed so smart and accomplished. It was intimidating!

Despite my fears about not meeting the “higher standards” for the mini batch, I was accepted and made to feel totally welcome. I met people at Recurse with all sorts of backgrounds, from career changers and bootcamp grads to very experienced engineers. The only thing everyone has in common is a drive to learn new things.

I don’t know that I would have applied to RC earlier if I had known I wasn’t “too junior” to be considered, but I sure would have been less anxious about my application!

Lesson 2: About 50% of a mini-batch is socializing

The mini batches happen during the first week of each incoming batch. For the people attending a full or half batch, this first week is a chance to get familiar with Recurse, meet everyone, and figure out what you’re going to work on. There’s a lot of events scheduled, and new members are encouraged to attend as many as possible. It makes sense to focus on mingling if you have five-plus more weeks to work on projects, but what if that week is all you get?

I planned to spend the whole week heads-down coding, but in the days leading up to the start, the escalating number of emails and invites and meetups forced me to reconsider. While it would certainly be possible to attend a Recurse batch and not participate in the social events, it seems like a giant waste of opportunity.

The first day is pretty heavy on scheduled events, which I decided to lean into and not worry about “being productive”. After that I made sure to attend one or two events that sounded interesting every day, and let focused work happen where it may.

I unfortunately picked a project that was hard to collaborate on, but I did do a few pairing sessions on unrelated problems and overall was happy with how I divided my time.

Lesson 3: Remote pairing requires clear communication

I was excited to try out pair programming at RC, since it’s not something I’ve had much opportunity to do at work. One of the first events was a pair-programming workshop, which I think went really well. I did another pairing session that I felt I floundered a little on without the additional structure of the workshop.

It quickly became clear to me that if both parties have access to edit the code but can’t see each other, clearly stating who is in the driver/navigator roles is very important. If you’re both in the same room you have body language to work with (and can’t both be typing at the same time) so there’s a little more implicit communication, but over the internet it’s all verbal. This is always harder than I think it’s going to be!

There were inevitable technology glitches with the remote coding platform we used, which sometimes made it so the other person couldn’t see what you typed. This drove home the importance of you both being in agreement about who is supposed to be typing.

I still don’t know what the proper etiquette is when neither pair knows how to proceed and you need to look things up. Do you both halt and research? One person read their findings out loud? There’s probably no one right answer to this.

Lesson 4: Don’t try to learn a language and complete a project in one week

My goal was to make some serious progress on writing a distributed key-value store in Rust, and by mid-week I was buried in error messages about lifetimes and borrowing. This phase of learning Rust is apparently known as “fighting the borrow checker”. I felt a little frustrated at my lack of progress, and also blocked from working collaboratively.

It’s possible a more outgoing person would have found a way to turn these error messages into a pairing problem, but my reaction to being confused is to silently read seventeen different articles, which isn’t ideal for collaboration. Instead I only worked with other people while ignoring my main project.

If I were to do this again, I would pick a goal of either learning a new language (ie, learn Rust by doing small problems every day) or a specific project (make a web app), but not both at the same time in one week.

Lesson 5: Virtual RC replicates many aspects of in-person events—including the social anxiety

My first reaction to logging in to Virtual RC was exactly the same as when I showed up to !!Con—panic that I didn’t know where I was supposed to go or which room the first event was being held in! Is it ok if I stand near these people or are they all friends who know each other and I’m just being weird?! I don’t know the etiquette for touching things so I don’t want to touch anything! o no! (In both cases things turned out fine.)

There were very cool aspects of the Virtual RC platform: I got the feeling of being in a space with other people without having to be in a Zoom call all day, there were defined places to go for events, and the audio rooms were a cool way to create and join voice chats in a low-friction way. It took most of the week before I got comfortable making links and notes, but if I spend more time there I can see it feeling second nature.

The main downsides I found were that the interface is a little opaque if you’ve never seen it before, and there was rarely an easy way to casually discover what other people are up to without asking them directly. On the one hand this latter point helps enforce the “no back-seat driving” social rule (you can’t shout into a conversation without joining it); on the other hand approaching people directly without first receiving social cues that I would be welcome is a major anxiety trigger for me.

Virtual RC has ways for people to indicate what is going on in a given room, but I found they were used haphazardly. Often I would see a group of interesting people on a call and have no idea if it was ok to wander in, or if it was something you had to sign up for in advance.

This was counteracted by the fact that many events were announced on Zulip and visible on the calendar so it’s not like I had a shortage of events. I just wish there was a way to casually overhear what’s going on in a room without (metaphorically) throwing open the door and announcing your name!

I am interested in seeing how the platform continues to evolve, and also looking into other “hallway track” platforms.

Lesson 6: It’s okay to relax

My week at Recurse coincided with a week of beautiful weather in my city and a few social commitments I hadn’t planned on. Rather than stress out about all the coding I wasn’t getting done and working late into the night, I tended to log off shortly after the East Coast contingent disappeared (mid-afternoon my time), and go read a book in the sunshine.

I was a little disappointed in my lack of coding progress, but when my week ended I still felt excited about programming! I continued working on my Rust project through the weekend and got it working by Sunday.

The end result of not pushing myself was I had a relaxing vacation, met a bunch of cool people, and still succeeded in achieving my target for my Rust project (if a couple days late.) A++ would recommend taking breaks and naps and coffee chats!

Overall I had a very good time at virtual Recurse Center, and I look forward to maybe attending a batch in New York in the future.