The One Where I Quit Cold Turkey (Week 4)

Captain’s Log

Week 4

Week 4? Woah! Yeah. Week 4. I’ve managed to keep this going for far longer than I thought it would. Thanks for being a subscriber and sticking with me through rough patches and typos. It’s been a pleasure becoming a better writer with you. Don’t unsubscribe just yet because there is plenty of good stuff to come. Starting with this newsletter!

Why I “Quit” Open Source for 30 Days

Anyone who follows me on Twitter knows that open source is a big part of my life. It’s an obsession that started during the summer of 2015 when I submitted my first pull request to the pandas project. After this initial involvement, I became extremely involved with open source. I’m the kind of person who dives into things very quickly. It wasn’t long before I was an influential member in the open source community (or so I like to think). At some point, I started to question my involvement in open source. Was anything I was doing really useful? What is the end goal of all this? How can I use this to advance my career and my self? Do people appreciate my work? Does any of these mean anything in the places where it matters? A torrent of questions flooded my mind and I questioned myself, my existence, and the value of my work and contributions.

On December 7th, 2016, I unplugged for 30 days from the open source world. As it turns out, when you really care about something, “quitting” is very hard to do. I realized that clicking the GitHub bookmark on my browser was like a nervous tick for me and it took a lot for me to resist the urge to scroll through my GitHub feed and triage issues. It took a lot for me to not engage with people about open source on Twitter (which was one of the many reasons I created the newsletter). And my goodness, the emails I had to ignore. Needless to say, the first week or so was very difficult, but eventually I got used to it.

Here’s the thing, my life without open source is so…boring? I ate, showered, slept, ran, watched Netflix, ate, slept, ran, worked, showered, ran, watched Netflix, slept, ate, ran….you get what I mean. Most people would call that relaxing but it felt tedious and unfulfilling to me. I felt like I was on a journey without a destination.

During my hiatus, I tried to outline some of my goals with respect to open source. These goals had several requirements. They (1) couldn’t be project specific, (2) should involve more content creation than consumption, and (3) shouldn’t be code-oriented. The goals I outlined were as follows.

  • Create more resources to help maintainers effectively manage open source projects
  • Put more effort into advocating for the retention of URMs (underrepresented minorities) in open source
  • Advocate for an open source mindset in non-technical communities

Over the next year, I’ll be working on several projects that align with these goals. I’ve already started on a project that addresses the first goal and I’m actively looking for opportunities to address the second two. “Quitting” open source was very hard, but very necessary. My mind feels detoxed and prepared for the mission ahead. Watch out world, Safia’s ready!

The Code of Conduct: A Misunderstood Document

There was recently a discussion in one of the open source communities I belong to about including a Code of Conduct. I didn’t participate in the discussion because those things tend to be emotionally debilitating for URMs. I did follow the discussion closely, though.

As with any CoC discussion, there were several arguments that were made against the CoC or with the intent of weakening the enforcement capabilities of the CoC. I’d like to dissect one of the arguments that was made in that discussion, and in many others, here. The argument claims that CoCs can harm individuals from different cultural backgrounds in situations where translations/linguistics misunderstandings can make something sound harmless in one language but cruel in another.

But cruelty is a universal dialect. I’ve yet to see an example of a CoC enforcement in which a member of a community was unfairly punished because of linguistic barriers. This argument also trivializes what a Code of Conduct is designed to protect against. For those with privileged backgrounds, “things that come off the wrong way” are the cruelest form of harassment they’ve experienced on the Internet. For those with less privileged backgrounds, the Internet is full of legitimately harmful threats and language. Believe it or not, people say things to underrepresented minorities and the underprivileged that are degrading and cruel regardless of what language they are in. That’s what a Code of Conduct is designed to protect against. Codes of Conduct weren’t created to aid in cross-cultural misunderstandings, that’s a deeper problem that isn’t going to be solved by a few individuals on the Internet who belong to a cultural bubble.

A Code of Conduct also does not prohibit free speech. Unless your idea of free speech consists of calling people who look like me “nigger” and rating women based on their looks, you have nothing to worry about. This is another one of those “false concerns” that is pitted against CoCs, and really any document that outlines cultural mores. It also ignores a critical aspect of most democratic government documents throughout the centuries: there is no such thing as absolute free speech, there never was, and there never will be. For as along as we are a species that forms social groups, the things you say will be judged by your peers and used to make judgments for and against you. Your peer group reserves the right to ostracize you if they collectively agree that the statements you make are harmful to the vitality of the group. There’s nothing unfair about that; it’s just life.

Codes of Conduct are misunderstood documents. Often times, by virtue of the skewed demographics in open source, the people attempting to implement Codes of Conduct are not the people who are going to be helped the most by them. This concern differential results in a misunderstanding of the intent and execution of CoCs. At a minimum, they are a message to the underrepresented in your community that you care about their well-being. At a maximum, they provide a legal framework for protecting against discrimination and ensuring digital civil rights.

Absolutism Kills

I recently posted a quirky tweet about how the singular work “datum” can be used as an intermediary variable when mapping over lists or doing other iteration tasks. I posted a snippet of code along side the tweet and received a barrage of responses to the effect of “But you should never name a variable ‘data’!” This is absolutely nonsense and touches on something that has always bugged me about the tech community. There tends to be a sense of absolutism that is accompanied when people share programming tips — an absolutism that disregards the nuances that come with programming. I’ll admit, I’m guilty of having this absolutist tone in several of my Tweets and writings. Absolutism is sometimes the best way to grab attention but, like all things that grab attention, it has consequences.

A Subtractive Approach to Learning Programming

I have a problem with the way that most code schools and online tutorials teach programming nowadays. The focus tends to be on learning frameworks and syntax with the intent of developing applications. This is fine and dandy for the modern needs of technical industry. I’d like to see a shift in the way that we approach learning to program, both individually and in group environments. Programming, like most tasks in engineering and sciences, involves iterating through a search space and identifying the optimal solution to a particular problem. Becoming a skilled programming is about reducing the size of the search space for a particular problem that you need to address — you become a good programmer when you need to try fewer things before you get to the “right” solution. People subconsciously gain the ability to navigate the technical search space as they could more and more, but I’d like to see a stronger focus on this “subtractive” approach to learning to code. Instead of teaching people the “right” or “best” way to do things, which is hard to do anyways, we should strive to show them the wrong approaches with hopes of reducing the amount of energy they expend on a particular problem. As a result, I’m going to be a bit more purposeful about following this approach in my technical talks and open source mentorship work.

What Am I Reading Now?

Update! My Kindle and I are engaged now. I’m looking forward to obsessing about flower arrangements over the next couple of weeks and sharing more great reads with you!

I hope you liked this newsletter! Be sure to share it with friends, family, coworkers, and pets (dogs read too!). Until next week, engage!

Your captain,



Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s