This summer, I was honored to give my first keynote address to the Open Source Bridge conference. It was my first F/OSS conference, and a wonderful place to start: full of interesting people, excellent talks, and good conversations, and a place where I felt like I might belong.

Stumptown Syndicate is the organization that runs Open Source Bridge and other volunteer-run Portland open source events. With more funding, these volunteers could focus their energies and do even more to create welcoming, accessible events.

Sumana Harihareswara has offered to match $15k of donations made by Dec 29th, and has written eloquently about why she’s doing so. I share her vision for a more hospitable community, and I want to support Stumptown Syndicate in creating and sharing resources to make it possible for more spaces like this to exist.

I’ve donated because I want to contribute to sustainable, welcoming spaces in F/OSS and because I want Open Source Bridge to be even better in future years. Join me and donate by the end of the 29th (today!) and your donation will have twice the impact.

I decided to leave what had been a promising career in organic chemistry about a year ago. Deciding to leave my program, and then to leave the field entirely, was one of the hardest decisions I have made. I had more resources than many in my position: savings and financial support, enough work experience to feel confident that I was making a realistic decision, and supportive friends and mentors. Still, that decision meant that I lost my plans, my confidence in my career trajectory, and my identity as a practicing scientist.

One of my biggest losses was a clear(ish) path forward. In chemistry, and particularly in academia, your mentors and your observations help you form a mental career map of sorts. Undergrad (graduation) leads to a bench job or graduate school (the latter may be much like that bench job, but with worse management and less compensation); the bench job leads to a dead end (in Big Pharma, at least), an “alternate career path”, or to graduate school. Graduate school traditionally leads to academia, industry, or work at national labs (or that “alternate career path”). Academia has the postdoc-to-postdoc-to-tenure track path; “industry” covers a lot of territory, but there is an expectation of moving either laterally or vertically within and between various companies (assuming there are jobs); and similarly, there are opportunities for career progress and moving up the ladder in national labs. None of these are easy paths, of course, but I was surrounded by the institutional knowledge that they were possible.

When I left, I left the territory that my maps covered. That same institutional knowledge whispered that leaving a program is failing; that “alternate career paths” are well and good for those who couldn’t hack it on the “normal” paths; that a master’s degree is an admission of inferiority, not a proud acheivement. I had never judged my friends and partners who had left their own programs and changed fields, but it was somehow different when it was me.

Humans aren’t very good with change. We create meaning around the stress and soften transitions with rituals and rites of passage. Each of the change-points on the map I described would have been marked with a ritual: graduations, heading to happy hour after quals, the ritual challenge of the thesis defense and the addition of “Dr.” to one’s full name, a handshake and congratulations on a raise or promotion, ordering business cards with a new title, heading to lunch with coworkers when a new coworker arrives or when one leaves for grad school, going through the arcane and labryinthine process of setting up accounts and office space at a new institution. We go through rituals to enter a program, and the process of graduate school itself is arguably a rite of passage that culminates in a final challenge, renaming, and shared food and drink. There is nothing to smooth the process of choosing to leave.

When I made my final decision to leave, I could feel what I was losing and that I needed to mourn. My grandmother had died at the beginning of the year, so grief, and irreversible change were already on my mind. My family grieved by coming together to share food, drink, stories, and ritual. None of those elements need to be restricted to mourning a death. I wanted the support of my community for this loss as well.

I invited my friends to a wake of sorts. No one ended up coming in mourning wear, but a dear friend brought me funeral lilies with a sheepish expression and that set the tone for the evening. We ate, we drank, and we chatted. Eventually I talked a bit about the choice I’d made, why I’d invited them, and my hopes for my future. My friends shared their hopes, reassurances, and anger on my behalf and their own wishes. I led a series of toasts and curses for what I’d been through and what I wished were different. I acknowledged what I had gotten from that part of my life. I cried for what I’d experienced and what I’d lost.

Those of us who leave the paths “everyone” knows are no less brave and resourceful than those who follow them. I’ve posted the invitation I sent out for the “wake” I held below the cut. If you think that anything I’ve shared here might help you navigate your own changes, please take whatever is helpful, change it to fit you, and pass it on. We can map and mark our new paths together.

Read the rest of this entry »

My final report is up on my MediaWiki progress reports page! I’ll have a more thoughtful reflection post up in the next week or two, but if you want a peek at what I’ve done, head on over and check it out.

