Systems Thinking about WIT

Systems (and by “systems” I mean “everything”) can be modeled as stocks and flows.[1] Stocks are quantities that accumulate (or disappear) over time, like money in a bank account or code in your repository. They may not be physical, but they are observable in some sense. Flows are how the stock is filled, and how it empties. Flows have valves representing the variable rates of ingress and outgress.

salary flows into the stock of money; spending flows out

Stocks don’t change directly; they grow or shrink over time according to the rates of flow. If your salary grows while spending stays constant, money accumulates in your account. Flows are affected by changes to the rules of the system, and sometimes by the levels in each stock. The more money in your bank account, the faster you spend it, perhaps. When a flow affects a stock and that stock affects the flow, a feedback loop happens, and then things get interesting. If the more money in your bank account, the more you invest, and then the more money in your bank account… $$$$$!

salary and investment income flow into the account; spending flows out. An arrow indicates that the amount in the account affects the investment flow rate.

This is a reinforcing feedback loop, marked with an R. It leads to accelerating growth, or accelerating decline.

Enough about money, let’s talk about Women[2] in IT. We can model this. The stock is all the women programmers working today. They come in through a pipeline, and leave by retiring.[3]

the pipeline inputs women into IT; they flow out through retirement.

People also leave programming because there is some other, compelling thing for them to do. This includes raising a family, writing a novel, etc. I’ll call this the “Something else” flow. It should be about the same rate as in other lines of work.
Then there are women who drain out of IT because they feel drained. They’re tired of being the only woman on the team, tired of harassment or exclusion, tired of being passed over for promotion. Threatened until they flee their homes, in some cases. Exhausted from years of microaggressions, in more. I’ll call it the “F___ This” outflow.

The pipeline inputs to the stock of Women in IT; three outflows are Something Else; retirement; and F This.

There are feedback loops in this system. The more women in IT, the more young women see themselves as possible programmers, the more enter the pipeline. Therefore, the flow of the input pipeline depends on the level of the stock. This is a reinforcing feedback loop: the more already in, the more come in. The fewer already in, the fewer enter.

same picture as before, but an arrow indicates that the quantity of women in IT affects the rate of flow through the pipeline. Marked with R.

The quantity of women programmers also affects the experience for each of us. At any given conference or company, a few assholes are mean, and those microaggressions or harassments hit the women present. The fewer women, the more bullshit each of us gets. Also the less support we have when we complain. This is also a reinforcing feedback loop: the lower the number of women in IT, the more will say “F___ This” and leave.[4] If there are ever as many women programmers as men, that outflow might be the same as in other fields. Until then, the outflow gets bigger as the stock gets lower.

same picture, with additional arrow indicating that the quantity of women in IT affects the rate of the F This outflow. Marked with R.

One of my friends pointed at the pipeline and said, “It’s not hopeless, because women are a renewable resource.” He hopes we can overwhelm the outflows with a constant influx of entry-level developers. In Thinking in Systems[1], Meadows remarks that people have a tendency to focus on inflows when they want to change a system. Sure enough, there’s a lot of focus these days, a lot of money and effort, toward growing the input pipeline. Teach young girls programming. Add new input pipelines: women-only bootcamps, or programming for moms. These are useful efforts. Yet as Meadows points out, the outflows have just as much effect on the stock.

Can we plug the holes in this bathtub? Everyone in IT affects the environment in IT. We can all help close the “F___ This” outflow. See Kat Hagan’s list of ways we can each make this environment less sexist.  Maybe in a generation it’ll get better?

This isn’t new information. Let’s add granularity to the system, and see what we learn. Divide the stock into two stocks: junior and senior women developers. The pipeline can only provide junior developers. Experience takes them to senior level, and finally retirement. Junior people are likely to find other careers, while senior people have been here long enough we’re probably staying so I won’t draw that as an outflow. The “F___ This” outflow definitely exists for both.

pipeline flows into a stock of Junior women. Outflows of Something Else and F This lead nowhere, while an outflow called Experience leads to a stock of Senior Women. Outflows from here are retirement and F This.

Consider now the effects of the two stocks on the flows. The senior developers are most impactful on all of them – on the pipeline as teachers, on “F___ This” as influencers in the organization, and even on the “Something else” outflow as role models! The more women architects and conference speakers and book authors and bloggers a junior dev sees, the more she sees a future for herself in this career. Finally, the stock of senior women impacts the rate at which younger women move into senior roles, through mentorship and by impacting expectations in the organization and community.

