During my time at the Recurse Center, I've been a part of many groups aimed at learning a specific topic or subject. Some of these have been more successful than others. In this post I'll try to analyze what makes a successful learning/study group.

I'll do this by going through all of the groups that I've been a part of, and talking about what worked and what didn't:

Mathy ML Group

The Mathy ML group was a group that was going through Stanford's CS229 course.

I did this for a few weeks before slowly going to fewer and fewer meetings. The group went on longer, but quite a few people drifted off.

I think that this group had too many people to be successful - there were basically no meetings where everyone had watched the lectures beforehand, and there wasn't really any accountability if you didn't show up.

OS Group

The OS Group was a group that was going through the OSTEP book.

We got through almost the entire book, with the same set of people! This was the most successful group that I've been in.

I think that there are a few things that made this successful:

We had a relatively small (~7 people), very consistent group. This provided a lot of accountability, since if someone forgot a meeting, we would make sure to remind them (if they were in the space). Thus, deciding to stop attending would have to be a deliberate choice.
The OSTEP book's chapters are often self-contained and well-sized for a meeting. Additionally, they're small enough that it's pretty easy to catch up if you miss a meeting.
We had enough people that we could answer most questions that we had.

NAND2Tetris Group

The NAND2Tetris group was a group to discuss various chapters of the NAND2Tetris course.

This fell apart during the S2 → F1 batch transition, but I still learned a ton from it, so I would say that it was moderately successful.

I think the thing that was best about this group was that the NAND2Tetris material is very well suited for discussing as a group and learning as a group. We frequently worked through creating gates on the whiteboard as a group, which was far better for helping my understanding of the material than going through it alone was.

I'm not sure how to transfer this to other groups. I think what this shows is that different materials have different ideal ways of learning them. NAND2Tetris was well suited to working on as a group, whereas some books/lectures/etc are not. It's best to think about what the best way to absorb the material is, and if the group should be a discussion group, or a group where people come to work on the material together. Both have worked, but which one is ideal is dependent on the material.

Blogging Buddies

Blogging Buddies was a time slot dedicated to blogging. We all sat in the same room and worked on writing blog posts.

I really enjoyed Blogging Buddies, but I found that I didn't get much actual blog work done during them. I think that this is a product of it being just a time to work on stuff, rather than a specific set of tasks to work on.

To (hopefully) solve this, I've turned what was Blogging Buddies into a Iron Blogger Challenge. I'm hoping that this will result in me actually writing posts, while still being able to enjoy hanging out at Blogging Buddies.

Apprenticeship Patterns Reading Group

The apprenticeship patterns reading group was a group to discuss the Apprenticeship Patterns book.

It was fairly short-lived, but mostly because it was started late in the batch.

It had an interesting model of discussion - we didn't have any chapters that we were assigned to read before the meetings. Instead, people would summarize a pattern that they thought was useful, and everyone would discuss their thoughts on it.

I liked this a lot, even though (or possibly because) it resulted in some long tangential discussions.

Deep Learning Book

The Deep Learning Book "group" was me and two other people who were going through the Deep Learning Book.

This worked fairly well, for two main reasons:

The group was 3 people, so we held each other accountable by necessity - If one person wasn't there we wouldn't have the meeting.
Alok and Joe were experienced enough that we could figure out most of the questions that we had.

Because of time pressure (The S1 batch ending), we only got through Part II, but I would still call this a success.

Raytracer Discussions

This group was a bit different - Tim, who works a Pixar, ran a series of fairly open ended discussions about raytracers. There were various people who were working on implementing raytracers because of this, so the weekly discussion was an opportunity to ask about how to implement interesting features or where to go next.

This worked very well: Tim had enough experience to be able to give everyone enough help and guidance, and implementing a raytracer is fun enough that many people stayed with it for the whole thing.

Key features of successful groups

From this, I've identified what I think are the key features of a successful group:

A small enough group to provide accountability
A large enough group (or a group with enough experienced people) to be able to answer questions
Same set of people consistently (to provide accountability)
A well defined, well sized thing to read/do before each meeting
Having one person who is very experienced/already knows the material is incredibly useful

While I've seen successful groups without these, I think that each one of these increases the odds of a group being successful dramatically.

The other recommendation that I would make for starting groups and choosing groups to go to is that the time investment in a group that doesn't work out is actually fairly low, so I'd err on the side of going to/starting groups even if you think that they may fail, since the possibility that they will work is likely worth the risk that they might not, given that you'll probably only put a couple hours of time into a group that doesn't work out.

Thanks to Julian Squires for comments/feedback/discussion.