Monitorama 2014 wrapup

I’m just settling back into the daily routine after RelEng/RelOps’ workweek and then Monitorama back-to-back.

Videos will eventually be posted here.

I thought it was awesome the conference started with some #hugops.

Here are my highlights:

  • I gave a talk about crontabber! I have my speakers notes if you’re interested!

  • Dan Slimmons gave a nice talk about basic probability and how understanding the difference between sensitivity and specificity can help you choose more useful alerts. It was super basic stats stuff, but a good foundation for building up stats competency in teams.

  • James Mickens gave a hilarious talk about the cloud that is well-worth finding when it goes up.

  • Ashe Dryden gave a talk about gender issues and “our most wicked problem”. It was very well-received by the audience, which was gratifying for me personally. I think the audience walked away with some very practical things to do: speak up among peers when someone says things that make you uncomfortable and ask questions about equal treatment in your company for things like salary, perks and benefits.

  • Several talks were given about monitoring and managing ops inside companies. My favorite was from Daniel Schauenberg (contributor to statsd) of Etsy. and Scott Sanders spoke about similar topics in this presentaton on Github’s outage lifecycle. And related, but not at the conference, Heroku just published an incident response runbook.

  • There was a hilarious lightning talk about the failure of the Swedish ship Vasa as an object lesson for massive project failure. Here’s a link to the case study the lightning talk was based on.

  • Larry Price (@laprice) gave a 5-minute talk about Postgres autovacuum tuning, which was awesome, and I hope he posts the slides. It reminded me that I should do a couple brownbags about Postgres config this summer!

  • I was struck by how many people said they used Postgres in production. Someone else asked the question during a talk, and nearly half the audience raised their hands.

  • InfluxDB, a new timeseries database emphasizing an HTTP API (remind anyone of CouchDB? :D), seemed interesting, although maybe rough around the edges when it came to documenting useful features/best practices. When I mentioned it on Twitter, I found a few folks already trying to use it in production and got at least one bug filed. :)

  • I also saw an amazing demo of Kibana, which seems like a very interesting dashboard/investigation/querying interface to Elastic Search. I watched a friend deploy it in about an hour to look at their ES systems last Wednesday.

  • Dashing from Shopify was also very interesting, although a rubyist project, so not easy to integrate with our Pythonic world. However, putting on a contributor relations hat — it could be a wonderful and beautiful way for contributors to interact with our many APIs.

I’m looking forward to the videos coming out and a list of slide decks, as I missed a few talks during hallway track conversations. I met several people who are managing similar or larger event loads than we do with Socorro, so it was fun swapping stories and seeing how their software stacks are evolving. RabbitMQ was a weapon of choice for reporting environments, along with Storm. Lots of love for Kafka was out there for the people dealing with real-time customer response.

Overall, highly recommend attending Monitorama to dip a toe into the state of the art with regard to system operations, monitoring and ops management.

The Final Crontab: an introduction to crontabber

I gave a talk at Monitorama today about crontabber. (slides)

My coworker tells me that I left out the part of “why you should care” about crontabber from my first few slides. So here’s a list:

  • Retries jobs on failure automatically
  • Dependency-aware, and won’t execute child jobs that depend on parents that have failed
  • Nagios integration including support for WARNINGs and CRITICALs, and configurable escalation from WARNING to CRITICAL (e.g. 3 WARNINGS == CRITICAL).

Those three are probably the top features sysadmins who are not happy with how cron is managing jobs wish they had.

Crontabber needs at least Python 2.6, Postgres 9.2, is FOSS and being used in production. We’ve used a version of the code since February 2013, and currently have the python module version you can install with pip install crontabber is currently running in our stage environment.

Let us know what you think!

PyLadies Meeting notes from “Negotiating the job market: a panel discussion”

Flora Worley organized a fantastic PyLadies PDX meeting called “Negotiating the job market: a panel discussion“.

The meeting was organized in three parts:

  1. Experiences (good, bad and ugly) from four women who entered the software industry in the last 1-2 years.
  2. Managing expectations and setting boundaries from three people, two recent entrants into the industry, and me.
  3. Negotiating the application/interview/offers process (which we turned into a group discussion, led by one panelist)

We kicked things off by asking people to get into groups of four and talk to each other about why they came and what they were hoping to get out of the meeting.

Some of the comments from the meeting and feedback after included:

  • On what was good prep for interviewing: Attending PyLadies and Python User Group meetups to learn new skills, hear about what modules and techniques people are using. (from Amy Boyle, a local developer)
  • Attending PyLadies helped fill in gaps in knowledge useful as a working programmer, even after having a CS degree.
  • “I love being a Pylady, and if it weren’t for this community, I honestly don’t know that I would have continued learning to code.”