When I started my internship with the WMF this summer, it was clear that I would need to be able to learn quickly and effectively for most of the summer. My mentor had recently been to Hacker School, where she’d encountered the idea of engineering learning styles. She wanted to know how I learned so that she could point me to the resources I’d have the best chance of absorbing, and asked me if I’d be willing to take Soloman and Felder’s questionnaire and see where I landed on the various scales.

I ended up with a moderate preference for reflective/intuitive/global (click here for a description of the categories).
I’ve posted my detailed description and reflection below the cut. How do you learn best?

Read the rest of this entry »

For the last part of my internship, I’m adding a search function to the Java Wiki Bot Framework. Unfortunately, the Java ecosystem has had other ideas. JWBF uses Maven, a common build automator and dependency manager, and I’ve had a difficult time getting it working on my own system. (I wrote about the things I tried here.)

Partly because of the frustration of getting such a simple program up and running and partly because it’s been a decade since I used anything besides a scripting language, I’ve had a hard time getting myself to work on the project itself. Tonight I jumped into the Java method problems at Coding Bat. It’s all online so there’s no need to struggle with classpaths or system-specific differences. I’ve been enjoying it, kind of like I enjoy working math where I know the steps, or enjoy balancing redox equations.

Note to self: doing little bits of code practice is kind of like washing up the glassware you know you’ll need so you can just get started on the next reaction whenever the one running decides it’s done. Gather ye momentum where ye may.

I’ve been looking at web API client libraries in a lot of languages for my OPW internship project: Python, Perl, Ruby, and most recently, Java. Fortunately for me, the Java Wiki Bot Framework (JWBF) is the clear leader in the available libraries, so it was the only one on my list to evaluate.

