I've tagged this as opinion because it's mine. Obviously, I'd be gratified if you made it yours since that's the only reason for writing a persuasive essay after passing Senior English. If you disagree with some or all of what I have to say, I'm willing to read your persuasive essay too. If you hate my opinion, all I can say is that I'm sorry.

Left: Glen Beck Right: Frances Elizabeth Snyder Holberton

We recently ran a survey on Stack Overflow and noted:

Compared with men, women who code are nearly twice as likely to have less than 2 years programming experience. We hope this means more women are joining the industry and closing the gender gap.

Just to be clear, we know that our survey under-counted female developers, so the first sentence might not be representative of demographics as a whole. The second sentence, however, is hopelessly and naively optimistic. Best case: experienced female programmers are less likely to take our survey. But I worry that women leave the computer industry or shift out of programming roles sooner than men do.

The survey didn't really ask the sort of questions needed to figure out why there are so few female programmers. I wondered out loud if woman leave because of hostile work environments. My wife, trained as an RN to think critically, asked if I'd looked at AP test results. In the US, high school seniors have the option to take any number of tests that will allow them to skip freshman level courses in college. Looking at this data removes a lot of complications such as whether women are dropping out of the programming profession to have children or not getting hired because employers are afraid they will get distracted by having children. So here's how males and females performed on the Computer Science and Calculus AB Advanced Placement tests from 2006 to 2013:

Boys Girls Total
CS performance 64% 56% 62%
Calculus performance 62% 54% 58%

64% of male students and 56% of females passed the Computer Science test (with a 3 or better). This is a problem for my theory, but the gender gap doesn't fully explain why only about 20% of programmers working in the US are women. No, the real problem is the ratio of young men and women who take the test in the first place:

Boys Girls Total
CS participation 81% 19% 100%
Calculus participation 52% 48% 100%

AP Calculus is pretty important for anyone planning on entering college. Even if you aren't majoring in anything math-related, passing the exam will exempt you from the Quantitative Reasoning requirement many universities have. Most high schools offer AP Calculus for college-bound students and women now outnumber men on campuses, so it's not surprising that close to 50% of the students taking Calculus AB are female. By contrast, the CS test only makes sense if you are considering a computer science major or have already learned some programming before your senior year.

Therefore, whatever causes keep women from working as programmers have pretty much been in place by the time girls are 17 years old or so. Hostile work environments can't be the reason so few women are programmers. At best my theory explains why some offices have more women than others. We have no way of knowing if the ~20% of women working as programmers are the same ~20% as took the AP Computer Science test, but it's startling that the numbers worked out that way.

As it happens, I took (and passed) both AP tests my senior year. Taking Calculus was predictable enough; I'd excelled at math since elementary school. But taking the CS test depended on a series of happenstances:

  1. My parents bought a Tandy 1000 SX computer when I was in 6th grade. It was a pretty good gaming PC for it's time and I often spent my allowance on new games (starting with Silent Service). At some point, I acquired David Ahl's BASIC Computer Adventures which contained the source code of 10 fairly simplistic games, including Westward Ho!, which is an Oregon Trail clone. I spent many hours keying in and debugging these programs; playing the games was boring in comparison to reading the source and improving them.
  2. Later, my family moved to San Jose, California. Being in the heart of Silicon Valley, the public library had a extensive collection of programming textbooks. So in addition to reading Isaac Asimov's Robot series, I consumed books about Artificial Intelligence that prompted me to write little programs that simulated robotic mice solving digital mazes.
  3. Halfway through my junior year, we moved to Fairfax, Virginia, which pretty much killed the last vestiges of my social life and freed me to spend more time typing on the computer.1 It also gave me a chance to take a Computer Science class that introduced me to Pascal. Not entirely coincidentally, the AP CS test was based on Pascal at that time.

The details are different, but many successful programmers can tell similar stories. Being introduced to computers early in life, having a personality amenable to spending lots of time with them and access to programming resources, greatly increased the odds that I'd take and pass the AP test. Programmers take it as common wisdom that this sort of back story indicates the personality necessary for being a successful developer. Joel Spolsky writes about sorting resumes:

Passion. We look for evidence that the applicant is passionate about computers and really loves programming. Typical evidence of this:

  • Jobs with computers or experience programming going back to a very early age. Great programmers are more likely to have spent a summer at computer camp, or building an online appointment scheduler for their uncle the dentist, rather than working at Banana Republic folding clothes.

  • Extra-curricular activities. People who love programming often work on their own programming projects (or contribute to an open-source project) in their spare time.

  • Waxing rhapsodic in their cover letter about how they were moved to tears by The Structure and Interpretation of Computer Programs.

Having some of these traits may have given me a leg up in interviews. Over my career, I've submitted resumes for 8 different programmer positions2 and received offers from 7. Now I was very selective in where I applied, had personal connections and was probably a bit lucky. Even so, there's no doubt that a handful of things outside of my control made the difference between getting jobs and not.