Below are my notes from the first panel, anonymized and edited a bit.

How did you find your first job in the industry and know it was the right place for you?

  • I knew a founder of the company from college
  • Knew someone and they invited me to apply. Wrote a great cover letter and got an interview even though they thought I didn’t have the skills for the exact job I applied for.
  • Got the job by going to talks and staying and talking to the speakers.
  • Decided I was more interested in data than my major! Looked around and found a company that was doing a lot with data.

At what point do you say you “know” a programming language?

  • I shy away from saying I “know” something — seems presumptuous to say that the same way it seems weird to say “I’m a writer.” If you’re getting paid to do a thing, though, then you get to call yourself the “thinger”. Coworker has been asking me for help with python and I know the answers to his questions so…
  • Finding ways to help others with things is a good way to boost your confidence.
  • Once I give a talk about something, I have to say I know how to do it because people will come to me for help. It’s a way to force yourself to cram, find out what you know and really don’t know. On my resume I don’t say “I know” — I say “I have experience with XYZ; I have managed to learn these things to get the job done.” Most technical interviews ask more general questions.. not exact syntax of a language.
  • Interviews seem to be trying to figure out if you can learn whatever it happens to be that they need you for at the job.
  • We have to support many languages. So many languages at the same time can get overwhelming.
  • I don’t say I’m an IOS programmer, but I help people write and improve their IOS code all the time.

What was your interview like?

  • Shared projects I made. We just went through my github repo. Tell me about this project, what did you do, what did you use.
  • Was interviewed over Skype
  • Interviewed with 4 people in a marathon. None of those interviews were super technical.
  • The interviews seemed to be gauging whether you would be able to just talk about whatever comes up.
  • They asked me about a lot of command line skills and brought lots of people in from different parts of the company.
  • The interview had me sit down with a program — there’s a bug in this program solve it. What I learned is what matters is the process of how you work on bugs — and being able to communicate that while you’re doing it, not that you actually fix it.
  • Most valued skill is resilience rather than a technical background. You can learn, compensate, fill in gaps. Need willingness to learn, capacity to be frustrated/despair and just move on. People don’t want to hear you freaking out, just want you to do it. Even if it takes you a long time.

Were there classes or resources that prepared you for interviewing?

  • Go out and make something for yourself. Nothing better than finding a thing you want to make, and then making it. Going back to old code, really fulfilling to see progress and wanting to make old code better. You have something to share!
  • Coming to meetings like PyLadies and the Python User Groups. I took some CS classes, but there was lots that I missed. You don’t realize how much you don’t know! Get to meetups to hear about what others are using, what is current in the field. Having a sense of with what the latest stuff is, what are good blogs, best practices, helps out. (seconded by another panelist)
  • Very helpful to go to PyLadies and talk with people around my same experience level. In conversation, people would explain stuff to you in a way that made sense, not just a bunch of jargon.
  • Learning that ecosystem and what tools people use is huge. Helps you figure out what a job entails and what do you need to know to build it.
  • For most of the stuff you’ll build, you’re going to use other libraries. It helps having experience mushing things together. Iterate on it. Every little thing you learn, you’ll find ways of improving stuff.

What if your coding style is really different than other people’s? How do you handle that?

  • Get good at giving constructive feedback
  • “days of spaghetti code is behind us” at the mercy of other people’s crappy code — tech companies deal with this a lot less.
  • Don’t be afraid to say “no idea what this function ” learned a lot about better code by reviewing a lot of code

What kinds of positions can you get? And where do you want to go?

  • Really overwhelming to learn everything I needed to know to support product. It’s an all guys team, learned to love them all, took on a mother role.
  • Teaching stuff all guy team can be intimidating, but most of the guys I work with are college educated CS guys, me having no CS background was intimidating until I realized I knew and could learn this stuff as quickly as they could. No CS didn’t matter.
  • I’m doing tech support, wish I could do more coding. It’s a mixed bag doig support, you learn a lot about system. Found that management wanted everyone to level up in tech support and not go to other parts of the company. I’ve had to come to terms with managers trying to keep me in that role. Need to see how long they expect you to stay in that role before you can move on — ask up front.
  • Had similar experience — resistance to moving from tech support into other roles. Most people in support are looking to move into another role. Make sure you’re on the same page with manager rather than be surprised by it later.
  • On working with guys: my communication style was not really effective when I started. Sometimes had customers that said “can I talk to tech support?” “can I talk to an engineer?”. Had to learn how to be kind of cocky — “This is how this works.” If I was wrong, I was wrong, and had to fix it but that was much more effective at communicating with customers and coworkers.
  • Had to learn that nothing wrong with asking for help. Saves a lot of time.
  • Everything takes me longer than I think it will. Triple your estimates!
  • I needed to learn its ok to ask questions, ask questions confidently rather than despair of never being a programmer. We all tell ourselves crap like: “i’m just generally stupid and can’t learn anything” or “can’t learn javascript in a day, so clearly i’m an idiot”. But turning that around is important for yourself.
  • Be dilligent in the way you ask questions: 1) first google it, stack overflow, check reference book; 2) write out the question fully (rubber ducking) — articulate the problem fully and you might solve it for yourself — what did i expect, what happened, what else can i expect….
  • I’ve had people say to me: “I don’t know why pyladies needs to exist.” I said: “I think its nice its a safe place where that you can articulate your questions without fear.” I don’t know what to do about it other than say that.
  • Men might be made clear to you that they believe we are post-sexist, post-racist. If you have too many of those people around, find a new job.
  • “you need to be careful about where you are” when expressing opinions about feminism.
  • Be open and honest, and they tend to understand.
  • Sometimes it may be the case you have to figure out if an opinion is being expressed because of privilege or malice. If privilege, it can be worked on.
  • Try to internalizing confidence. Tell yourself: “I know how to program” more. Once I really believed that, my programming got better. Because I know I will solve the problem I’m working on!

