Hacker School is now the Recurse Center. Read more.
Enjoy programming? Check out Code Words, a quarterly publication from the Recurse Center community.

Advice for new Recursers

The Recurse Center operates on a schedule of overlapping batches, which means that when a new batch starts, half of the people in the space are entering their second six-week rotation at RC. On the first day of each batch we give welcome talks to help give the new batch a sense of what to expect from their next twelve weeks at RC.

We’ve recently started inviting the people starting their second half of RC to stand up during the welcome talks and share some advice with the new folks. They always have really wonderful things to say, and so last week we started an advice stream on Zulip, our internal chat system, to allow alumni to chime in.

We realized that some of the advice people have shared could be helpful for programmers everywhere, not just Recursers. We’ve included some of it below – we hope you find it useful!

On setting goals

Andrea FeyDon’t try to do all the things, unless that’s really what you want to do. Set a goal or two and get feedback from your peers about whether your goals are clear and attainable.”
- Andrea Fey, Winter 2014

Gonçalo Morais“It is okay to change your goals. I wanted to dive deep into Node.js when I got to RC, but after a week I decided to spend the 3 months learning Haskell just for the sake of it. And it was glorious.
- Gonçalo Morais, Spring 1, 2015

On pushing yourself

Ilona Brand “If a project makes you uncomfortable, question why that is. If it’s like: ‘Ah! I can’t do this, it’s too hard!’ then it’s probably worth doing since RC is such a good environment for that. If it’s more like: 'Eh, am I even into this?’, try to get to the bottom of why you feel that way before immediately turning away. My biggest and best project at RC made me so uncomfortable because of how hard I thought it would be that I also thought I wasn’t interested in it. Turned out I was just afraid, which made it all the better of a project!”
- Ilona Brand, Fall 1, 2015

Sumana Harihareswara“It’s fine to ask people if they might want to pair program with you. Sometimes you will be rejected. That is fine. If you never get rejected maybe you’re not taking enough risks!
- Sumana Harihareswara, Fall 2, 2014

On managing stress

Nat Welch“Write a lot. When you feel tired, go to sleep. RC will still be there when you wake up. Burn out isn’t any fun.
- Nat Welch, Spring 2, 2015

Veronica Hanus“We’re all coming from different places/types of experience, and people are really aware that certain things (outside stuff, inside stuff, just learning so much so fast) can be hard and affect different people differently… if you can deal with your stress right away, you can get back to doing what will make you happiest in the end: building stuff.
- Veronica Hanus, Fall 2, 2015

Tim Sell“If you have a really bad day or two days, or week… just make sure you come into the office anyway. Sometimes turning up is the most important thing.”
- Tim Sell, Summer 1, 2015

On being flexible

Liz Sander“It’s nice to have one or two big projects to focus on, but don’t worry about getting sidetracked for a day or three. I spent a few days learning Prolog and, although I still can barely write a basic program in it, I learned so much.”
- Liz Sander, Summer 2, 2015

David Hargat“One day, I didn’t have my laptop. I decided to spend the day pairing with people and reorienting myself and my goals… and it turned out to be one of my most productive days at RC. I recommend to anyone who feels even slightly lost to forget about your projects for a day - talk to people, pair with people, ask for advice, float around.”
- David Hargat, Fall 2, 2015

Lindsey Jacks“It’s totally okay to spend time learning something and not focusing on a project. I always got scared by the 'What are you working on?’ question, when really a perfectly reasonable answer is 'Learning more about how x works.’
- Lindsey Jacks, Fall 1, 2015

On taking care of yourself