Same picture, with the addition of arrows indicating the affect of quantity of Senior Women on the input pipeline, the Something Else outflow, and both F This outflows. Also, arrows indicate an effect of quantity of junior women on input pipeline and their own F This outflow.

To sustainably change the stocks in a system, work with the feedback loops. In this case, the senior developer stock impacts flows the most. To get faster results that outlast the flows of money into women-only bootcamps, it’s senior developers we need the most. And the senior-er the better. Zoom in on this box, and some suggestions emerge.

An Experience flow brings in Senior Women in IT; they flow out through retirement and through F This.

Inflows 

1. Mentor women developers. Don’t make her wait for another woman to do it; she may wait forever, or leave first. Overcome the awkward.
2. Consider minorities carefully for promotion. A woman is rarely the obvious choice for architect or tech lead, so use conscious thought to overcome cognitive bias.

Outflows

1. Encourage senior women to stay past minimum retirement age. Our society doesn’t value older women as much as older men. Can we defy that in our community?
2. Don’t tolerate people who are mean, especially to women who are visibly senior in the community. See Cate Huston’s post: don’t be a bystander to cruelty or sexism. And above all, when a woman tells you something happened, believe her.[5] For every one who speaks up, n silently walked away.

Magnify the impact

1. Look for women to speak at your conference. Ask early, pay their travel, do what it takes to help us help the community.
2. Retweet women, repost blogs, amplify. I want every woman in development to know that this is a career she can enjoy forever.

Stocks don’t change instantaneously. Flows can. It takes time for culture to improve, and time for that improvement to show up in the numbers. With reinforcing feedback loops like this, waiting won’t fix anything – until we change the flows. Then time will be on our side.

Finally, please don’t take a handful of counterexamples as proof that the existing system is fine. Yes, we all respect Grace Hopper. Yes, there are a few of us with unusual personalities who aren’t affected by the obstacles most encounter. Your bank account is in the black with just a few pennies, but that won’t make you rich.


[1] Thinking in Systems, by Donella Meadows. On Amazon or maybe in pdf
[2] Honestly women have it easier than a lot of other minorities, but I can only speak from any experience about women. Please steal these ideas if you can use them.
[3] There’s a small flow into Women in IT from the stock of Men in IT, which is awesome and welcome and you are fantastic.
[4] Cate Huston talked about “how dismal the numbers were, and how the numbers were bad because the experience was bad, and how the numbers wouldn’t change unless the experience changed” in her post on Corporate Feminism.
[5] Anita Sarkeesian on “the most radical thing you can do to help: actually believe women when they talk about their experiences.

Accidental vs Deliberate Context

In all decisions, we bring our context with us. Layers of context, from what we read about that morning to who our heroes were growing up. We don’t realize how much context we assume in our communications, and in our code.

One time I taught someone how to make the Baby Vampire face. It involves poking out both corners of my lower lip, so they stick up like poky gums. Very silly. To my surprise, the person couldn’t do it. They could only poke one side of the lower lip out at a time.

Turns out, few outside my family can make this face. My mom can do it, my sister can do it, my daughters can do it – so it came as a complete surprise to me when someone couldn’t. There is a lip-flexibility that’s part of my context, always has been, and I didn’t even realize it.

Another time, I worked with a bunch of biologists. Molecular biology is harder than any business domain I’ve encountered. The biologists talked fluently amongst themselves about phylogenies and BLAST and PTAM and heterology and I’m making this up now. They shared all this context, and it startled them when developers were dumbfounded by the quantity of it.

Shared context is fantastic for communication. The biologists spoke amongst themselves at a higher level than with others. Unshared context, when I don’t realize I’m drawing on a piece others don’t share, is a disaster for communication. On the other hand, if I can draw on context that others don’t have, and I can explain it, then I add a source of information and naming to the team.

In teams, it’s tempting to form shared context around coincidental similarities. The shows we watched growing up, the movies we like, the beer we drink. The culture we all grew up in, the culture we are now immersed in. It gives us a feeling of belonging and connection, shared metaphors to communicate in. It’s much easier than communicating with someone from a different culture. There, we have no idea how many assumptions we’re making, how much unshared context there is.