Do you find that as a woman you communicate differently and you are interpreted differently?

  • Here’s an example: when someone says: “Can you pass the salt?” One person might respond by thinking, “I understand you’re being polite and phrasing that request as a question rather than a command. Sure, here’s the salt!” Or another person might respond with, “I could pass the salt to you. Is that actually what you want me to do?” Pretty different communication styles.
  • Try to be flexible and ride out conflict.
  • I question myself a lot — did i interrupt too many times, was i too aggressive. I worry I am too aggressive.
  • Be yourself. Take time to figure out if you are happy or not.
  • Try to compromise and avoid “truth bombs” where you “explain how the world is”. Take conversations case by case and try not to take it personally.
  • If it gets to be too much, get out of there!

VPN Problems and Ubuntu: killing off the dnsmasq zombie

I’ve been having problems with VPN, DNS and Ubuntu for a year. But, I’m also pretty lazy when it comes to spending time on configuration. And configuring VPNs is like last on my list of ways I’d like to spend my time.

In short, I’d rather reboot than figure out exactly why my networking just stopped working.


Fortunately, I had an easy (for me) work-around for most of my VPN needs: use SSH and a jump-host for getting to servers. I found it annoying when I wanted to look at a website on protected network space, or had a service on an unusual port that I wanted to test things against. I would work around with SSH tunnels, or I would fire up my Mac, whose VPN settings worked flawlessly.

That all said, I thought today, a sunny, lovely fall day in Portland, I would fix my VPN.

And so, my buddy @uberj_ helped me get things sorted.

The root cause of all my VPN heartache was the dnsmasq daemon controlling my DNS. And, related, network-manager. There are a few places that document exactly how to disable dnsmasq

  • DNS in Ubuntu 12.04
  • Disabling dnsmasq as your local DNS server in Ubuntu

However, they leave out one important step: killing off the existing dnsmasq process. For the unlucky, restarting network-manager does not kill off dnsmasq.

So, to find and kill dnsmasq, do the following:

 sudo service network-manager stop
 kill `ps -C dnsmasq -o pid=`
 sudo service network-manager start

Then, start your VPN and check out the contents of the /etc/resolv.conf. If all went well, you’ve got nameserver addresses other than in the file.


Sadly, this was not the end of my story.

After a few minutes, NetworkManager started dnsmasq up again!

Zombie dnsmasq

So, like any reasonable sysadmin, I opened up the /etc/NetworkManager/NetworkManager.conf file, uncommented the dns=dnsmasq line, and replaced it with dns=/dev/null. My guess was that you can probably put just about anything other than dnsmasq into that line to permanently disable the plugin.

I ran sudo service network-manager restart, checked /etc/resolv.conf and felt pretty smug.

I tried also uninstalling dnsmasq-base package, but unfortunately that takes out a number of other packages I appear to need. So, I left /dev/null in my NetworkManager.conf, and updated this blog post.

But wait...

While editing this blog post, dnsmasq took over my DNS settings again.

A clue as to what was happening was in /var/log/syslog:

Oct 18 10:20:10 localhost dnsmasq[30535]: started, version 2.59 cache disabled
Oct 18 10:20:10 localhost dnsmasq[30535]: compile time options: IPv6 GNU-getopt DBus i18n DHCP TFTP conntrack IDN
Oct 18 10:20:10 localhost dnsmasq[30535]: DBus support enabled: connected to system bus
Oct 18 10:20:10 localhost dnsmasq[30535]: warning: no upstream servers configured

