Reflections on Recurse Center: Application goals and outcomes
Introduction
This post looks at the things that helped or hindered me in achieving the goals from my Recurse Center (RC) application.
Hopefully it’s useful for future recursers or anyone thinking about applying.
Contents
Application goals
I put four main goals into my RC application:
- Deepen my knowledge of Rust
- Come away with a maze-making program written in Rust that I can use in my art practice
- Make my first contribution to an open source project
- Present something about any of these, in any format
The first goal was the primary one, with the remaining goals constituting the ‘how’ for achieving that primary goal.
How did I do?
This was how they panned out over my six-week batch:
- Deepen my knowledge of Rust ✅
- Come away with a maze-making program I can use in my art practice ✅
- Make my first contribution to an open source project ❌
- Present something about any of these, in any format ✅
Not too bad, I finished my batch having achieved 3/4, and they were the three that were the most important to me.
How did I get there?
What helped?
These are the things that I think played a key role in helping me achieve my goals during batch:
- Following the self-directives
- Having a sampling phase
- Using sampling phase data to structure the remaining batch
- Going to coffee chats
- Prioritising non-coding things
Following the self-directives
The incredible thing about the self-directives is that, if you do your best to let them guide your actions, you will almost always end up doing something that helps you (and those around you) to learn more and generally have a better time during batch.
I found that following them always led to, or affirmed, what turned out to be a productive course of action.
Why did I do this?
- I trusted RC to know what they’re talking about when it came to principles that help people get the most from their batch.
How can you do it?
- In an ideal world, you'd always be considering the self-directives in some form, but in practice this is impossible - you still have your own value system, your mood changes, you forget, get distracted etc. etc.
- It's more achievable to decide in advance the scenarios where you'd find them particularly useful. (For me, it was if I was at a loose end or I was doubting whether a particular course of action was the right one).
- When these scenarios arise, then you know it's time to really lean into and let yourself be guided by the self-directives.
Having a sampling phase
I made a concerted effort at the beginning of my batch to sample any activities / topics / projects that caught my eye. There were three great outcomes from this:
- Getting to know fellow recursers. This was especially important for getting the RC experience while it was fully virtual.
- Gaining exposure to the mind-boggling breadth of things that are possible with computing, and therefore learning a lot.
- Collecting crucial feedback for volitional muscle training.
The last one was probably the most important one for me. It helped me be more certain that what I wanted most was to pursue the goals I initially set myself. Without this sampling I think I would have constantly wondered / worried ‘Oh maybe I should really in fact be doing X’. (See the next step for more this).
Why did I do this?
- So many different people recommended this approach, so I concluded odds were on it would be useful for me too.
How can you do it?
- Use the calendar to see what’s on.
- RSVP to anything that piques your interest.
- Go along!
- Build your volitional muscles by noting how you feel before, during and after. Are you excited? Drained? Does it feel like work? Or does the work totally absorb you (in a good way!)?
Using sampling phase data to structure the remaining batch
This leads on from the previous step. I thought about my experiences during the sampling phase and looked at where my time was being spent. Doing this I realised had to drop various things, even though I really liked them, because they were taking too much time and energy from my main priorities.
It felt a little sad that I had to do that in order to make progress, but it was the right decision as I ended up only just about getting my maze program in a usable state by the end of the batch. This wouldn’t have been possible without recognising what my priorities were and allocating my time accordingly.
It's important to say that everyone’s outcome for this is going to be different. I saw plenty of people go in the opposite direction, pivoting away from what they came in with, and towards some new thing that they'd discovered at RC - and that’s really worked for them. It’s all about making sure you’re doing the thing you’re most interested in.
Why did I do this?
- Again, this approach was recommended by so many different people that it seemed sensible for me to give it a go.
How can you do it?
- Refer to the notes / recollections from the sampling phase and rank the options.
- Think about what time you need to pursue your priorities to the level you want.
- Plan your time accordingly. This may mean dropping other RC things and that’s okay.
Going to coffee chats
Finding the cadence that worked for me for coffee pairings (weekly) and then (mostly) following them through was a core part of enjoying and being productive during my time at RC.
It’s so inspiring and refreshing hearing about different people’s backgrounds and projects, I always left those calls having had learnt something new, feeling encouraged about my own projects and also lucky for being able to share time with such a talented, generous and curious group of people. Coding all the time != progressing all the time.
Why did I do this?
- I was already a convert to the idea. We had a similar functionality at my work, and I almost always left them having had learnt something or enjoyed myself or felt more connected to the people I work with (and often all three).
- I like hearing about what other people are working on and what their backgrounds are, coffee chats are perfect for this.
How can you do it?
- Stay signed up to the coffee bot.
- Choose a cadence that works for you.
- Do your best to go to them!
- Don’t beat yourself up if you miss or are late to any - make your apologies obviously - but know it happens to most people from time to time.
- Know that being a bit nervous beforehand is totally normal, the other person is probably nervous too!
Prioritising non-coding things.
This one’s fairly simple but, to paraphrase Rich Hickey, simple is not always easy!
In a similar vein to the coffee chats, prioritising coding all the time is, for me at least, a recipe for reducing the speed and quality of my learning. During my batch I tried to prioritise non-coding things that were good for me : meditation, exercise, eating well, leaving the house (😂). This meant that I gave myself the best possible chance to learn generously, at the edge of my abilities and to build my volitional muscles.
Why did I do this?
I find it impossible to work well if I’m not well rested, fed, exercised etc. etc. so avoiding this wasn’t much of an option for me.
How can you do it?
There are so many ways to approach this, so this is just a suggestion amongst many possibilities:
- Identify what things make you feel good (seeing friends, doing puzzles, eating well, listening to music etc.).
- Sketch out how much of these you think you’ll need to maintain a good happiness / functionality level.
- Get these amounts of time into your schedule first.
- Whatever time is remaining is time that you can use for RC things.
What hindered?
The things that I think added unnecessary difficulty to my batch were:
- Prioritising pairing too late
- Overthinking my second presentation
- Not taking the time to make Zulip work for me
I was surprised to see that, unlike the 'What helped?' entries, these shared a root cause - losing sight of and/or not addressing something important:
- I lost sight of key benefits of pairing, which delayed my efforts to organise it properly.
- I didn’t address the mixed-feelings I was having end-of-batch, so worked inefficiently on my final presentation…I also didn’t address how long I was spending on it, so continued to pour even more time into it.
- I didn’t address that I was finding Zulip really difficult and draining.
So if you're going to take away one thing from this 'What hindered?' section, it's this: prioritise whatever it is you need to create and sustain the headspace required to notice, reflect and act on things that aren't going well. If that's too general, read on for the concrete examples and suggestions, hopefully they demonstrate this underlying observation.
Prioritising pairing too late
I only started prioritising pairing about halfway through my batch in week three. Pairing on Rust projects was where I learnt the most in the shortest amount of time. If I’d started prioritising this earlier I would have progressed my project faster, learnt more, and had more time to explore other topics.
Why did I do this?
There were lots of people on the course who wanted to get experience pairing, as they hadn’t had much opportunity to do that before coming to RC. I think I got distracted by this and my initial thought about pairing was “Oh I do so much pairing at work, it’s not so much of a goal for me to get pairing experience”. But this totally overlooked the main benefit of pairing: you learn so much from other perspectives and skillsets when you code together.
How can you avoid it?
- Start posting in pairing stream from week one whenever you’re going to do some coding.
- Start taking people up on their posts in the pairing stream.
- If there’s something you want to know about, or get better at then prioritise pairing on it - doesn’t matter if it’s your project or other people’s as long as the domain/technology/problem type is something that interests you.
Overthinking my second presentation
The Friday presentations are five minutes long and you can present something as finished, unfinished, speculative, not-working as you want - as long as it’s no longer than five minutes. I lost a lot of my final week to this, and one week is an especially long amount of time when you’re only on a 6 week batch. To top it all off… it still wasn’t finished by the time that I presented it 🙈
How can you avoid it?
- Practice presenting unfinished things, remember how you - a reasonable person - would feel on seeing a not-completely-polished five minute presentation about someone's work i.e. totally fine with it. Banish the imaginary audience of unreasonably-critical people, that’s not RC people.
- Notice when you’re spending ‘too much’ time on something and take a step back and ask why this is happening and whether there’s anything you can do about it.
Why did I do this?
I think there were two causes. The first was that I was having very mixed feelings about being in the final week of my batch, and burying my head in a presentation was a great way to put my head in the sand and not actually address those feelings. But this wasn’t great for actually working on the presentation in an effective way. It also wasn't great for doing nice end-of-batch things, for example it meant I wasn't able to be as diligent about the niceties as I'd have liked.
The second cause was that I didn’t fully understand how I solved the problem that I was going to be presenting. This made it very very difficult (impossible?) to explain in an easy-to-understand way. So that took a lot of time. Though this was productive in a way because I learned lots about the problem and I learned that I really enjoy that type of problem (co-ordinates, vectors, transformations - linear algebra basically). So, not completely a bad thing.
Not taking the time to make Zulip work for me
Though I did spend a very long time choosing my notification noise, opting for Deep Tom (which I'm still not sure was a good decision), I did not take the time to decide on more important things like:
- What to mute.
- What to favourite.
- What order to check different notifications in.
Not doing this meant I did something different each time I used Zulip, without collecting that information into an optimised workflow.
When I use Slack at work I’ve got a really clear sequence of things to check, I know what I can safely ignore, what I can’t and so on. This means I’m efficient at getting all the information I need with minimum cognitive load.
I did not create an equivalent for Zulip at RC and that made all my time on Zulip (which is a lot when you’re remote) much harder than it needed to be. Again, this wasted precious cognitive resources that could’ve been spent on something more productive.
How can you avoid it?
- Attend RC ‘How to’ tech sessions in the first week and ask around for how different people use Zulip.
- Notice when your initial assessment of something starts drifting from what you’re actually experiencing.
Why did I do this?
I thought I would eventually ‘get it’ and a workflow would naturally emerge without me having to allocate dedicated time for figuring this out. Even when this was evidently not happening, I clung to rather than questioned this initial assumption.
Wrapping up & up next...
Hopefully there are some useful nuggets in there for future recursers. If nothing else it's certainly given me more clarity on how I'll approach the next batch I attend.
The next post will reflect on the goals I took into this batch but weren't written up in my RC application...