Building a team around incidental shared context is cheating. It keeps all the worst of context: the assumptions we don’t know we’re making. It deprives us of the best of unshared context: the stock of models and ideas and values that one person alone can’t hold.

Instead, build a deliberate shared context. Like the biologists have: a context around the business domain, the programming language we use, the coding styles and conventions that make the work flow, that make the code comprehensible. Team culture is important; we should understand each others’ code through a shared context that’s created deliberately.

Eschew incidental shared context by aiming for a diverse team. Create consciously a context that’s conducive to the work.

Why Aren’t There More Women Programmers

When we feel like we’re good at something, that’s when we can really learn it, sink our teeth in and love it and do it until we’re experts.

It is a great motivator, this feeling of confidence. This belief that we can accomplish what we want to do is called self-efficacy. There are four sources of self-efficacy at a particular task (in order of strength):[1]

  1. doing it
  2. seeing people like me do it
  3. social persuasion
  4. your body

Why aren’t there more women programmers? Because many women don’t feel like they can do it. Therefore they don’t try it, or don’t persevere. These sources of self-efficacy explain why women (in aggregate) are less likely to program than men.

1. doing it: If you try something and have success, this is the best source of a feeling of self-efficacy. In my generation, more boys than girls started programming at an early age.

2. seeing people like me do it: If my mom can do it, so can I.
People choose careers by picturing themselves in that job, and the picture is based on people we know. If we can’t picture ourselves in a career, we don’t consider it. The gender dichotomy is strong in our culture, a big part of whom we consider “like me.” A boy can picture himself as a programmer. When a girl looks around, she doesn’t see people like her coding, attending conferences, speaking, blogging, contributing to open source. Even women developers: looking up in the hierarchy, they see themselves in management, analysis, QA, BI, maybe DBA. Not system administration. Not architecture.

3. social persuasion: Do my friends approve of it?
Here, we look not at the culture of programming, but the culture of women. When I go to Kindergarten Moms Night and someone asks what I do, “computer programming” usually ends the conversation. I don’t fit in. Growing up and being grown up, if you enjoy the company of other women, the social persuasion is against development.

4. your body: Do you get a good feeling in your stomach? I don’t know about this one. Is it different for men and women?

Women are just as capable of programming as men, but (in aggregate) they don’t feel as capable. If we can change that, then we can change the ratio.

#1 is the most direct route, and many in the community are working on introducing programming to young people, especially young women. Yay for them!

#2 is something else we can change. Increase the visibility of women who are already developers, especially those at the highest level. I want to look up, up on stage or up the decisionmaking structure, and see people like me. Conference organizers who go out of your way to elicit proposals from women, thank you. You’re helping.

#3 comes the larger social culture, not the culture of programmers. I can’t be a typical mom and a community-involved developer. This is not something the programming community can change. Personally, I see #3 as the most intractable obstacle for women.

As a community, #1 and #2 are the ones we can do something about. And hey, they’re at the top of the list! If we keep working at this, we’ll reach s critical mass. Once programming is (say) 33% women, then #3 will fix itself. Without intervention, the social pressure and lack of role models combine to attract and retain fewer and fewer women. With work, we can turn that spiral around.

————————–

[1] At PyCon Canada, Mel Chua gave a great talk on learning. This list is hers.

Welcome All the People

On our team, in the user group, and at conferences, we try to build community. In each conversation, we do this by emphasizing ways we are alike.

  •  Who doesn’t like beer?
  •  Monty Python is funny.
  •  Everyone has done Object Oriented programming.
  •  We all went to college.
  •  Each of us can grow a beard.
  •  Video games are awesome.
  •  Everyone can see and hear.
  •  We all grew up watching Saturday morning cartoons.

Each of these shared references draws together most of the developer audience and promotes a feeling of belonging. And each of them further isolates people who don’t fit these assumptions.

I’ve been guilty of this. Writing presentations or posts, I look for domains familiar to my audience, and choose role playing. This emphasizes the programmer == geek stereotype, and the people who don’t know what it means to “level up” feel stupid and out of place.

When a reference appeals to the majority then people who don’t get it feel isolated. No one asks, “What does that mean?” when 80% of the audience reacts with knowing laughter.