It turns out that dnsmasq was still getting revived by NetworkManager. Why NetworkManager doesn’t seem to care about configuration settings was beyond my willingness to investigate today. So, I did some more searching about truly killing of dnsmasq for good.

And I found this thread, and this sample configuration file. In the output for the dnsmasq process from ps:

nobody   30777 30759  0 10:21 ?        00:00:00 /usr/sbin/dnsmasq --no-resolv --keep-in-foreground --no-hosts --bind-interfaces --pid-file=/var/run/sendsigs.omit.d/ --listen-address= --conf-file=/var/run/nm-dns-dnsmasq.conf --cache-size=0 --proxy-dnssec --enable-dbus --conf-dir=/etc/NetworkManager/dnsmasq.d

I dug into the thread, and the suggestion was to set port=0 in the config. I created a file called custom in /etc/NetworkManager/dnsmasq.d. And ran sudo service network-manager restart.

And then I got this in my syslog:

Oct 18 10:21:10 localhost dnsmasq[30777]: started, version 2.59 DNS disabled



An experiment in attention

I’ve had reoccurring thoughts about attention and who I give mine to. In the last week, I’ve been mentioned in a couple “women in tech” twitter lists. This seems to happen about quarterly and someone will create a list of 50 or so, or maybe 100+ women on a list.

I spent a couple days looking through my 5k followers and assembled a list of the women and women’s groups who are following me. I probably missed a few, and I know I followed a few people who don’t consider themselves women. Sorry! Just let me know and I’ll add/drop as needed.

So, why bother with a list like this?

Before I created this list, I was following about 920 people. Which, in itself is a sort of ridiculous number. How could I possibly pay attention to that many people?

I really don’t, right? I just check into twitter, sample the firehose, and then step away for minutes, hours or days.

When I do sample the tweet stream, whose voices do I listen to? There are certainly a few close friends whose feeds I look at directly, and a few other people I’m interested in who I will catch up on a backlog. Otherwise, it’s whoever is the most vocal.

What I noticed is: most of the voices I hear from when I sample the feed are men. It wasn’t anywhere near balanced. That’s on social activity, technical rants, technical praise and blogging.

I’d like to be skewed toward women’s voices for a while. Particularly on tech issues. So, I just added about 450 women to my feed who were already following me.

My next step may be replacing my primary feed with this list I’ve made. I wrote a tool a while back to extract URLs and RSS feeds from my friend’s twitter profiles and feeds. The code isn’t awesome, just rough and practical. But you could do something similar using it. You need a set of read/write API keys (create an app, then make it read/write), but I did the “hard” work for you:

./ --consumer_key [key here] --consumer_secret [secret here] --access_token [token here] --access_token_secret [token secret here]  --to_follow [file of twitter handles]

I left some crud in there that links the script directly to my account for the list. Sorry! If anyone actually wants to use this, I’ll clean it up. (just ping me on github)

Anyway, doing this kind of attention hacking for yourself isn’t hard. It is drudgery to go through all your followers and guess who is what gender. But it is interesting to spend a few hours contemplating what the people you’re giving your attention to have in common, and how you might hack it a bit to hear from different perspectives from time to time.

I’m turning comments off because I don’t care to hear from anyone who thinks I’m somehow being sexist by changing who I pay attention to. Cheer up, haters! I’m sure plenty of people are already paying attention to you.

Speaking at the Cash Music Summit today

I’m headed off to the Cash Music Summit in Portland, OR today.

Here’s the blurb I wrote out for Jesse’s zine:

What’s open source got to do with it?

Free software sounds like a 70s era free-love pipe dream. The idea and a copyright hack to enable it were born in 1984, brought to term by an academic who just wanted to fix a problem he had with his printer.

Free and open source software underpin Cash Music’s platform. Why should that matter to you? Software developers prefer working with code they can freely read, understand and modify. But the benefits to end users are not always as clear.

There’s a method to the madness that is giving away something many believe is worth more if kept secret. It’s not just about sharing, but also accountability, choice and freedom. And, it’s about creating communities we love contributing to, with the kind of people we love to collaborate with.

I’m not sure exactly which story I’m going to tell today – I’ve got 10 minutes though and a pretty sweet picture of Tina Turner.

If you’ve not seen Cash Music or learned about it’s mission, check out this NYTimes article about their work.

What I mean when I talk about collaboration with teachers: part I

I’ve given a few talks about my experience learning to teach. This is an edited version of my speaking notes for the keynote I gave at the Computer Science Teachers Association conference. This is the best distillation of my thoughts about the value of open source in my life, and what motivates me to contribute and teach. The first half is over 2000 words, so I’m breaking this into two posts. The next part I publish will be the second half of the talk – about the classes I’ve taught, and my lessons learned about what people need to know to get started in free and open source software.

