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

RC Start: Free one-on-one mentorship for new programmers

Today we’re launching a new experiment called RC Start: You can now apply to get free, one-on-one programming advice and help from members of the Recurse Center community.

Learning to program is hard. Not in the sense that you need to be exceptional to do it, but in that most of us struggle with it, especially when we’re just getting started.

For nearly five years we’ve been running a full-time programming retreat designed to help people become better programmers. Our retreat is great for professional programmers, long-time hobbyists, recent computer science grads, and people who have been programming intensely for several months. RC has helped hundreds of people become dramatically better programmers, and many Recursers have said that their time here was the most educational period of their lives.

But our retreat is not meant for brand new programmers. Folks who attend a batch of RC need to be able to at a minimum write short programs from scratch for our retreat to be useful. Up until now, we haven’t had a good way to support people who can’t do that yet.

We hope to change that. With RC Start, if you’re a new programmer, you can now get advice, pair program, have your code reviewed, and receive other support in becoming a better programmer – all without having to quit your job or pay thousands of dollars.

The deal

If you’re selected for RC Start you’ll get:

  • Three 45-minute one-on-one sessions with an RC alum. These will be either in-person or over video chat, depending on you and your mentor’s locations and preferences.

  • The opportunity to use these sessions however you and your mentor see fit. We expect most folks will do some combination of asking questions, pair programming, code review, discussing project ideas and learning resources, and goal setting.

  • Access to a private forum and mailing list so you can get help from (and help!) other RC Start participants and RC alumni.

Your mentor will be an RC alum. RC Start mentors are all friendly, thoughtful, and generous people who are excited to help new programmers grow. They are also a diverse group, and include engineers at major tech companies like Dropbox, Etsy, Google, and Mozilla; long-time hobbyists; open source contributors; and people who were very new to programming not long ago.

RC Start mentors are diverse in other ways, too: more than 40% are women, and they are distributed across more than a dozen cities, including New York, San Francisco, Boston, Seattle, Chicago, and Portland in the US, and globally in the UK, Canada, Brazil, Malaysia, Switzerland, Peru, and the Netherlands. While we expect many RC Start sessions will take place over video chat, we hope there will also be lots of in-person meetings.

Who RC Start is for

RC Start is intended for people who are in the early stages of teaching themselves to program. Perhaps you’re working through online tutorials or an introductory programming book and you’d like advice on what to tackle next.

Or perhaps you’ve been learning alone and are overwhelmed by the limitless number of things you could focus on, and want to talk with a more experienced programmer who can help you cut through the buzzwords and figure out a path for yourself.

We expect that most of the folks who participate will already be taking advantage of the many great resources available for free online. The Internet has brought us countless high-quality educational resources, from books like Marijn Haverbeke’s Eloquent JavaScript to Zed Shaw’s Learn Python the Hard Way, to thousands of tutorials, online courses, and open source projects to study and learn from.

For people fortunate enough to have access to a computer and a reliable Internet connection, a lack of tools or learning materials is unlikely to be the bottleneck for their growth as programmers. Rather, we think it’s more likely a lack of access to individualized advice and a supportive community of learners will hinder someone’s development as a new programmer.

In fact, many Recursers have said a friend answering their questions or giving them personalized advice early on was instrumental to their becoming programmers. We hope RC Start can provide this kind of support to people who don’t currently have it.

We are especially excited to receive applications from people with limited financial resources and from groups that are traditionally underrepresented in programming.

While everyone is welcome to apply, RC Start is not intended for people who have recently paid to attend (or who are currently attending) programming “bootcamps.”

Why we’re doing this

We’re doing this for two reasons, besides the fact that we think it’s a good thing to do. First, it’s something we are particularly well-positioned to coordinate given our alumni network of nearly 700 programmers.

Second, we hope some of the people who participate in RC Start will eventually come to our retreat. We also hope that people who don’t participate in RC Start are inspired to apply to RC Retreat. In both cases, we hope RC Start helps us continue to grow our community of thoughtful and curious people dedicated to becoming better programmers.

An experiment

This is a time-limited experiment: We’ll decide in a couple of months if RC Start is worth continuing based on how much demand there is and the feedback we get from mentors and participants.

This experiment would not be possible without our amazing alumni, so many of whom enthusiastically volunteered to be mentors the moment we floated this idea. We are forever grateful for our community, who both make the Recurse Center what it is and inspire us to keep working on building the best place to become a better programmer.

