That Time I Quit Twitter (Week 1)

Captain’s Log

Week 1

Huzzah! It’s the first-ever edition of the Captain’s Log — a journey inside the mind of your favorite programmer/runner/conference speaker! I’m touching a ton of topics in this newsletter so I hope there is something there to satisfy all of your interests. This is the first edition and I haven’t completely settled on the format so if you have any feedback on that, let me know!

Hot Take #1: Why I “Quit” Twitter
I recently posted a status that I had retired from Twitter. I have been thinking about doing this for a long time and have outlined a few of the reasons  I had below.

  • I want to focus on making better content. I want to grow as a writer — beyond brief, impassioned rants on a platform that thrives off ephemeral reactions instead of long-lasting dialogues. I want to dedicate more time to the craft of writing and I feel the only way I can do this is to change the medium that I write for.
  • I do not want to support Twitter. Twitter, as a platform, has consistently failed the vulnerable, the righteous, and the routinely oppressed. By hosting some of my most popular content on the website, I — someone who identifies with these categories — am giving business to a harmful platform. I no longer wish to do this.
  • I want to engage more meaningfully with the people who read my content. Twitter is actually a terrible platform to have a genuine conversation with people about something, it’s not a chatroom and it’s not a coffee date. I create most of my best content using Twitter’s threading feature — which makes it easy for individuals to take a single tweet out of context and use it to spread harmful assumptions about me and my ideas. I believe that hosting my content on a platform I control will (mostly) prevent this from happening. I want people to send me an email, a direct message, or pull me aside at a conference when they have something to share about my writing.
  • I want to avoid harassment. In tangent with the second point, I’ve received harassment on some of my content that centers around diversity and inclusion in tech and comments on the inappropriate behavior of powerful individuals in the tech community. The best way for me to avoid this harassment, no matter how minimal (although I’ve been known to underestimate what is considered harassment), is to limit my engagement in the platform where it occurs.
As a result of the above, I’ll be moving my “rants” onto my newsletter/blog and reserving my Twitter for more mundane posts (like a particularly grueling winter run or the occasional self-deprecating comment) or retweets from organizations I support. I’ll be auto-tweeting links to my newsletter on Tuesdays but I’ll be limiting my engagement with other individuals on the platform around the topics that I write about.

Hot Take #2: The Stuff No One Tells You About Codes of Conduct
I was recently on rOpenSci’s Community Call to discuss Codes of Conduct. During my 10-minute (I might have gone a bit past that) presentation, I talked about some things that I think are oft-overlooked when codes of conduct are implemented in an open source project. Here’s a few quick bullets from the presentation.

  • Limit the amount of non-productive discussions that might hinder the adoption of the CoC. When looking to introduce a Code of Conduct into your project, it’s important to limit the amount of non-productive discussions and resistance that might prevent the Code of Conduct from every being adopted. The best route is to form a small committee of diverse stakeholders who can properly choose or create a Code of Conduct for your community.
  • Make sure that you have versions of your Code of Conduct in multiple languages. A Code of Conduct is a universal document that establishes a common set of virtues and principles that a community abides by. As such, the document should be accessible to everyone — and language boundaries are the easiest form of inaccessibility to remove. This also allows a project to expand their reach to an international audience by opening translation issues for the code of conduct.
  • Don’t fill your CoC enforcement board with individuals who already have power in the community like BDFLs and core contributors. It’s easy to fill the CoC enforcement board, the group of individuals responsible for enforcing the CoC, with members of the community who already hold a considerable amount of power —whether they are core contributors, active advocates, or the project founder. It’s easy because these individuals are often the ones who take on large responsibilities — like enforcing a CoC — within the project. This is not the way to go. Instead, the enforcement board should consist of diverse individuals who don’t hold “powerful” roles in the community but are endorsed and enabled by the leaders of the community.
  • Have users submit violations via a structured Google form. I’ve seen a lot of Codes of Conduct that instruct community members to submit reports of violations to the CoC via an email. I don’t think this is the best way to receive reports from individuals, instead community members should be able to make reports via a well structured Google form. This allows CoC enforcers to communicate what information is required in order to make a good judgement on violation reports. It will also guide individuals as they make CoC reports — especially as they struggle to convey a sensitive situation in an emotionally raw state.