Let’s build community on what every one of us shares.

  • We want to learn from each other. 
  • Each of us wants to help build better software.

If you don’t want to learn or build good software then don’t read this blog. From now on, I aim to make only these assumptions about the people on my team, in my user groups, and at each conference.

Dick jokes? Funny, yes. Offensive, no. It isn’t about offensive/not offensive anymore. It’s about welcoming/isolating. When a particular joke applies to 80% of the audience differently than to the other 20%, that joke is isolating. That builds homogeneity. I want everyone to feel welcome, I want diverse ideas and contributions. I’m aiming for inclusion.

These are my action items:

  • Consider my target audience as the attendee mix I hope to see someday. Men and women and transgendered, Asian and African and European, 20s and 40s and 60s. People who like sports, and cooking, and quilting.
  • Give context to my references. The next time I mention the Prime Directive of Programming, I’ll talk about how Captain Picard in Star Trek: The Next Generation follows the Prime Directive of “do no harm.”
  • Have hallway and table conversations about a diverse range of topics, that any random person might be able to jump in on. I’ll keep the stuff that freaks some people out for parties and private.

Let’s make each other think. Development communities should be about learning, not warm fuzzies of all being alike, when “all” means “people who resemble me.” I want to be all in, and let all in.

Geeks, Freaks, Nerds, & Programmers

This post is about diversity. But not about gender — gender is a symptom of the larger problem, and I am a part of that problem.

First, something about brains: In our brains, everything that goes in, what we see and hear and read, forms a pattern in our neural connections. Later, when we see something similar, those same neurons are activated and we recognize the situation. It is like Content Addressable Storage, except that it doesn’t need an exact match; close is good enough. Storage and retrieval with pattern matching thrown in for free — it’s memory and processing at the same time![1]

As a consequence of this, two brains with different patterns produce different output for the same input. Patterns come from experiences, so no two brains are the same. Two people presented with the same problem will ask different questions, try different solutions, come up with different names for concepts. [2] Experience changes not just what we think, but how we think. The more different the experiences, the more variety in ideas.

Consider geeks like me. The typical geek grew up watching Star Wars, Star Trek, and Monty Python. We played D&D. We read books about our future in space. We were unpopular in high school, but now we have our own subculture where we fit in. Lots of us now work as programmers.

Bonus for us: at work we’re all a bunch of geeks, so we have all this shared experience. This lets us communicate efficiently, because we can speak in XKCD references and Lord of the Rings analogies. But what is that costing us?

In design meetings or pair programming, we look at a problem and separately we all come up with the same idea. We say, “Yeah! We must be right, because we all agree!” But are we missing out?

The more shared experiences, the more similar patterns, the more uniform our ideas. We don’t even know what might occur to someone with completely different references. Someone who loves history and gardening, or someone raised in a different religion. Likely there are a few people like that on our team, but they don’t speak up much. They’re in the minority, always voted down. They get quiet after a while.

This camaraderie we enjoy, this snuggly monoculture, it’s costing us ideas.

More about brains. When presented with a hard question, such as “Will this candidate be a good programmer on our team?” our brain does some magic. Without consulting us, it substitutes an easier question: “Does this candidate resemble other good programmers I know?” and then also without asking us, it answers this question with easily obtained data, such as “Does he look like the other programmers I know? Does she laugh at the same jokes? drink the same beer? Does he have a beard?”
This is how our gut makes decisions. [3]

Some managers call this “hiring for cultural fit.” Is this the culture we want?

Teams are built on shared values. It’s easy to get lazy and base our shared values on the Force, “that’s what she said,” and good beer. This takes away from values like solid code, abstract thinking, or responsive UIs. Team members who don’t fit in can pull the team’s focus toward the stuff that matters.

Bruce Watson, manager of Atomic Object’s office in Detroit, has seen this many times.

“Change the gender mix and behavior immediately changes to a greater focus on work, different perspectives are introduced, and side trips are more social than derogatory.
This effect is not exclusive to women joining all male teams. I have seen behavior change when men join an all women’s group or when races, beliefs, and orientations mix.”

Monoculture limits ideas and distracts from values that matter. Let’s take the “cult” out of culture.

How? Apply a design principle: separation of concerns. Separate being a geek from being a programmer.