I am a beginner teacher. I’ve only just started writing lessons and teaching classes to adult women who are learning or practicing their programming. All of what I share today is based on my personal experiences working with first time, adult programmers. My plan today is to tell you a little bit about me and what motivates me to teach and contribute to open source, share with you the successes of some of our beginner adult programming efforts and finally what I think open source communities offer teachers.

And I want to start by giving away my punchline. When it comes to working with open source community – of which I’m a member and a leader, and there are many, many leaders without any kind of central authority – I can say for sure today that we’ll come to you.

I’ve been working for the past couple years to find like-minded open source community members, and for those of you in the audience today, I am making a commitment to you – if you want it – to find an open source person to come and talk about what it is that they do to your classroom.

Just contact me (you can leave a comment below – just indicate if you’d prefer I not make your comment public), and I will make this happen, either through Mozilla or through my open source collaborators. I’ve spent the last 16 years going to conferences, and I would like to introduce that network of people to you.

I want to start with something Julie Horvath said recently. She wrote a blog post about women in tech and it struck such a chord with me. The first sentence really stopped me dead in my tracks.

I didn’t grow up thinking I could do anything I wanted to.

When I look at this again, I feel overwhelmed by how much it matches what the women I’ve taught said that they think about programming.

Screen Shot 2013-07-25 at 5.31.27 AM

I see this every time I walk into a classroom to teach beginning programmers. This is a photo from a class on algorithms, people doing a pen and pencil exercise in groups. Several women said afterward they finally felt confident that they could explain what algorithms were. That before coming and working on this in these groups, they literally had never really thought about how algorithms related to programming or what it might mean to implement or create their own algorithms.

I’ve come to think of this as a possibilities problem. People truly have no idea what is possible for them in computer science. And in my teaching experience in particular, many women coming to these classes have a very limited view of what they can accomplish. They don’t know what the job opportunities are, they don’t realize how programming can be used in their lives outside of work, and they know very little about how a computer works or what the main components of a computer are.

When I think about what I really need to do — what my focus is in teaching that I do — I think about changing the scope of what people think is possible. Broadening the scope, and enhancing whatever details I can that make studying programming and ultimately computer science relevant to the lives of the people coming to these classes.

So if we were to just to attach a little overdeveloped importance to this idea of expanding the scope of possibility, we could call this “possibility engineering.”

In my experience, there’s two basic things I have to do – I need to raise awareness, and then I need to offer encouragement. It’s in addition, of course, to teaching real skills that people need. And as classroom teachers, you’re all aware of the need for these two things. I’ve found that these issues are often left out of how outreach and teaching in open source communities is structured.

Screen Shot 2013-07-25 at 5.09.46 AM

This is a picture of a sticky note I drew of how I felt while learning to use a new programming language or trying learn a new module in Python. The top of the graph is “euphoria” or “happiness”, and the bottom of the graph is “despair” or unhappiness. You can see I have a lot of ups and downs!

The peaks are when I’m reading documentation for the first time, succeeding with experiments and implementing code. The valleys are when I actually try the tutorials and they don’t completely work, when I write code that fails and when I’m trying to refactor my test suite. In the end, my emotions level out and if I’m lucky, I end up satisfied with the tool I chose to work with.

Screen Shot 2013-07-25 at 5.11.08 AM

Here’s what I think happens sometimes with the women who come to PyLadies and then never come back. They initially are very happy, but then something happens that causes them to give up.

Screen Shot 2013-07-25 at 5.11.51 AM

In one case, I know exactly what happened — a woman attended the workshops, tried things on their own that didn’t work, and then finally had something break with Python on her Windows laptop and she never came back.

What happens when PyLadies succeeds? What does the emotional graph look like?

Screen Shot 2013-07-25 at 5.12.49 AM

What I’ve seen in the 60+ women that keep coming to meetings is that they continue to have difficult experiences – things break, they don’t know how to fix them.

But they all come back to the group. They ask questions, they commiserate over things that don’t work and they get the help they need to see that they are improving at the same time as they feel as though they are getting better, making friends and being supported. The in-person experiences are key.

Screen Shot 2013-07-25 at 5.13.48 AM

Before we go on, it’s important to acknowledge a key truth about what it is that teachers are teaching. Computer Science is a way of thinking and solving problems. It’s not a company or a product.

This is of course obvious to all of you in this room – but it’s such an important idea to come back to to in all of our work. It’s about getting kids or adults to understand the basics of what a computer is and what it does, and how it stores data about what, where, how and when we do things. We need people to understand these concepts in the same way that we need people to be able to read. When our society is increasingly assisted, augmented and controlled with the help of computers, democracy is at stake when most people have no idea how a computer and software works.