The Community Call was great and brought up a lot of excellent nuances around the work involved in successfully introducing and enforcing a CoC to a community. Like anything involving people, Codes of Conduct are an art and a science that involve a great amount of energy and finesse. Yet another reason reason to appreciate a project’s community manager and/or diversity and inclusion advocate!

Hot Take #3: High School Never Ends
I’m a member of the JavaScript community and there was recently some controversy around the JS Awards, “a new way to recognize innovation, creativity and talent from across the JavaScript landscape.”  The award has since be discontinued as members of the community felt that it provided more visibility to already visible members of the community instead of recognizing less-visible individuals who were making valuable contributions. Other individuals felt that this wasn’t the case and that the award program should’ve continued.

The disagreement here has less to do with the award and more to do with how we allocate recognition in our communities. Recognition is a limited resource — there are only so many speaking engagements, lucrative career opportunities, and promotions to distribute amongst a limited population of programmers. As a community, we struggle to allocate this limited resource amongst each other. There is a “sweet spot” for the amount of recognition that is good for someone to have. You don’t want an engineer who is doing valuable work to go unrecognized because they might become discouraged and leave their work. You also don’t want an engineer who is doing valuable work to get too much recognition because at a certain point an additional speaking engagement or career opportunity won’t mean much to them.

The struggle to find this “sweet spot” came in full force during the JS Awards incident. The JavaScript community was called, in a very explicit manner, to make the allocation of the limited resource that is recognition upon a limited set of community members and projects. The problem with the awards was not who was on the list or what categories were in place — but the fact that the community was being asked to allocate a limited resource in a poor format. Instead, recognition should be allocated as any limited resource should be allocated — by the dynamics of a market.

The market of programmers and recognition is invariably complex and touches on a lot of things that are too illogical for an economic model: emotions, alliances, cliques, and friendships. For the market to work efficiently, it requires that each participant have an implicit understanding of how much recognition is too much and how much is too little — an understanding that is difficult to come to.

My thoughts on this are a bit incomplete at the moment but I’d like to change this. As someone who has a fair bit of “recognition” in the tech community, I want to develop a deeper understanding of the psychology, sociology, and economics that got me here. I’m hoping to dedicate more time over the next couple of weeks to relevant research on this. If you have recommendations for great economic texts to read, let me know and I’ll be sure to check them out!

What Am I Reading Now?
My Kindle is my best friend! I take it everywhere I go. Here’s the stuff I’m reading at the moment.

  • What I Talk About When I Talk About Running by Haruki Murakami: Because I’m obsessed with running, duh! I started reading this book after I finished my PyCon Canada keynote, which talked about the intersection of running and programming, since I wanted to gain another perspective on how running changes people.
  • The Federalist Papers by Alexander Hamilton, John Jay, and James Madison: During these tough political times (in the United States, where I reside), I thought I should go back and read some of the arguments used by some of the founders of the United States as they attempted to convince the people of the early nation to ratify the Constitution and birth the American democracy. It’s wonderful to read the concerns that the author brought up that are relevant today and the solutions they proposed that are still working today.
Where Am I Speaking Next?
I’ve got several speaking engagements lined up over the next coupled of months. Let me know if you’re going to be at any of these conferences and we can grab something in a cup or on a plate and chat!
  • Mobile and Web Dev Conference: I’ll be at Mobile and Web Dev Conf in early March to speak about React internals!
  • RenderConf: I’ll be at RenderConf in late March to speak about React internals (again but better)! I’m really excited to be visiting the UK for the first time!
  • OSCON: I’ll be at OSCON in early May to talk about how and why we should begin to view working in open source as a form of entrepreneurship!
Woah! You made it to the end! Thanks for reading this newsletter, I really appreciate it! Did I say something that got your gears turning, inspired you, upset you, angered you, or humored you? Reply to this email and share!

K. Thanks. Bye. Love you lots!

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