Geek is a subculture, but programming is a profession. Right now the terms are used interchangeably in many circles. Geeks are mostly white and male, and this is fine. Programmers are mostly white and male, and this is a detriment to our industry. We’re missing out on other brain patterns, and we’re not optimizing for teamwork.

The problem is: programmer == geek. Nerd, to those outside our circle. Gender is a symptom, and racial uniformity is a symptom. The US is 50% male, and developers are 90% male. The US has 30% black and Hispanic people, and development has … hardly any. Gender and race we can measure, so they are the metrics for general diversity. Count the women, count the skin colors, count the ideas your team has access to. The real goal is diversity of minds.

A child growing up as a girl, or a black person or Latino, why would they picture themselves as a programmer? They’re not a geek.

I’m a woman, but I make fun of team members who don’t read the right webcomics, and I wear this “geekette” shirt to present at user groups and conferences, and I make penis jokes. I’m part of the problem.

What can we do about it?
Three suggestions.

  1. Seek out the team members you’re least comfortable with. Ask them design questions. Draw them out if necessary, because they may not be used to it.
  2. None of us, even those who identify as geeks, are defined by this label. Share the parts of us that don’t fit the stereotype. At work, at user groups and conferences, talk about topics that are unique or important to you. Talk about books the others probably haven’t read. Politics, even. Not your kids — that’s too safe. Tell the stories that changed your outlook on life. Surprise each other.
  3. One way to get new patterns for our team is to get new patterns in our own brains. Go do something you can’t picture yourself doing. Dance, climb, speak an obscure language. Run for office. Join a band. Be the diversity we seek. Listen to a kind of music you’ve never liked. Go past where it feels good, and you might find where it feels wonderful.

We are more than geeks. Our industry is about more than geekdom. Programming is about creating, thinking, abstracting. Let’s make programming for everybody.


“As a leader, I know that the more mixed the group, the easier it is to get a stronger focus on teamwork. The stronger the teamwork, the better the software, and the better the software the greater the sense of contribution among all team members.” — Bruce Watson


[1] For more info, look up Sparse distributed memory.
[2] “Different men confronting the same range of phenomena… describe and interpret them in different ways.” “The particular conclusions he does arrive at are probably determined by his prior experience in other fields, by the accidents of his investigation, and by his own individual makeup…. An apparently arbitrary element, compounded of personal and historical accident, is always is always a formative ingredient of the beliefs espoused by a given scientific community at a given time.” — Thomas Kuhn, Structure of Scientific Revolutions
[3] Substitution heuristic and representativeness heuristic. Daniel Kahneman, Thinking Fast & Slow

The invisible hand that isn’t there

Amber nails it, but not in the way you might think.

Where are these opportunities? You don’t see the opportunities that no one offers you. You don’t see the suggestions, requests for collaboration, invitations to the user group, that didn’t happen.

Where are these obstacles? Also invisible. They’re a lack of inclusion, and of a single role model. They’re not having your opinion asked for technical decisions. They’re an absence of sponsorship — of people who say in management meetings “Jason would make a great architect.” Jason doesn’t even know someone’s speaking up for him, so how could Rokshana know she’s missing this?

You can’t see what isn’t there. You can’t fight for what you can’t see.

In the post that triggered Amber’s tweet, Tom describes the subtle, behind-the-scenes influences that make a career. Success is built on a hundred fortuitous circumstances. Lack of success is a thousand paper cuts. And since it’s always been this way, why would a sliced-up person even notice? It feels normal. Like a child with poor vision, they don’t even know anything is wrong until someone takes a broader perspective, makes a comparison.

How can we make this comparison? At the aggregate. You don’t have to look far to know that at the aggregate, women and minorities are strangely missing. Women who are here are leaving.

This isn’t overt discrimination, it isn’t intentional, it’s simply how our pattern-forming brains work. When people like me think about technologists, the image that comes to mind has pale skin and grows a moustache in November. People aren’t trying to exclude anyone, we’re just human. If you disagree, read some numbers.

Tom gets it wrong when he realizes there are “certain opportunities I get that women have to fight much harder for.” There’s no fighting, you can’t fight for opportunities you don’t see. Instead, there is waiting. Wait forever, wait until they’re tired of feeling out of place. Until some other career offers them the encouragement they don’t realize they’re missing.