Richard Harrington“Take walks during lunch. As Javier Ernesto Olaechea (S'13) told me during my batch, Friedrich Nietzsche said you should never trust any thought you have when you’re sitting down. I wouldn’t go quite that far – I’d say you can have them while sitting down, but make sure to confirm them while on a long walk.”
- Richard Harrington, Summer 2013

Andrew Drozdov“There’s so much to be done while at RC, but make sure to take care of your health. Eat well, sleep well, and try to get a little exercise each day, even if it’s a walk around the block.”
- Andrew Drozdov, Spring 1, 2015

Michelle SteigerwaltGet a journal and be honest in it! When you’re done, you’ll have an amazing souvenir of all the personal growth you’ve accomplished!”
- Michelle Steigerwalt, Spring 1, 2015

And finally…

Pablo Torres“Keep this handy at all times.”
- Pablo Torres, Winter 2014
GIF of owl being pet

Rachel vincent 150 721478ea579ac58fd8dffda7530f962fd9d8e6b94bdb5d2365585f12cac14a96

Why am I saying this?

My cofounders and I adopted the no well-actually rule before we even started the Recurse Center. Almost immediately, it made working together more pleasant because the rule made us aware of an annoying tic we all had: Making pedantic “corrections” that were usually more about serving our own egos than contributing to the conversation at hand.

Having a friendly, named social rule made it easy for us to catch ourselves and avoid derailing our conversations or building resentment. Even better, it was straightforward to give and receive this feedback because it was inside a framework we’d already agreed to. Pointing out a well-actually became a genuinely lightweight piece of feedback, akin to pointing out a style guide violation like inconsistent indentation or a missing semicolon.

When we started the Recurse Center, it was obvious we should incorporate no well-actually’s, since the rule had worked so well for us internally. It worked for RC as well, and over the first few batches, we noticed other unpleasant and educationally destructive behavior and added three corresponding rules. This included acting surprised when someone doesn’t know something (no feigned surprise), interrupting conversations or pairing sessions with unsolicited advice (no backseat-driving), and minor and usually unacknowledged sexism and racism (no subtle -isms).

Throughout this process, we’ve come up with some guidelines for when social rules are helpful, and what makes a good one. Specifically, a good social rule should target behavior that is:

  • Relatively common. There’s little value in a social rule about things most people never do.

  • Done unwittingly. Much of the value of our social rules is that they let people recognize annoying things they didn’t realize they were doing. Most people don’t intend to be annoying. This means the behavior shouldn’t be overtly malicious, and this is why “don’t call people idiots” isn’t a good social rule but “no subtle -isms” is.

  • Fairly minor. The behavior should be more like a pinprick than a punch. Our social rules are meant to provide a means for frequent, friendly, and lightweight peer-to-peer feedback, to provide a release valve so pressure doesn’t slowly build over time.

  • Specific and easy to correct. This is why “don’t be a jerk” isn’t a useful social rule but “no feigned surprise” is.

Our social rules have helped make RC a better educational environment, and a remarkably pleasant place. We introduced our fourth and most recent social rule in the summer of 2012. We’ve considered others since, but we’re reluctant to add more, because we think it’s more effective to keep things simple and have a few, easy to understand rules.

Unfortunately, not all annoying behavior meets the criteria above. So what do you do if you want to further reduce bothersome behavior in your community and yourself, but you can’t even pinpoint what it is that makes certain things annoying?

An experiment to make myself less annoying

Early this year, I came up with a way for spotting my own annoying behavior. I call it, Why Am I Saying This, or WAIST for short.

The idea is simple: Before I say something, I ask myself, “Why am I saying this?”1 I’ve found this to be especially helpful when writing online, for instance, in chat channels or on mailing lists. But I’ve also found it useful for in-person conversations, including meetings and group discussions, and it’s even been helpful when thinking back on past conversations: Why did I say that? If I’m responding to someone’s question, am I trying to answer it (or better understand what they’re asking), or just boost my ego? Am I trying to be helpful or just look clever? Am I trying to contribute to a conversation or just make sure people know I Have Opinions? Why did I make that bad joke that disturbed the flow of the meeting?

Since adopting this approach, I’ve found myself revising or even deleting chat messages and occasionally holding my tongue in meetings2, because I realized after reflection that I had unhelpful motivations. I’ve also found that WAIST is like a macro you can use to discover potential social rules. In fact, I think you can derive all our social rules from it.3

There are two pitfalls to consider if you try this yourself. First, you have to be willing to honestly question your motives. It’s easy to trick yourself into believing your motives are pure when they’re not, especially when there are plausible good ones (for instance, convincing yourself that you’re making a joke just to make others laugh, and not primarily because you want to appear clever). But doing so doesn’t get you anything: The goal of WAIST is to realize when you’re doing things that annoy other people, and fooling yourself here just robs you of an opportunity for growth.

The second pitfall is self-censorship. Clearly, you could take this too far, and become paralyzed questioning every little thing you do. Thankfully, this pitfall is easy to avoid: Just try WAIST for a week or two. All you have to do is reflect occasionally on why you’re about to say (or previously said) something.

I was pleasantly surprised by what I discovered.

  1. If anyone’s curious, I’m writing this post for two reasons: First to advertise RC (and hopefully encourage people to apply), and second because I hope it will further curb annoying behavior inside our community.

  2. As anyone who works with me knows, I should probably learn to talk less and listen more in meetings. I’m working on it!

  3. The connections between feigning surprise, well-actually’s, and backseat-driving and WAIST are relatively clear. For subtle -isms, the answer is, unsurprisingly, usually more subtle. But the reason typically boils down to an unexamined stereotype or belief about a group of people (for example, consider the riddle about the father and son in a car crash).

Nick bergson shilcock 150 b8199afeb2ad95f104479b871218ad552bd7b23d26917dfc5b2242661107b78a

Why research

Michael Nielsen, our first research fellow, started working at the Recurse Center one month ago. This is an email I wrote to RC faculty and staff last week about research at RC. The goal was to communicate the business case for having a research lab at RC. This means it doesn’t address a lot of important questions like what sort of research we will be doing, and how our research lab will fit with the rest of RC. We’re still figuring out the answers to these questions, and I’m going to write more about them in the future as we make progress. The email has been slightly modified to remove some personal information.

Now that Michael has had some time to settle in, it’s worth revisiting why we have research at RC. The last time we talked about this was at an offsite in the spring, before several of you had joined the company.

We’re running a research lab for three reasons: We think it will make RC a better learning environment, we think it will attract more great people to RC, and we think it’s an interesting thing worth doing in its own right.

I think Michael’s presence has already made RC a better learning environment: He’s given seminars that have been well received,1 and worked with a couple of Recursers on projects related to his research. One experienced alum cited Michael’s presence as a reason for coming back to RC to do another batch.

It’s less certain whether the research lab will convince more people to apply to RC. Good research takes time and is often not flashy. Frequently there is tension between good research and good marketing, and good research is our priority. Figuring out how to use the lab to convince more people to apply to RC without negatively impacting our research will not be easy and requires balance, taste, and patience.

We think research fits well with RC’s mission of building the best place for people to become better programmers. One of my favorite parts of our blog post announcing our research lab is the idea of discovering new abstractions or “power tools” that let people build more impressive, intricate, and beautiful software in less time. At RC, we spend a lot of time helping people become better programmers as individuals. It seems logical that we should also be working to help all programmers become better by giving them more powerful tools to express themselves.

We think we’re well positioned to run a research lab. We’re not part of a university, so we can sidestep the problems generally associated with research in academia (pressure to publish regularly, constant grant writing). Because we’re not building our business around the specifics of the research done at RC, we have much more freedom than most industrial labs. We also have a unique environment full of people with a wide range of backgrounds and ideas, a fantastic alumni community, and the ability to approach things from first principles and have a long-term outlook.

Our goal is to discover new ideas and distribute them as widely as possible. None of the research done at RC will be patented, and we will have a permanent license to distribute the results as widely as possible (researchers will retain copyright to their work). This makes it easy for us to collaborate with researchers elsewhere and does the most good for the world.

While we can’t know if this experiment will work in the long run, we’re planning for success and we want to make sure we don’t end up starting from scratch when Michael’s fellowship is over. Assuming we can afford it, our plan is to hire 1-2 more researchers to join Michael before he leaves.

A useful way to figure out what we should try next is imagining a version of RC that is the size of a large university and asking yourself what it would look like. It seems inevitable that research would be a big part of that future version of RC, and there’s no better time to start than now.

  1. Notes from Michael’s seminar on Douglas Engelbart and Augmenting Human Intellect are available on GitHub.

David albert 150 0f64de6001c6a96e367d64401a6d171221d4e5af702b8e210a3cb91e7c31acdb

Star Simpson, Tim Abbott and Marijn Haverbeke are Recurse Center residents

We’re excited to announce that we have Star Simpson in residence this week, and that Tim Abbott and Marijn Haverbeke will be joining us at the Recurse Center as residents later this fall!

If you’d like to attend the Winter 1 batch to work with Marijn and other residents like Star and Tim, apply to the Recurse Center. Keep an eye on our blog for more resident announcements!

Star Simpson Star is a currently unafilliated electronics hacker and aviation enthusiast with a passion for the potential transformative power of applications for drone technologies. She was fed Perl as a baby before discovering embedded programming and has been trying to unlearn habits learned therein ever since. She’s currently in residence (10/5 - 10/8) at the Recurse Center, and is working with folks on Haskell and Swift projects.

Tim Abbott Tim was the CTO and co-founder of Ksplice, which developed technology for updating a running Linux kernel without rebooting that was running on over 100,000 production servers when it was acquired by Oracle in 2011. After Oracle, he co-founded Zulip, a powerful group chat application, which was acquired by Dropbox in 2014. Tim is currently the technical lead for Dropbox’s main server platform. In his spare time, he advises startups, enjoys hiking, cooking, and board games, and leads the Zulip open source project. He will be in residence at the Recurse Center next week (10/12 - 10/16), working with folks on Zulip.

Marijn Haverbeke Marijn is the author of Eloquent JavaScript. His technical interests range from programming languages to distributed systems to databases. He runs a small lifestyle business around his open-source projects, such as Tern, CodeMirror, and ProseMirror. He’s made important contributions to the Rust compiler. He will be in residence at the Recurse Center from 11/16 - 11/19.

Rachel vincent 150 721478ea579ac58fd8dffda7530f962fd9d8e6b94bdb5d2365585f12cac14a96

Code Words Issue Four

Issue Four of Code Words, our quarterly publication about programming, is now online! Well, partially online.

We’re taking a different approach to publishing this issue. Rather than publish all of it at once, we’re going to spread publication of the pieces in Issue Four over the next two weeks. We’re doing this for a few reasons:

  • Our team is small and far-flung. The folks who write and edit the pieces are mainly alumni and current Recursers. They put an amazing amount of effort into each piece they work on, but we recognize that they all have busy lives and live in different time zones. For some folks it can be hard to coordinate the work, and we’d like to have a model that allows for as many folks to contribute as possible while removing some of the deadline stress.

  • A more spread out publication schedule will give everyone more flexibility. We’ve found that in publishing issues of Code Words we often have a piece or two that’s ready early or on time, and a piece or two that needs another week to make it great. There’s also a lot of work to be done after all the pieces are ready for publication, and delays happen at that point in the process, too. We’d like to have that time built in to our publication schedule in a better way than having padded deadlines. We also know that sometimes writers and editors can’t complete an article on time or at all due to events beyond their control, and we’d like to have a process that allows for these possiblities (this happened twice in Issue Four) while also allowing us to publish on time.

  • We want Code Words to be as awesome as possible. With this issue we were faced with the choice of publishing a full issue on time, or holding off a bit and giving the authors and editors time to make changes and additions to the articles that would make them better. We decided that the second option was better.

We’ve just published the first article of Issue Four: Hack the derivative by Erik Taubeneck (RC Summer 2013), which presents an interesting result in computational science, involving a clever use of complex analysis to give an efficient way to compute estimates of derivatives.

The issue will also include writing from Darius Bacon (RC Fall 2, 2015 and Fall 2012) and Mudit Ameta (RC Spring 2, 2015). In addition to all of the writers, we’d like to thank Joel Burget (RC Spring 1, 2015), Alan O'Donnell (RC Summer 2011 and facilitator emeritus), and Leo Martel (RC Summer 2, 2015) for all their careful editing and help. Special thanks to Gonzalo Bulnes, James Keene, and Mudit Ameta for the help and sympathetic eyebrow-furrowing they lent us in fixing a last-minute bug. New pieces will be published mid-next week, and the week after next. We’ll start publishing Issue Five in mid-December, and will maintain a quarterly publication schedule.

As a preview of Issue Four, here’s a line from Darius’s piece which I loved, and which I believe captures the mission of Code Words nicely:

…try to work out the basics of a subject for yourself: simple ideas are still out there undiscovered or forgotten, waiting to be put together.

Code Words is written and edited by the Recurse Center community. Like the Recurse Center itself, we aim to make Code Words accessible and useful to both new and seasoned programmers, and to share the joyful approach to programming and learning that typifies Recursers. Code Words contributors retain the copyrights to their work, and provide their essays under the terms of the Creative Commons BY-NC-SA 4.0 license.

If you’d like to receive updates about new issues and news about the Recurse Center, sign up for our mailing list.

Rachel vincent 150 721478ea579ac58fd8dffda7530f962fd9d8e6b94bdb5d2365585f12cac14a96

Zulip: Supporting OSS at the Recurse Center

Today, as the result of an ambitious Dropbox Hack Week project, Zulip, the real-time group chat app acquired by Dropbox last year, is being released as open source software. We use Zulip every day at RC, and with today’s release, we’re excited to kick off a few experiments in collaboration with the original Zulip team and Dropbox in order to help build a sustainable open source community around the project. As part of that effort, Zulip cofounder and current Dropboxer Tim Abbott will be spending a week at RC early next month.

Why we’re excited to contribute to Zulip

We switched to Zulip from IRC both for our internal company communications and for the whole RC community nearly three years ago, and it’s since grown into an indispensable part of RC. We now have about 700 people on our internal Zulip realm, and they log in from all over the globe. Zulip has allowed RC alumni who live in other countries and timezones to ask and answer technical questions, get and give advice, and stay connected to the community long after their time at RC has ended. And we strongly prefer Zulip to other options for several reasons – its message threading being a key one. It’s not an exaggeration to say Zulip has made RC a stronger community and a much better place to get programming help and advice.

We’re especially excited about this announcement because we think RC is in a unique position to help build a healthy open source community around Zulip. Zulip is institutionally important to us, and we have an alumni network of hundreds of programmers who use it regularly, many of whom are excited to make it better.

Helping jump-start a community with new contributors

A perennial challenge of nearly all open source projects is finding and on-boarding contributors. Below are three things RC and Dropbox are doing to help Zulip get off the ground as an open source project.

First, Dropbox flew two RC alumni, Nemanja Stanarevic and Jonathan Dahan, out for their Hack Week last month. Nemanja and Jonathan joined Neeraj Wahi (an RC alum and new Dropboxer) and a team of Dropbox employees to help prepare Zulip for release as open source. Our alumni were among the nine guests, including folks from several other Zulip customers, who Dropbox hosted for the week and who contributed to open sourcing Zulip. In the process, Nemanja and Jonathan also began learning Zulip’s architecture and code base, and I’m happy to say they both plan to continue working on the project going forward.

Second, Zulip cofounder and chief architect Tim Abbott will be in residence at RC for the week of October 12th. During his time here, Tim will be giving a technical overview of Zulip’s architecture, live-coding a new feature, and preparing a list of high-value projects for people interested in contributing. Tim’s goal in coming to RC is to help spread knowledge of Zulip’s internals beyond the handful of Dropbox employees currently familiar with them.

Lastly, RC facilitator and alumna Allie Jones plans to hack on Zulip at RC, both on her own and with interested Recursers. Allie already has a local build running, and has begun making experimental changes to speed up parts of the interface.

Looking ahead

Keeping an open source project alive and healthy requires good documentation, instructions for setting up and running the code, and people willing to help build a community around it. We’re thrilled that Dropbox and the Zulip team have invested the time and energy needed to release Zulip in a thoughtful and responsible way, and we’re excited to do our part in making it a successful open source project.

We would like to thank Leo Franchi (F'12), Jessica McKellar, Tim Abbott, Jeff Arnold, and Waseem Daher at Dropbox for all their work on Zulip and support of RC over the years.

Nick bergson shilcock 150 b8199afeb2ad95f104479b871218ad552bd7b23d26917dfc5b2242661107b78a

Four new Recurse Center residents

We’re excited to announce that David Turner, Ranjit Bhatnagar, Stephen Tu and James Coglan will be joining us at the Recurse Center as residents in the next few months!

If you’d like to work with David, Ranjit, Stephen, James, or residents like them, apply to the Recurse Center. Keep an eye on our blog for more resident announcements!

James Coglan James has been working on the web for nearly a decade, mostly in Ruby and JavaScript across many parts of the stack. He maintains a number of open-source side-projects, including Faye, Canopy and jstest, and last year published JavaScript Testing Recipes. He currently works at FutureLearn and is trying to work on his coaching skills. He’d like to know more about functional programming and building languages. James will be in residence from September 14th - September 17th.

Ranjit Bhatnagar Ranjit Bhatnagar is a sound artist who works with technology, language, and found materials to create interactive installations and musical instruments. His works have been exhibited across the United States and Europe. Ranjit recently worked with the art collectives, Flux Factory and Rabid Hands, to build a large-scale musical installation at Palais de Tokyo in Paris. His interactive sound work, Singing Room for a Shy Person, commissioned by Amsterdam’s Métamatic Research Initiative, previewed at NYC’s Clocktower Gallery in 2013 and moved to Museum Tinguely in Basel for the Métamatic Reloaded exhibition. Ranjit will be in residence from August 30th through September 3rd.

Stephen Tu Stephen Tu is a graduate student at UC Berkeley in the EECS department. His research interests include both theoretical and practical aspects of optimization and machine learning. He has worked on various open source contributions including developing various probabilistic models for data-microscopes, implementing semidefinite program solvers in mlpack, and various contributions to a previous version of Facebook’s HipHop compiler. He still dreams of one day building his own programming language, despite a failed attempt many years ago. Stephen will be in residence from August 30th through September 3rd.

David Turner David Turner hacks on git and Pants at Twitter. He enjoys recursive backtracking, Unix, Free Software, and board games. David will be in residence from August 17th through August 20th.

Rachel vincent 150 721478ea579ac58fd8dffda7530f962fd9d8e6b94bdb5d2365585f12cac14a96

Three reasons to apply (and three reasons not to)

We frequently describe the Recurse Center as being like a writer’s retreat, but for programming. What does that really mean, and why do people choose to uproot their lives and families to move to New York to do RC? In this post, I’ll try to answer that question, but instead of describing what RC is (which we’ve done elsewhere), I’ll share a few reasons why people should consider applying to RC, as well as a few reasons why we might not be a good fit.

Consider RC if…

  • You’re a professional programmer, and you’re not growing as quickly as you’d like in your current job. Good programming jobs provide lots of challenges and opportunities for growth, but even great jobs can become monotonous, and most companies understandably prioritize building useful features and fixing bugs over employees’ growth and education. If you’re not growing as much as you’d like (or worse, you’re stagnating) where you currently are, considering coming to RC. You’ll have three months to focus on becoming a better programmer —not deadlines, company politics, or shipping code.

  • You’ve never worked as a programmer, but you enjoy it, and would like to get way better. Perhaps you’ve just discovered programming in the last few months, or perhaps it’s been a hobby for years. Regardless, RC is designed to help you get the support, guidance, and resources you need to become a better programmer.

  • You have a project, area of interest, or programming skill you’d like study or work on deeply for three months. Maybe you want to learn about distributed systems, or become a more effective debugger, or build your first substantial project in a statically typed language. RC is a fantastic place to do any of these things, since it gives you the freedom to focus on what you want, the time to make real progress, and a large network of friendly, helpful, motivated, and intellectually curious people with expertise in almost any area of programming you can think of.

RC isn’t a good choice for everyone

And for good measure, here are three reasons why the Recurse Center might not be a fit for what you’re looking for:

  • RC isn’t a good fit for people who don’t like managing their own time or setting their own goals. We do everything we can to make RC a supportive environment, and there are lots of people to draw on for advice and help, from facilitators to residents to fellow Recursers and alumni. But at its core, RC is self-directed, and most of the structure we do have is opt-in, not mandatory. There isn’t anyone at RC to tell you what you must learn or must work on, and while there are plenty of people available to provide support, it is ultimately up to you to decide what you want to focus on here.

  • RC isn’t a good fit for people who only want to work on their own. While everyone at RC spends some of their time here quietly working and learning on their own, a huge part of RC’s value comes from interacting with other people. And while we do our best to make RC conducive to focused, solitary work (for instance, we have two dedicated quiet rooms), we’re still not as good as a library or private office for this.

  • RC isn’t a fit for people who just want to make something that works, and don’t particularly care how it does. All of us fall into this category sometimes: We’re trying to build something, and we just want to make it work and don’t care if we understand how it does. In many ways, that’s the point of programming: To make things that actually work. But RC’s focus is education, not just making things run. That doesn’t mean we don’t value building things, but it does mean that RC is probably not a good fit for you if your current priority isn’t becoming a better programmer.

If you’d like to spend three months programming and learning alongside friendly, smart, motivated, and intellectually curious people, consider applying to the Recurse Center.

We’re hosting an open house

We do our best to share what makes the environment at the Recurse Center special on our blog, our mailing list and our Twitter. But we realize that the experience of attending RC is hard to put in to words, so we’re hosting our first open house on Wednesday, July 29th from 7 pm - 9 pm.

We’re hoping this event gets you excited to apply for a batch, whether you’ve never considered applying before or if you have been thinking about it for years.

The open house will begin with a short welcome talk, followed by presentations from current and past Recursers about what they’ve been working on, and a Q&A session. Food and drinks will be served.

If you’d like to attend the open house, RSVP no later than this Friday, July 24th. Please note that space is limited, and we may need to close RSVPs.

Rachel vincent 150 721478ea579ac58fd8dffda7530f962fd9d8e6b94bdb5d2365585f12cac14a96

Code Words Issue Three

We’re excited to announce that Issue Three of Code Words, our quarterly publication about programming, is now online! This issue features writing from five current and past Recursers:

In addition to all of the writers, we’d like to thank Aki Yamada (RC Summer 2013), Dan Luu (RC Winter 2013), Stephanie Losi (RC Summer 2, 2015), Darius Bacon (RC Fall 2012), Danielle Pham (RC Summer 1, 2014), Jari Takkala (RC Fall 2013), Travis McDemus (RC Summer 2013), and Mike Walker (RC Fall 2013) for all their careful editing.

Code Words is written and edited by the Recurse Center community. Like the Recurse Center itself, we aim to make Code Words accessible and useful to both new and seasoned programmers, and to share the joyful approach to programming and learning that typifies Recursers.

I’d also like to share a bit more about our process. Code Words exists because of the hard work of members of our community, and it is important to us that they are compensated for their work. And so I am excited to announce that starting with this issue, we are now paying writers and editors a stipend for each piece they work on for Code Words.

Code Words contributors retain the copyrights to their work, and provide their essays under the terms of the Creative Commons BY-NC-SA 4.0 license.

If you’d like to receive updates about new issues and news about the Recurse Center, sign up for our mailing list.

Rachel vincent 150 721478ea579ac58fd8dffda7530f962fd9d8e6b94bdb5d2365585f12cac14a96
View older blog posts