A return statement; is a post to describe and reflect on one's time at the Recurse Center1. I completed my batch last week, and decided to follow this tradition to close out the RC series of posts on this blog.

This post goes over the highlights of my batch, a combination of the technical stuff I learnt, and most importantly the discoveries I made - about myself and my approach to programming and learning in general.

Starting a personal project

I've had a mental block regarding personal coding projects for the longest time, and thought that working on multiple, tiny projects at RC would be the solution to the problem.

Initial attempts at tiny projects left me with mixed feelings:

I was looking for something more, a programming project I didn't get bored of.

A chat with a fellow Recurser, a two-day break from RC and lurking in a group project encouraged me to finally commit to a project in Week 6 - tuntcp.

This was the big turning point of my batch, I started looking back on the first 5 weeks more positively thanks to this, despite them being all over the place. And while this was the opposite of a tiny project, something about it felt right.

After hopping between projects for a while, it was great to have moments of focused programming, where I was also learning things in line with my goals.

This also made me realize that I'm a fairly good programmer, who can write decent code outside of one-off shell scripts.

Overall, this project really boosted my confidence, and my approach to RC changed for the better after this. One such change was in the group project I mentioned earlier.

Contributing to a group project

A group of Recursers from a previous batch kept weekly meeting to work on a C implementation of Julia Evans' Implement DNS in a Weekend.

My batch started when they were probably half-way through the guide. I started off on the listening end in the first few weeks, as I was unfamiliar with the code and was intimidated to contribute.

At one point, I considered dropping out of this session, as it was taking up a big chunk of time, and I wasn't gaining much out of it. However I continued to attend, hoping I would contribute someday.

That day finally came in Week 7, as I lead the group session for the first time. Working on tuntcp gave me the confidence of writing C code, and the 6 weeks of observing made me familiar with the codebase.

This project was also responsible for the initial progress of tuntcp, as I used the project's source code as inspiration for the code structure.

I went from wanting to leave this session, to completing the core of the project on the last day of my batch.

Pair programming + coffee chats

Pair programming as a concept is first introduced during the pairing workshop, as part of the orientation events. By the end of that session, I was a fan. I knew this would become my favorite way of learning, and looking back at 31 pairing sessions on my calendar, I was right!

Pairing is when I find myself most engaged with the task at hand and make significant progress or learn something new. A downside is that it demands a lot of energy and focus, which meant I had to schedule these carefully.

It also contributed significantly to building my volitional muscles, as many of these pairing sessions were initiated based on what I found interesting2.

Here are some pairing highlights:

Another form of 1:1 interactions I enjoyed were coffee chats - casual chats with fellow Recursers. I really looked forward to these, as these were the closest I got to informal chats one would have when attending in-person.

It was a great way to meet people with both similar and completely different interests, and to get to hear about different approaches to programming, learning and even jobs.

Impossible Stuff Day

Impossible Stuff Day is a day organized by RC to work on something that is well beyond what you're currently capable of. The idea is to take the first step towards doing something seemingly impossible, and seeing how far you can get.

This concept clicked really well with me. The first Impossible Stuff Day in Week 3 helped me get unstuck, while the second one in Week 9 exceeded my own expectations.

The week of the first Impossible Stuff Day was possibly the lowest point of my batch, as I was unsure of what I really wanted to do. I'd heard about how installing Gentoo Linux helps you understand how the operating system really works, as it's installation requires a fair amount of manual configuration.

I didn't attempt it until then as I was fine with the current Linux distribution I was using. However, it seemed like a good idea for Impossible Stuff Day, and after some doubting, I committed to installing it as a Virtual Machine on my laptop.

It took me two days, but I did it! I experienced lots of firsts - partitioning disks, configuring the bootloader, selecting drivers to install and compiling the kernel! It made me more willing to try different things, even if they didn't feel important to work on in that moment.

By the time the second Impossible Stuff Day happened, I felt like a completely different person, and my choice of project reflected that.

I created and hosted a tiny Capture The Flag challenge using Docker on a DigitalOcean droplet. I wrote a blog post covering all the details and gave a presentation about it the week after, which was also well-received!

I think I blew my own mind with this project. This was the first time I made something that people could try out, and that too in two days! It's the closest I got to working at the edge of my abilities, and it felt great.

Learning in public

Learning generously is a big part of RC and is encouraged from the very first day. I did so in three significant ways - blog posts, written checkins and presentations.

I had picked up blogging again shortly before RC but didn't have a regular schedule. So I thought blogging during my batch would be a good way to establish a schedule.

There were initial troubles, as it was hard to find time to write with so many activities going on during the week. The momentum came in the latter half of my batch, where I posted once every 7-10 days.

Writing the posts themselves was a tedious process - I'd start with a good idea, but would excessively edit my post while writing it, to the point where I'd be annoyed by the time I'd hit publish. It's something I'm still working on getting better at.

I posted written checkins daily as an accountability mechanism during my batch. Writing these came naturally to me, and became an integral part of my days at RC as someone attending entirely remotely.

I also wrote weekly reflections as part of the checkins each Monday, where I reflected on the past week - what worked, what didn't and what to do differently. In hindsight, this is what kept me fairly on track, I would have been a lot more distracted otherwise.

RC hosts Presentations every week, where Recursers present what they're working on in 5-minute time slots. Attending this made me feel closest to the community, as almost all Recursers would join in the call every Thursday.

Since my focus was on blogging, my approach for presentations was "whenever I felt like and had a cool topic to talk about", which happened to be a total of three times:

I enjoyed presenting, and it was a good practice on how to convey information in a limited timeframe, despite the preparation taking forever.

Finding a routine that works for me

Being self-directed meant I was responsible for making my own schedule.

The first two weeks were a little confusing. I was adjusting to Zoom fatigue and an 8-hour time difference (Zoom fatigue being the bigger problem), which meant that the scheduling was slightly all over the place.

Around Week 3, I figured a set of hours that worked - with my timezone and core RC hours. I kept the core RC hours being open for chats, group meetings and other events, and did solo work either before or after that.

Scheduling things within those set of hours was another task. I had all different kinds of weeks, ranging from great to not great. I realized that my ideal schedule requires an equal mix of social interactions and solo work. Overdoing any one will leave me feeling completely drained.

How I ensure this balance post-batch will be an interesting task. At least I have the weekly reflections and checkins to help along the way.

Discovering a field I like

I came to RC with a vague idea of the topics I liked - Linux, security, networking, and low-level programming. I came to RC to find a field or job role that included the right combination of these interests.

Thanks to coffee chats and exposure to so many different topics, I found DevOps to be a field that matched my interests the most.

This gives me a good idea of what I need to learn next, and makes the job search easier as I know what I'm looking for.

What's next?

The Recurse Center helped develop a set of learning strategies that work for me, and now is the time to put them to practice.

At the end of a batch, you Never Graduate, and can continue to be a part of the community and events. That's what I'll be doing for a while - working on existing projects (maybe starting new ones?) blogging, pairing away and learning new things.

I remember thinking "this is exactly what I was looking for" when reading through RC's website for the first time, and it still holds true three months later.

Notes

  1. This Return Statement from another Recurser goes explains the origin of the term. ↩

  2. I'm particularly feeling this post-batch, as I'm a lot better at initiating/joining pairing sessions where I end up learning a lot. ↩