So we've reached the pivotal point in this essay where we must ask ourselves: Am I really the sort of person who makes an ideal programmer? It's something I've taken on faith so long, it's hard to break the reflex that equates "passion" with outstanding developers. In fact, I've put off writing the next half of this essay because it conflicts with my mental model of how successful programmers work. When I'm productively programming, hardly anything else seems worth doing; I'm not able to turn that portion of my brain off once it's operating. So it seems impossible that someone who doesn't experience the world the way I do can be productive as a software engineer.

Indeed, research does suggest that some people are able to think semantically about their code and others are not. Anecdotally, even people with advanced degrees in Computer Science can't write simple programs on demand. So those of us in the profession have invented a sort of reverse mirror test to determine if prospective hires are in or out of the group of people likely to become successful programmers. We look in other people for markers (such as spending free time programming) that we feel identify us as exceptional.

If we judge programmers by things such as whether they take and pass AP Computer Science in high school, there's strong evidence that men are better developers than women. But I've worked with many female programmers and that just does not seem to be true. When I mentally rank the programmers I've known by how good they are at their jobs, women are as likely to be near the top of the list as the bottom. None of the typical markers of passionate programmers work either. The only real way to rank my colleagues is by remembering how well (and how often) they were able to complete projects, solve problems and fix bugs. There are no shortcuts.

The standardized AP test certainly doesn't cover the bases. The multiple choice section breaks down thusly:

Rank Classification Category Percent of multiple-choice items
1. Programming Fundamentals 55–75%
2. Algorithms/Problem Solving 25–45%
3. Data Structures 20–40%
4. Object-Oriented Programming 15–25%
5. Logic 5–15%
6. Recursion 5–15%
7. Software Engineering 2–10%

I like recursion as much as the next guy, but there's literally always a way to write a recursive algorithm iteratively and that's nearly always the best solution. Far more useful for students to learn would be:

  1. Using source control
  2. Creating a build system
  3. Writing specification documents
  4. Interface principles
  5. Writing user manuals
  6. Building an automated test plan
  7. Debugging

Some of this is probably hidden under "Software Engineering", but I don't remember ever getting instruction on these items. Every one of them I learned on my own. A good software engineer will spend significantly more time using those skills (especially debugging) than using recursion. I'm not saying that the AP course should be structured differently. For the purposes of this article I just want to point out that it covers a subset of the activities that define a programmer. This subset overlaps heavily with the subset of the job most likely to be scrutinized by potential employers. And it's the subset that most naturally fits the outlook of people like me who thrive on spending late nights alone with an editor and compiler solving intricate (and therefore interesting) problems.

The software industry fixates on great hackers—the Micheal Jordans of the field who are five or ten times as productive as ordinary programmers. These men (and if Google is to be believed, they are mostly men3) are able to create a new language in 10 days or start an aerospace company on the side. And why not? If you are starting up a new company, this is exactly the sort of programmer you'll want to hire.

As software projects expand, they need people to do all sorts of things other than designing data structures and efficient algorithms. When you start thinking of building a software team, it becomes clear that selecting for a few narrow traits is enormously dangerous. Like a basketball team that consists of nothing but seven-footers, a software team fails if there aren't people to fill all the positions. It's as if we've all read the Mythical Man Month, remembered "the order of magnitude" that separates great programmers from replacement level and forgot about the idea of a "surgical team".

When I was working as contractor to JPL, Raytheon was responsible for two ground-data systems for sister instruments launching on the same spacecraft. One system was designed by a single (and brilliant) programmer who worked mostly on his own. I was a junior developer on the other system that was designed by a small team. There's no doubt that the system built by an individual programmer was better in nearly every way.

After the systems went operational, the lead programmers on my team moved on to other jobs. So it was decided that the two projects would be merged. I was excited to be working with the programmer from the other project and was eager to bring his code into our system. Early on, we had a particularly difficult scaling problem and the other guy decided to solve it one weekend. Since he was used to working on his own, he put the changes into production with a quick email explaining what he'd fixed.

The only problem is that his changes broke another part of the system. I couldn't find the code because he hadn't checked it into our source control system. When I did get his code, I couldn't figure out how he had compiled it; he'd build it on his own machine and moved the binaries into production. He hadn't updated our documentation, he'd used the database library he'd written himself and there was no manual for it. For the next week, we worked to test and debug his changes, but because this was a production system we had to pull all of his changes out until we'd figured it out. A little later, he left the company and so the changes just didn't get pushed.4

As long as software companies fixate on hiring alpha male programmers, we are never going to see the full potential of technology. I don't just mean that we will be lacking in role models for girls or that our products will fail to meet the needs of female consumers. No, I mean that teams will struggle to overcome the inefficiencies inherent in working with rock-star developers.

Footnotes:

  1. My big project at that time was a galaxy collision simulator typed from a Sky & Telescope article. It was a great introduction to optimization and debugging. ↩

  2. If you count Stack Exchange, I'm 8 of 9. The one position I failed to get an offer for was an internship that explicitly asked for Computer Science majors. I studied Atmospheric Sciences. ↩

  3. Or the occasional woman wearing old-fashioned clothes. (Though part of the problem is that men have no fashions.) ↩

  4. The projects never did get merged because of my own Lone Ranger attitude. Shortly after I left the project, a colleague called to ask me to check in some code. So I probably ought not cast any stones. ↩