It’s vague because no one can see what isn’t there – until we back up and observe the indirect effects.

The invisible hand isn’t pushing up down – it’s pulling others up. Let’s work on pulling everyone up.

So how must we be vigilant? I’ll tell you.

  1. Create explicit opportunities to make up for the implicit ones minorities aren’t getting. Invite women to speak, create minority-specific scholarships, make extra effort to reach out to underrepresented people.
  2. Make conscious effort to think about including everyone on the team in decisions. Don’t always go with your gut for whom to invite to the table.
  3. Don’t interrupt a woman in a meeting. (I catch myself doing this, now that I know it’s a problem.) Listen, and ask questions.
  4. If you are a woman, be the first woman in the room. We are the start of making others feel like they belong.

The good news: once there are several women on every team, in every conference session, in every user group, then the bias will naturally shift. Same for other minorities. The bad news: it takes a generation. So be patient, and be encouraging. Encourage people to enter the field, to stay in it, and especially to lead. Sometimes all it takes is a suggestion.

The chicken and the egg both come first

Yesterday at the Java User Group, I talked to someone with a recent Ph.D. in Computer Science who can’t get a programming job. Why? He doesn’t have experience. Everyone wants to hire a Java programmer with Spring and Hibernate to program in Java using Spring and Hibernate. To get experience, you need to have experience. This same chicken-or-the-egg problem shows up all over the job market.

Me, I’m lucky: I graduated in 1999 when everyone was hiring entry-level programmers. You could graduate with an English degree and get a programming job in 1999. [1]

The real way to get a good job is through word of mouth. The best jobs don’t go through the recruiters who are screening everyone for experience in Spring and Hibernate. Like so many things in life, it’s all about who you know. And how do you get to know people? Through people you already know! It’s all about being part of the community.

Communities exist in our field at many levels. In Structure of Scientific Revolutions, Kuhn shows that small communities within each scientific specialty decide when a new paradigm is superior to an old one. They control the direction of the field and set the rules for all practitioners of their science.

Getting a job is one challenge. Getting into the community that defines the direction of the field is another.

To excel takes hard work, merit, and opportunities. If any one of these is most critical, it is opportunities. [2] How does a person become qualified for an industry-leading group? Experience. How do they get experience? Someone gives them that first opportunity.

How does a hard-working, skilled person get into a community? Someone invites them in. Work all you want, but until someone gives you a chance, you’re stuck on the outside.

Me, I was lucky: someone invited me into the conference-speaker community and introduced me to people who are now my friends. I’m speaking, blogging, tweeting, and digging into technology all because one person held out a hand and said, “you could do this too.”

If you are a hiring manager, look outside the official experience profile and hire someone smart.

If you are part of a community, especially an informal one, find someone with potential and hold out a hand. Invite them to your gatherings and share ideas. Look beyond the obvious candidates. Raise up more chickens, and we’ll get more eggs. Everyone will eat better.


[1] My coworker Sarah did.
[2] Outliers, by Malcolm Gladwell. If you disagree and haven’t read the book, please read it.

This is not OK

After the first session at StrangeLoop, I ran downstairs, heading for the side of the lobby with the women’s restroom. I had to pee. Halfway there I looked up; it said “Men’s Restroom.” Turned around: “Men’s Restroom.” Wait a minute.

The venue converted the women’s room into a men’s to alleviate overcrowding. They did not ask the conference organizers. The ushers remarked later that it was the first time they’d ever changed the main women’s room into a men’s, while the other way around was common enough.

Trapped between two men’s rooms, I flipped out. I had to pee and this was NOT OK. An usher pointed me around the corner, where the Family Restroom was relabeled “Ladies.” It was a one-seater.

There was no line.

That day in the Family Restroom I threw a fit. Hurled my water bottle at the wall and screamed, “This is not OK!”

StrangeLoop is the most awesome of programming conferences, with less “you can use this in your day job tomorrow” and more “you can think about this for months and then it will embiggen everything you do.” Seven of the speakers at the conference were women, better than the local conferences I’ve attended this year. Thirty or forty women attended, of over a thousand. 3%.

I exited that bathroom and looked around at the sea of men, and it looked different than ten minutes before. Ten minutes ago it was expected. Now it was NOT OK.