The role of open source groups like PyLadies, of non-profits like Mozilla, is ultimately to empower people: to spread knowledge, dispel myths and invite exploration.

But these groups are mostly helping out people who are already out of high school.

There’s a fair amount of research at this point about what many people think about computers when they’re in high school. I’ve mostly read about what girls think, and try to keep that in mind when I’m advertising my courses. Which brings me to what I thought computer science was all about when I was in high school.

What I knew was:

  • Computers were for playing games
  • Computers were for anti-social boys
  • You’ll find lots of inappropriate, animated ASCII art on computers

And I think that highlights a problem with how we’re collectively handling explaining computer science to the world. We can’t rely on ad-hoc self-education, or discovery learning to help people understand how the whole world is changing.

Screen Shot 2013-07-25 at 5.16.37 AM

Here’s a list of job titles from my colleagues in the industry. Many of these are jobs that didn’t exist 20 years ago, some are jobs that didn’t exist five years ago. So much is changing so fast.

Despite that, we have some real principles – computer science principles – underpinning it all. That’s where we need to focus, while at the same time exposing people to this wealth of possibility.

So, how did I, a person who thought the computers were for gaming, for boys and probably a little bit seedy, get from there to thinking it might be possible to join an open source community and move on to actually changing something I cared about?

In 2000, I made my first contribution to an open source project. I was working at Intel, managing network equipment monitoring and I’d found a problem with how I’d set everything up and needed to modify something like 7000 files to fix it. So I wrote a simple script.

Not too long after that, someone else had a similar problem and posted about it to a mailing list. So I decided, I might as well help that guy out and post the script. Then, I did.

And what happened next totally changed my life. The maintainer of the project not only thanked me, and asked a bunch of questions, he accepted my patch committed it to the main repo, and added me as a contributor to the project’s site.

Mind Blown

I changed the source code of a tool I used every day.

I felt deliciously powerful, so important! And incredulous that something that I’d written that was so obviously terrible, was good enough to be part of a piece of software that I not only used every day, but thought was incredibly great.

And other people used it! I know because I got bug reports later.

Today, I’m a major contributor to the PostgreSQL community, and I founded a chapter of PyLadies in Portland. I’m also deeply involved in many aspects of open source community organizing, like running conferences and helping out with the Ada Initiative. It’s hard to understate how much that patch affected the rest of my life.

I’m super passionate about open source software and I really think collaborating with teachers is awesome. And what I think in particular is great about collaboration between us is getting the open source community to understand teaching at scale. By that, I mean learning how to teach everyone — the way that we teach in our public education system.

Public education is a grand experiment, and a very successful one. Despite the many issues we have with the administration of it, we have a literacy rate that enables us to sustain a democracy and a system for getting an incredible amount of information to most of our republic’s citizens.

We should be using this system to teach everyone about computer science.

Beyond that, I want open source communities to figure out how to teach at that kind of scale. Not only do we need computer science in the classrooms — we need free and open source principles and tools to be taught as well.

We can get there with community members reaching out to teachers as a first step.

And an important part of that is learning what the process of developing lessons and teaching students in classrooms is all about. This is the huge thing we (free and open source developers and community members) can learn from you (teachers).

Teachers and open source community have a lot in common. Some of the more important things are:

  • Minimal resources
  • Teach anyone who shows up
  • Change the world by sharing ideas

My dream in this is that we’ll find a way to provide effective computer science education for everyone.

We’re trying to find that minimal set of concepts that will make people feel empowered at a keyboard, a kiosk or any computer they interact with in their lives. That they understand what’s being said in the newspaper about computers, that they can ask questions without feeling shamed or stupid, and that they can learn more if they choose.

And I don’t mean at all to say that you’re all signing up for teaching everyone. But I am signing up to at least try to do this for the adults in my life that need and want it.

Second half of this talk coming shortly…

What Open Source developers can do for teachers: volunteer to speak in a classroom

I keynoted the Computer Science Teacher’s Association annual conference on July 16th. I gave a talk about how open source developers can help teachers, and what I’ve learned about teaching programming to beginners. The slides are available, although not completely informative about what I said. I plan to write up what I said in that talk after OSCON is finished. Here’s part 1 of the talk.

My pitch to the teachers was: send me an email, and I will find a free and open source community member to give a 15-20 minute talk in your classroom. Lots of teachers are taking me up on it.

To get this done, I set up a form for FOSS community members to provide their contact information. I’ve gotten 163 people as of 8:20am PT July 24. Thanks so much everyone! I know quite a few of the people who have filled out the form, and there are a ton of new people as well. I’m incredibly excited about this. We can all do a lot of good by actually meeting the teachers in our local areas!