Curious? Learn more about applying to RC Start or RC Retreat.

Nick bergson shilcock 150 b8199afeb2ad95f104479b871218ad552bd7b23d26917dfc5b2242661107b78a

Evan Czaplicki and Yan Zhu are Recurse Center residents

We’re excited to announce that Evan Czaplicki and Yan Zhu will be joining us as Recurse Center residents this year! Evan will be in residence (again!) from February 22nd through 25th, and Yan will be in residence from July 18th though 22nd.

If you’d like to work with Evan, there’s still time to apply to the Spring 1 batch. If you’d like to work with Yan, you should apply for our Summer 1 or Summer 2 batch. Keep an eye on our blog for more 2016 resident announcements!

Evan Czaplicki Evan is the designer and developer of Elm, a purely functional programming language for web programming. He currently works at NoRedInk as an Open Source Engineer. Evan loves functional programming, Haskell, OCaml, Elm, compilers, type systems, library design, front-end programming, JavaScript, and reactive programming. He previously worked at Google and Microsoft.

Yan Zhu Yan is currently a Technology Fellow at the Electronic Frontier Foundation and a Software Engineer at Brave, a start-up in San Francisco. Since 2012, she’s been a developer on various open-source security projects like the Tor Browser, SecureDrop, Privacy Badger, and Let’s Encrypt; she was also previously a member of the W3C Technical Architecture Group. Lately she’s been working on new browser privacy attacks and building new communal warehouse art spaces in her spare time. In a past life, she dropped out of high school, did her B.S. in Physics at MIT, and dropped out of a PhD in Physics at Stanford. You can read about her security research projects and more on her blog.

Rachel vincent 150 721478ea579ac58fd8dffda7530f962fd9d8e6b94bdb5d2365585f12cac14a96

Code Words Issue Five

Update on January 4th, 2016: All of the pieces from Issue Five are now live! Check out Lauren Long’s explanation of what RESTful means and Julia Evans’ work on fooling neural networks.

The first piece from Issue Five of Code Words, our quarterly publication about programming, is now online!

As with Issue Four, we’re publishing Issue Five piece-by-piece. You can read more about the reasons why in our Issue Four announcement blog post from October.

The first piece is a guide to writing web applications in Elixir with Plug by Robert Lord (RC Winter 2014).

The issue will also include writing from Lauren Long (RC Fall 2, 2015) and Julia Evans (RC Fall 2013). In addition to all of the writers, we’d like to thank Aditya Mukerjee (RC Spring 1, 2015), Oskar Thorén (RC Fall 2012), Stephen Tu (former RC resident), Anjana Vakil (RC Fall 2, 2015) and Alex Wilson (RC Summer 2013) for all their careful editing and help. Special thanks to Dan Luu, Leah Hanson, and Victor Felder for their feedback. New pieces from Issue Five will be published throughout next week, so make sure to check back often!

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

The Finger Waggle

RC faculty waggle our fingers to show agreement in meetings, and occasionally in one-on-one discussions. This was introduced by Mary Rose Cook who originally encountered it in an activist community in Leeds, England. We’ve been using the Finger Waggle for a couple of years and the results have been both positive and surprising.

The Finger Waggle

The Finger Waggle solves the problem of people repeating each other in meetings. This can be merely annoying, but it can also have more serious consequences: it can keep the meeting from moving forward even though everyone agrees; it can focus attention on unimportant issues (see bikeshedding); and it can minimize contributions, when others appear to pass off someone’s original work as their own.

People repeat each other for many reasons: because they agree, because they see the same idea differently, to hear their own voice, or just because they’re not thinking about it. I’m as guilty of this as anyone. In the moment, it’s hard to remember that you’re in a meeting to solve a problem as a group, not to make yourself heard.

One interesting aspect of the Finger Waggle is that it solves this problem in a systematic way. Instead of relying on everyone to think constantly about whether they’re repeating each other, it gives them something else that’s natural and easy to do in the moment.

In addition to solving the problem of people repeating each other, there are a few other nice things about the Finger Waggle. Conversations generally move faster because waggling your fingers doesn’t take long. Multiple people can show their agreement at once, increasing the bandwidth of the meeting. Personally, waggling my fingers forces me to take a step back and remember why I’m in a meeting in the first place: not to be right, or to be heard, but to do my part to solve a problem.

David albert 150 0f64de6001c6a96e367d64401a6d171221d4e5af702b8e210a3cb91e7c31acdb

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
View older blog posts