8 bits of advice to flourish at the Recurse Center

Aside from the interesting new friends, S-tier programmer memes, and new work opportunities, why would someone want to spend 6–12 weeks doing Recurse?

Because it’s one of the most potent environments for growing both your taste and agency as a programmer.

High-intensity environments like startup accelerators can help boost your agency, but can ruin your taste. Low-intensity environments like online courses can develop your skills but can’t teach either taste or agency.

The magic of Recurse is the balance of intensity and community, which enables almost any curious programmer to grow in both their ambition and volition. It’s easy to leave university or a job knowing how to do without knowing what to do. Recurse allows you to develop both in tandem and rekindle your love for programming along the way.

This is part of my Return Statement for my Fall ‘24 batch at The Recurse Center (RC). I’ve already written about what I made at RC and my own Recurse experience.

This post is my 8 bits (yes, that’s 1 byte) of advice to make the most of your time at Recurse. These are the things I wish I had known going into my batch and had to figure out along the way. I hope they serve you well.

0. Plan religiously, then religiously discard plans

Reflect, write up plans, share them, re-evaluate them. Repeat.

Plans are worthless, but planning is everything. – Eisenhower

This kind of externalised reflection and recalibration is extremely valuable to almost anything you do in life and Recurse is no exception. The RC faculty regularly organise events to help facilitate this kind of deliberate re-evaluation throughout your batch. Actually go to these and actually write the things out. Revisit your previous plans and review your stated goals and methods.

A prime example of this is refining RC projects based on your personal interests and motivations.

Another example: I reflected on my progress after the 8th week. Some questions I reflected on that proved helpful:

• What currently seems like the most fun to me?
• What am I learning the most from doing?
• What work am I most proud of so far?
• What would I be annoyed to leave RC having not done and learned?
• What sort of engineer / scientist / developer do I want to be in 2 years time? What skills do I need to get there?

1. Explore hard, then exploit hard

The first couple weeks are much less “productive” than you expect. A great deal of the time is meeting your batchmates, trying out different activities, and developing healthier motivations.

With the variety of interesting people at RC, it can be easy to stack every day with eight hours of meetings, coffee chats, and group co-working. But then you’ll never feel like you’ve really done anything.

Trying many things and meeting many people is valuable in the first few weeks. Thereafter, bias towards a focussed and deliberate commitment to a few projects and groups. This pattern somewhat repeats in weeks 7 and 8 if you do a full batch.

The explore/exploit tradeoff tells us how to find the balance between trying new things and enjoying our favorites. – Algorithms to Live By, Brian Christian and Tom Griffiths

At first, bias towards high-exploration. Oversubscribe yourself. Meet with lots of people, drop into many groups, participate in all you can.

By the start of week 3, you’ll have a much clearer sense of what’s going on, who you vibe with, and what’s tugging at your curiosity. That’s when it’s time to switch to “exploit” mode. Double down on the 20% of the activities and people that give you 80% of the learning and fun.

You should still leave ample room for serendipity. Just optimise for the activities and people that reliably enable it.

2. Distinguish homework groups from hangout groups

It’s common to get access to the Recurse calendar and immediately become overwhelmed by the sheer volume of fascinating and varied activities each week.

It’s also common to spend the first few weeks jam-packing your schedule with events that appeal to you. (Of course I want to attend the Vim enthusiasts’ chat and the mechanical keyboards show-and-tell and seven different study groups for Nand2Tetris and the Rust developers’ Cargo pants workshop.)

A key realisation is that some of these are homework groups and others are hangout groups:

• Homework groups require significant additional preparation each week in the form of reading chapters, watching lectures, or advancing a project. Try many of these out at least once, then ruthlessly prioritise which couple you will devote yourself to.
• Hangout groups require much less offline effort, but more online intentionality. These hangouts can be a waste of time if you all sit around chitchatting, but can be a valuable learning environment if you come prepared with something to share or questions to ask. They’re also great sources of fun and serendipity.

At the end of week 2, I wrote an overview of all my homework and hangout groups, as well as all the weekly requirements. This allowed me to prioritise and make sure I completed all the “homework” ahead of time.

3. Ship constantly

Like real muscles, growing your volitional muscles requires more than a plan. At some point, you have to just hit the gym and put in the reps.

Write code every day. Write words every day. Then git commit and git push.

Always ship! The momentum compounds on itself each day you maintain the streak and your ultimate gains reflect that.

4. Write a lot, but not only code

Write to think and write to communicate.

Conversation and writing are the two great catalysts for thinking:

• Writing requires the greatest clarity of thought and the most rigour, which is essential for actually advancing the frontier of your understanding.
• Conversation is less precise, but has higher variance and spontaneity, which is exceptionally helpful for igniting the sparks of new ideas.

Some people like to write concise and streamlined essays. Others prefer a conversational stream-of-consciousness style. Either way, write and share it with others. It’s a fantastic way to grow during RC (and beyond) and one of the best ways to learn generously.