There are women in programming. Usually there are a few other women wherever I’ve worked, something like 15%. (More at Amdocs, which was an Israeli company.) Look at the women who attend conferences, and there are fewer, around 10%. Take a highly technical, serious-about-this conference like StrangeLoop, and we’re down to 3%.  Speakers at technical conferences are somewhere between 3-10%, partly because organizers recognize that women speakers are a good influence on the industry and bring more women attendees.

The rest of the conference, I veered far from my usual mode of operation. Instead of talking among my friends and targeting mostly men to meet, I chased down women in hallways to say hello. Ines Sombra suggested over twitter a gathering for drinks that evening, and it became my mission to invite every woman I saw.

Saint Louis has a vibrant software industry, especially lately. We have a shocking variety of user groups; I’ve spoken at six this year. There’s a group for every ecosystem and favored text editor. Across the board, attendance is 30-50, yet if I see another woman I get excited. At first, people thought I was a recruiter. Extroverted female at a programming group? It was a reasonable assumption.

Monday evening at StrangeLoop, fourteen passionate women programmers sat around three pushed-together tables. We broke into conversations with the people nearest us. I had before never spoken with three other women about technical topics. It felt good! It felt really, really good. We considered starting a group for women in tech in St. Louis.

There aren’t enough women in programming. I applaud those who work to get more girls to choose STEM careers. (shout-out to Atomic Object, who sent a few of my favorite people to StrangeLoop.) There are initiatives to raise awareness of bias and sexism in the workplace. There is encouragement for women to speak at conferences. But what about the level above that?

There are speakers, and then there are respected thought leaders. The keynoters, the language designers, the authors of seminal texts. Where are the women there? Can you name one in this millenium?

Enrollment of women in computer science is decreasing. The women who do program move up to project management instead of architecture. Senior developers go home at five thirty while their husbands lead user groups. Why?

I want to find role models at the very top of our industry. I want to make talking tech with other women  commonplace. I want to encourage women to make programming a career. I want more women at StrangeLoop.

Confessions of a woman in tech

I have enjoyed being a woman in a profession dominated by men. I love being the only woman in a roomful of men. I love when they open doors for me. When they carry heavy boxes for me. When they give me a chair in a full room.

I love it even more when a man patiently answers all my new-team-member questions. When my infrastructure requests get done fastest because I call the man and ask him nicely. When I introduce myself to a random person in the coffee room and he is happy to talk to me.

I tell penis jokes and curse so that men won’t mistake me for a lady they have to tiptoe around. The stereotypical programmer – white, heterosexual, historically sexually frustrated, geeky — these men like me. That sexual tension can be an asset. Women don’t like me. I have made-up reasons for why, but I don’t know. I’m too busy hanging out with the guys.

At conferences it’s even better. I can sit down at any random table and strike up a conversation, and it’s easy because I’m a woman. Most men at conferences are pleasantly surprised and talk with me. Attention is everywhere. Speaking is even better, because then I seem extra-smart. I don’t have to prove my geek cred when my badge says “Speaker.”

I’ve been hit on at work. I don’t mind – hell, I relish in it. Call me “toots” and I’ll smile at you, as long as you are smart as hell or know your shit. I’m supposed to be offended, if not for my own sake then for other women who don’t want to be “toots.” But I like the attention.

The movement for women in technology has received lackluster support from me. As a woman, I’m supposed to be all passionate about this. Yet, deep down, I don’t want more women in my group. I don’t want more women speakers. I love being in the minority, because I love special attention.

Is this ugly? Fuck yeah it’s ugly. It is also me, it has been me for years, and I have to own it before I can move on from it. This is me owning it.

Next post, I’ll tell you the moment this changed.

in which I exhibit sexism in the same tweet that I complain about it

The other day, a scientist announced the detection of the Higgs Boson in a presentation using the much-maligned Comic Sans font. Dialog about the discovery focused on the design faux pas. I made this tweet, which felt pretty clever at the time:

//platform.twitter.com/widgets.js Other people found it pretty clever too. 76 retweets, 60k impressions, my most-retweeted ever by a factor of five.

Except.. the new elementary particle wasn’t announced by a dude.

//platform.twitter.com/widgets.js My apologies to Fabiola Gianotti. Congratulations, as well.

I made the assumption “prominent scientist = dude.” Pardon me while I smack myself in the forehead.