Anyone is welcome to sign up, in any location. We have gotten volunteers from every continent except Africa so far.

Most of my teacher contacts are in the US, and I know a few teachers in Germany. If you know teachers who’d like speakers, I’d love to hear from you as well.

I’ve also started a conversation with a few developers about creating an app for connecting teachers and FOSS community members. We’ve got some code in a repo, and a couple people interested in an API for use in some neat remixing applications.

If you’ve got some Django or front-end experience, and you’d like to donate a little time, we’d be happy to have you join us in developing a tool for managing the contact process. I really want the introductions between people to continue to be a “warm handoff”, but it would be nice to remove me as a single-point-of-failure.

I’m setting up a meeting next week. Just ping me either on this post or via email.

AdaCamp Day 2: Welcoming hackerspaces, Being Feminine in Tech and messing around with IR LEDs

This is a recap of my second day at AdaCamp. My second post in this series was about day 1.

Diversity beyond gender

My first session of the day was about creating welcoming spaces that encourage all kinds of diversity, rather than only focusing on gender. Those present were very interested in physical space issues involving hacker/maker spaces or running events. We discussed a set of practices that have worked in several spaces:

  • Let the people involved set the agenda and define the uses of a space.
  • Create an environment where a person of color is not the only person of color when they walk in.
  • Describe a space as a “makerspace” rather than a “hackerspace”.
  • Make events invite-only to establish a welcoming culture.
  • Don’t say “please come if you are a woman”. This is tokenizing language that discourages participation.
  • Invite everyone to organize events, not just attend events.
  • Invite people to events through existing, established groups.
  • Spend time thinking about who and what is missing from a group or space and take action to fix or change.

Patterns of exclusion start long before we deal with them in technology culture.

Being feminine in tech

This was a very large group, so we attempted to focus discussion on some key issues. I was also reminded of “grunch“, the feeling you get when you’ve suddenly been reminded that you’ve got a feminine body.

Our initial set of discussion topics were:

  • Masculinity valued over femininity — how do we get to express a masculine identity in an authentic way and not devalue femininity? Are we expressing masculinity because it’s who we are or because we perceive it as having more value?
  • How “woman” can I be? do I have to switch to their language? what rules do I have follow?
  • How do I make suggestions for a more gender neutral culture in the workplace?
  • Peer shaming if you represent as highly feminine or androgynous
  • Reacting to the hyper masculine by occupying a more feminine place despite its authenticity

Participants shared a series of stories about their experiences expressing feminine or masculine dress, haircut, physical attributes. Most of the descriptions were posed as experiments — “I spent a month wearing dresses to normalize femininity in my workplace and here’s what happened.” The experiments women are running on themselves and their coworkers to try to get people used to women in the workplace are fascinating and shocking. Reflecting on the discussion, I felt like we were back in pre-women’s suffrage, where men were shocked at women working or wanting equal rights.

I also realized that I think about issues with what I wear a lot, but rarely talk about it with my colleagues.

I learned about differentiating between a few different concepts when talking about expressing femininity:

  • Gender policing: comments designed to inform someone that they’re violating an accepted norm. Examples include being described as “dressing too slutty”, aggressive attention when a woman has a shaved head and looks masculine or androgynous.
  • Masculine assimilation: dressing more masculine to avoid unwanted attention
  • Feminine presentation seen as inviting sexual attention: several people described a dramatic change in behavior among colleagues or students when women wore traditionally feminine clothing (skirts, dresses, blouses)
  • Peer shaming: in this context, we discussed concerns with women who shame other women over appearing/acting too feminine, or using feminine symbols like the color pink.

There was a lot more to this conversation. Looking back over the notes, I am a bit overwhelmed at how much ground we covered among so many people in just an hour. This session also led to some other hallway track conversations where I learned a bit more about how individuals are trying to balance their activism with their personal relationships with other women in open source/hardware/culture communities.

Hardware hacking!

I spent some time with the hardware hackers. Several women brought soft circuits, and one person brought a soldering station so that people could try out soldering for the first time. I was trying to get some IR LEDs integrated into a headband, and we had some issues with the shape and the stretchiness of our material. Other folks at the table were making blinking fuzzy muppet/monsters for their badges. Lots of very adorable blinky things were assembled.

I did demonstrate how to troubleshoot LEDs and what IR light looks like on digital cameras. I talked a bit more about medical devices with someone looking into how to hack her own augmentations. It felt a little like a “from the future” conversation. :)

Mozilla contributor dinner

I spent Sunday evening having dinner with some Mozilla contributors from France and a couple coworkers. I was probably the only person at the table who spoke only English, reminding me that I really aught to keep up on my language lessons. 😀