5. Absorb tacit knowledge and emit vibes

Tacit knowledge and vibes are powerful. They are ubiquitous at RC, which is a large part of why it’s so great.

We often learn the most when just watching someone who knows a lot about a thing do that thing. There is an abundance of tacit knowledge to be absorbed from diving into the deep end with someone much further along the learning curve.

Navigating someone else’s codebase or just watching them work often reveals unknown unknowns.

Conversely, you don’t know what you know until you try answering other people’s questions. Remember that your own vibes and knowledge are almost invisible to you, yet often invaluable to others. What may seem trivial or obvious is often a key insight that you’ve absorbed but someone else has yet to.

Fortunately, many stupid questions aren’t actually stupid and are helpful in guiding the more experienced person to clarify their own thinking.

6. Systematically prioritise projects

I had been thinking about doing RC for a while, so I brought a lot of project ideas into my batch. Within days of gaining access to Zulip and having intros with my fellow batchmates, I had about twice as many ideas, all pulling me in different directions.

So how do you go about refining and prioritising?

Explicitly declare your motivations

I began by spending an afternoon clarifying my own motivations. Whilst I recommend this process to everyone, the specifics are highly dependent on your values, tastes, and goals.

My current guiding mantra is “Become Stronger. Defy Nature. Have Fun.” I spent several hours expanding on each of these aspects and following each thread to its terminal values. I found it helpful to sketch my ideas on paper in an unstructured, scrappy way and then organise them into typed bullet points afterwards.

Specify your project criteria

Based on my motivations (and some suggestions from RC faculty), I developed a list of project criteria.

Sparing you most of the details, my motivations involve the pursuit of mastery and fun via the feedback loops of ambitious and audacious projects; and then communicating openly and effectively to others.

Based on that, a good project for me would have most of the following properties:

• Requires me to work at the edge of my abilities in at least one skill or tool (ideally multiple)
• Optimises the gradients of fun and learning
• Encourages me to follow my curiosity whilst honing my craftsmanship
• Either deepens my abilities (mastery of fundamentals or pushing frontiers) or broadens my abilities (learn new tools, strengthen weak skills)
• Encourages me to develop new intuitions by either exploring a fractal bud, or connecting existing abilities in interesting ways
• Encourages doing (programming and writing) over planning (analysing and researching)
• Is shippable (constrained and can be completed and delivered)
• Is shareable (can freely and easily be publicised before, during, and after)
• Is ambitious and audacious, but achievable (by me)
• Encourages me to work deeply and in a state of flow
• Has tight and rewarding feedback loops
• Invites collaboration from others (and enables them to build on my work)
• Leaves room for serendipity
• Involves my personal interests and hobbies in some way
• Is something both useful and usable by me (and ideally others too)

Within the context of a Recurse batch, a good project also:

• Is achievable in <2 days (small project) or 2-5 days (big project) – in reality, these will be hopeless estimates anyway
• Allows me to pair program and thereby to learn with other Recursers and improve my pairing skills

These criteria were immensely helpful for refining the project candidates and prioritising the ones which remained.

Project examples

• BAD: Fiddling with my website configuration and not even showing it to anyone.
• GOOD: Learn Rust, macOS system APIs, and Homebrew by writing a CLI tool that monitors M-series GPU usage. Deploy to Homebrew and write a blog post about how I did it and what I learned.
• GOOD: Learn Three.js and improve my vanilla JavaScript skills by developing a 3D browser game based on my interests. Deploy via Vercel, share on Zulip, and invite feedback during Game Dev meeting.

7. Don’t sweat it too much

Fun is a virtue too and Recurse is one of the best places in the world to have fun with other programmers. Lean into that! Your enjoyment is infectious.

Thanks to my fellow 2024 Recursers for all you taught me and all the fun we had along the way!

Caption: A low-res video of me fooling around with the webcam shader I made during a Creative Coding session. Try it here.

Thanks to the whole Recurse faculty for all the great work you do to make RC a fun, productive, and incredibly welcoming environment. Few places can simultaneously push people to do impossible things and cultivate such an all-permeating sense of intellectual safety and curiosity. It’s all the things most oddballs like me really wish school could have been, and I’m deeply grateful to have experienced it.

1. If you’re soon starting at Recurse, I wish you well and hope you have as good a time as I did!
2. If you’re thinking of applying, you absolutely should!
3. And if you’re looking to hire talented, versatile, and self-driven programmers, reach out to the Recurse talent team. Few organisations have such an impressive and well-vetted talent pool to draw from.

Thanks for reading! If you’re interested in any of my projects, working with me, applying to Recurse, etc. then please do reach out on X, Bluesky, or by email. If you think other people might like to read this or any of my other posts, I’d appreciate you sharing it with them directly or via social media.

Discuss this post on Hacker News.