That evaluation was challenging! I hadn’t written or read any Java since my first CS class–about a decade ago now. Since then, I’ve been working with interpreted languages, not compiled ones (see: Python, Perl, Ruby). The idea of dependencies becoming relevant at compile-time was strange to me (what, you can’t just check whether it’s installed properly with import jwbf?!). I’d never used Maven, and the project-based structure with a zillion subfolders was not intuitive. Auto-generated documentation (JavaDocs) were available, but it wasn’t clear what was expected from one (not to mention what a good one was.

I’ve learned a lot since I started wrestling with this. I now know about:

  • Limitations of JavaDocs. Basically: good for granular description of packages and methods, but your project should really have a separate larger-scale document that talks about design goals and the overall approach behind your implementation.
  • The internal structure of JWBF. mediawiki/actions is where most of the methods you’ll want your bot to use are kept.
  • What the deal with Maven is. Turns out it’s not an IDE, but rather a build automator and a dependency manager. It connects to Maven Central, an online repository that a lot of dependencies can be downloaded from.
  • How to start a project in Maven, how it handles dependencies, and (broadly) how I might use JWBF vs. hack on JWBF.

I also found a handful of debugging links (using the Eclipse IDE), which I haven’t tried myself yet. They’re on the table for next week’s work.

I have about two weeks left in my internship, and in that time I’ll make a handful of improvements for the project. I’ve already starting rewriting the README to be friendlier to and more informative for new Java developers, and soon I’ll start drafting a higher-level supplement to the JavaDocs, including information on which packages a MediaWiki API client developer should start with. Code-wise, I’ll be implementing a search function to address this feature request and writing the tests and documentation to support it.

Since I’ve reached the part of my internship where I need to evaluate a Ruby web API client library and had never written Ruby, I went looking for places to learn! Some of these are books, some are websites, some are web tutorials. All are online and free. If you’re new to Ruby, give these a shot!

Books:

Ruby Best Practices: http://cdn.oreillystatic.com/oreilly/booksamplers/7_Ruby_Best_Practices_Sampler.pdf
Previously available for free at http://blog.rubybestpractices.com/. The author is now working on Practicing Ruby: https://practicingruby.com/
Interesting links from Practicing Ruby: https://practicingruby.com/articles/meditations-on-bad-and-good-code-1 and https://practicingruby.com/articles/meditations-on-bad-and-good-code-2 .

Programming Ruby: The Pragmatic Programmer’s Guide: http://ruby-doc.com/docs/ProgrammingRuby/
When people talk about “pickaxe book” this is the one they’re talking about! This version is fairly dated:
“This book documents Version 1.6 of Ruby, which was released in September 2000.”

Why’s (Poignant) Guide To Ruby: http://mislav.uniqpath.com/poignant-guide/book/
If you want an off-the-wall introduction to Ruby, this one has cartoon foxes.

Mr. Neighborly’s Humble Little Ruby Book: http://www.humblelittlerubybook.com/

Learn Ruby The Hard Way: http://ruby.learncodethehardway.org/book/

Web-based tutorials:

Ruby Koans: http://rubykoans.com/
Make things work! Also downloadable.

Try Ruby: http://tryruby.org/
More in-browser Ruby tutorials.

Codeacademy’s Ruby module: http://www.codecademy.com/tracks/ruby
Interactive web-based Ruby lessons.

RubyWarrior: https://www.bloc.io/ruby-warrior/#/
Adorable game where you write Ruby code to move your warrior and defeat enemies.

Misc:
A MIT OpenCourseWare handout that has a no-frills guide to some basics and talks about differences between Ruby and Python: http://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-170-software-studio-spring-2013/recitations/MIT6_170S13_rec3-Ruby.pdf

Ruby Style Guide: https://github.com/bbatsov/ruby-style-guide . I’ve been told that this is as close as the Ruby community gets to consensus on what “good Ruby” looks like.

command line ruby cheat sheets: http://cheat.errtheblog.com/s/rvm

Ruby Cookbook is not freely available, but the all the code from the book is: http://www.crummy.com/writing/RubyCookbook/

Ruby is definitely not what I am used to, but it seems like an interesting language and I’m looking forward to learning more of it when I have more time.

When I decided to start working in tech, I knew that someday I’d find my place in the informal women-in-tech backchannel warning system.

It seems that I’ve already reached a place where I can practice two kinds of post-conference networking: the standard mild awkwardness of “Hello! Remember those interests we share? I think you are a professionally interesting person!” but also “Hey, heads up–I’ve been made aware that a person you socialized with has a history of sexually assaulting incapacitated women, and thought you might want to know.”

I knew I’d get here sooner or later.

I wish I’d been able to finish my first internship before I did.

I was honored to give the final keynote at last week’s Open Source Bridge 2014. My talk was titled “‘Why are these people following me?’: Leadership for the introverted, uncertain, and astonished”. It is the story of how I learned and claimed my leadership skills–because leading and conveying authenticity are both learnable skills.

This talk contains brief and nonspecific mentions of emotional abuse and thoughts of suicide. The video skips in several places; I’ve filled in the transcript to the best of my memory, but if you happen to have more complete notes or corrections send them my way!

Video and transcript are below the fold. This talk is licensed CC-BY-SA.

Read the rest of this entry »

I am not back from WikiConference USA 2014, but I am settled in here to work and decompress for a few days. I attended the conference to give an intro-level talk and workshop based on my own work getting up to speed with the MediaWiki API, and to meet more of the larger Wikimedia community. I also got the chance to meet technical contributors whom I’d previously only interacted with on IRC and the wikitech-l mailing list. It’s good to be able to put faces to usernames. I also chatted with Asaf Bartov, a contributor to Mediawiki::Gateway. Asaf confirmed my first impressions of the library’s scope and quality–a good check for my work.

So, the talk! If you’re interested in the basics of web APIs (or MediaWiki’s in particular), my slides are available on Wikimedia Commons. Video for the talks will be up soon–see the WikiConference USA 2014 category for more photos.

Slides for talk
Slides for workshop/demo

I aimed the talk at an audience that was not wholly nontechnical but that would include non-programmers. Based on this feedback, it looks like I succeeded! https://twitter.com/kos2/status/472415903993589761https://twitter.com/kos2/status/472415903993589761

More highlights of the conference:

Sunday was the open space/unconference day. We started off with lightning talks (I talked about the Seattle Attic as a feminist hackerspace) and then I attended Sumana’s Diversity/Ally Skills training, using the Ada Initiative’s publicly licensed materials. We had about an hour until the next round of lightning talks (very cool stuff: Book scanners! Publicly available Israeli laws! 5-shot method of shooting video! Gender visualizations! Wikidata and maps!) so we only got through a couple of scenarios. The attendees at the Ally Skills training had wanted to keep going, so I agreed to lead another session in the afternoon.

It was an interesting experience, and it sounded like many of the attendees got a lot out of it. It was surprisingly/not surprisingly emotionally draining to run but I was glad to be able to offer this. The workshop offers concrete suggestions about how to deal with sexist words and actions as they come up, as well as some basic feminist background for people who may never have considered how some of these principles apply to their own life, and does it in the format of private small-group discussions. I am grateful to everyone who participated, shared, and listened in both of the sessions yesterday. I suspect that those conversations gave many of us things to think about. They certainly did to me.