I caught my buddy Diane up on what had happened at AdaCamp, met Delphine’s husband and tried to convince some contributors to lead an effort to have an AdaCamp in Europe!

By the end of the evening, I was ready to collapse and get back to Portland!

Summing up

My last post about AdaCamp will be reflecting on all three of the camps – starting in Melbourne, Australia, then Washington, DC and finally in San Francisco. The event has grown from about 40 people to 200+, and for me, is the most exciting gathering of women in open source, open hardware and open culture. I’ve never been around so many women who share the same values, who are fighting for openness in technology and who are focused on tearing down the many barriers we face to involving more women in our technical communities.

AdaCamp day 1: Allies workshop, OPW, The likeability paradox and depression/activism

This is a recap of my first day at AdaCamp SF. My first post in this series was about the opening reception.

Allies Workshop

I started the day with the 2 hour Allies workshop. Valerie Aurora led this session, with the intention to train a number of new people on how to give the workshop. I took a ton of notes, so here goes, without much editing:

The presentation starts with 15 minutes of introductory slides, which are Creative Commons licensed. We answer the question “why is men fighting sexism important?” There’s a visualization at the start of the number of women involved in FOSS (not many – 2%) and Wikipedia (slightly more, but still not many). We got sidetracked on a slide that had a bit of jargon on it – introducing the idea that we don’t have a gender binary, but for the purposes of the discussion today, “man” will mean “cis white male”, as that’s typically who will be participating in the allies workshop.

I failed to take notes on this (probably because I was intensely paying attention!).. There was a part about the purpose of speaking up. When you decide to speak up about sexism, you’re often not doing so to educate someone who has made a mistake, or is being a jerk. You’re helping a group set a boundary and showing everyone listening in what is ok and not ok. Super important point for me!

There’s a reminder to not be scared of the discussions about to happen. They will be uncomfortable possibly awkward, and that’s ok. When men speak out about sexism they do not get the same responses that women do. They are often publicly supported and privately criticized — the opposite of what happens to many women. The workshops will be a 7-minute discussions, followed by summaries and reflections to the group. These discussions are the times to ask questions, even seemingly foolish questions. Val asks that everyone respond authentically (my word, not hers) when questions are asked. This is a safe place for Allies to find the answers to difficult problems.

Then we went into some example scenarios. We did three scenarios that were prebaked and then one that a participant brought up. I’ll save my notes on these discussions for another time. I really enjoyed the time I spent on this, and learned quite a bit from my group.

The Likeability Paradox

In the book Lean In, there’s a section about the difficulty of being liked vs being respected when you are a woman leader. This discussion was by far the best large-group of the day for me, and extremely well-moderated. I wrote down lots of phrases: bossy, “risk theater”, damning with faint praise, competition between women == disdain, acceptable level of emotional discourse, the difference between “earning respect” and “earning like”, likeabliity == emotional catering, gendered insecurity about a woman’s place, the amount of time it takes to earn respect vs first impression likeability, orgs maximize stability by ignoring these kinds of problems.

There was the start of a great discussion about dog whistle adjectives, adverbs and verbs that subtly and not-so-subtly remind women of their role and place. Are there words we can choose to describe “aggressive” behavior, for example, that are less gendered and more fair to both men and women? Example was asking an employee to “be more aggressive”, when what the manager really meant was they wanted more “decisiveness”. Another person said they started using “inspire” instead of “convince” in their activist work.

There was a short discussion asking “what is respectibility” and how do we unpack that term. This brought up some experiences people have had with being questioned consistently about their qualifications — “the veracity of contribution is questioned” and “what has ‘this woman’ ever done for this community?” Another comment was that by speaking less as a manager, and “planting seeds that employees then run with and come to the same conclusion” a woman had found it much easier to get her employees to do what she wanted. There was quite a bit of discussion about how problematic recommending “speak less” is, even if it is an effective tactic. Upon reflection, I think what was problematic was the framing, rather than the management tactic. Men who are managers clearly use this tactic as well, and it is effective.

Later, Sumana tweeted a link to this piece in Politico about Jill Abramson.

Depression and activism

I mostly came to this session for tips from those in attendance. Here’s what I wrote down:

  • Ask for a big chunk of time off to recharge
  • Structure time for fun
  • Only work when you really want to — give yourself permission to relax when you feel like crap!
  • Consider flipping your “alarm” system to management – start talking about how busy you are when you’re at 70% capacity, rather than 150%!
  • Be selfish with your time and energy

Internal strategies:

  • Try cognitive behavioral therapy (there are great books: Mind over mood, Panic attack)
  • Flip negative self talk, going even so far as to rewrite personal stories in the best possible light

IBM had suicide prevention training for new folks working on-call. A hacker training school has a weekly 2-minute “talk about your life” time.