Stop Telling Women What They Aren’t Capable Of
When I first saw the title of Francine Hardaway’s post, I hoped it was just a bad, clickbaity title for a critique of one way Silicon Valley is currently missing the mark on women and girls. Nearly all discussions on how to improve tech’s gender problems focus on the so-called “pipeline problem.” Since that’s a reasonable critique related to girls’ CS education that I wish Hardaway had discussed, I’ll outline it here before responding to the specifics of her post.
The pipeline problem is the suggestion that the primary reason that there are so few women in tech today is that there just aren’t enough women and girls in the pipeline (same goes for minorities, but I’ll focus on gender since the original post does). So we advocate for teaching coding skills to girls, and increasing the number of women majoring in Computer Science, in order to get more women “into the pipeline” of software engineers for hire.
There are a few problems with this one-pronged approach. First, it doesn’t address a very major problem: women who do make it into the so-called pipeline leave the industry at much higher rates than men. 57% of women who enter careers in the technology industry end up quitting. Of those women, 38% report that “hostile macho culture” was a contributing factor to their decision to quit. 27% report compensation as a factor. One in three professional tech women report encountering dismissive attitudes from colleagues. Keep in mind that because these are current numbers, the vast majority of these women chose to pursue careers in technology before it was popular to advocate for teaching girls CS or equality for women in the field. Given their willingness to overcome the many hurdles—not receiving the same encouragement boys get, sexism in the industry, etc.—they are likely to be more passionate about tech than the average engineer. And they are getting discouraged to the point of quitting. If we don’t solve the retention issue, fixing the pipeline isn’t going to get us very far.
Another problem with this approach is that it’s a very long-term investment. Improving CS education for girls does nothing to improve things for the women currently in the technology industry, and won’t have much effect on the professional or academic worlds for another 10–20 years. And if we haven’t fixed the retention issues by that time, they won’t make much of a dent.
So now that I’ve said my piece on the pipeline problem, I’d like to respond to the actual post.
Hardaway proposes that we focus on gender equality in non-technical roles:
[E]veryone knows that tech companies don’t have enough women on their boards, in their management, or on their staffs. But that isn’t necessarily cured by teaching more women to code. It’s cured by hiring more women and promoting them from other parts of the organization.
All of this is correct — we absolutely should be working towards gender equality in non-coding roles, including investor, board, and C-suite roles. This will help women in the tech industry — and likely other industries as well — as a whole, including the women who do hold technical positions. My only problem is that Hardaway believes this is a reason not to teach women and girls how to code. She seems to think there are precisely two choices: either we improve equality in non-technical roles, or we teach girls and women to code. To that, I can only say…
Here’s the thing: that type of role isn’t for everyone. I know plenty of engineers who wouldn’t be happy in high-level roles. Yet they enjoy the work that they’re doing, they’re compensated well and treated with respect, and have an overall high satisfaction with their lives. A lot of people, myself included, actually enjoy writing code, and even do it to relax! There are plenty of people who find coding more enjoyable than they would find running a company. Let’s open up those opportunities to everyone, rather than telling women that senior leadership is the only goal worth pursuing. (Not to say we shouldn’t encourage women to pursue senior leadership, because again…we can do both.)
First of all, coding itself is a narrow function in which you write instructions to tell a computer what to do. People are fond of saying code is the next language, and that’s all fine, but there’s a difference between language and syntax. Coding is syntax. It is finely detailed work in a binary world, and it requires both attention to detail. When you write a line of code, you have to close the parentheses and make sure you put in the semi-colon or the code won’t run. It requires enormous concentration, and it is exacting. It’s often done in a dark room with no interruptions.
Okay. Uh, really? Like, for real? Where to even begin?! This is not only extremely insulting to all software engineers and computer scientists, it’s also really obvious that Hardaway knows almost nothing about what my being a software engineer is actually like. This might be a reasonable description of some people’s first 6–12 months learning how to code (pretty much the only skill level at which parentheses or semicolon placement will actually mess you up), but learning a programming language’s syntax is a very minor first step towards becoming a good engineer. It’s like learning the alphabet. This is like saying that learning how to read and write the letters of the Cyrillic alphabet is the equivalent of becoming fluent in Russian.
She seems to think that once you reach that stage, that’s about it for your professional growth. I’m sorry, but it’s laughable that after doing this for 8 years, I would have to sit in a dark room and concentrate on where I’m putting my parentheses and semicolons, because that stuff is second nature to me, and has been for years.
What I really do is sit in a (very well-lit) room with other engineers (and designers and marketers and product managers), doing any number of things: coding, planning the coding, reviewing others’ code, arguing about how to implement something, answering questions for others, researching possible solutions to a problem I’m trying to solve, working out time and deliverables tradeoffs with product folks, proposing alternatives, the list goes on.
And even if I spend all day writing code, literally zero seconds of that are spent thinking about correct placement of parentheses or semicolons.
I won’t elaborate further on the technical details here, since it’s likely to bore anyone who isn’t a software engineer, and anyone who is already understands just how unrealistic her description is. But consider that Computer Science is a rigorous academic field of study that people spend years of their lives earning degrees in, from bachelors up to doctorates. If it was really just a matter of learning syntax, what are they doing with all that time? Same goes for the professional world — why would places like Google or Medium give a hoot about relative experience and spend thousands of engineering hours putting candidates through day-long coding interviews, if the only skill level to achieve is learning a new syntax and having attention to detail? Why are there so many books, blogs, and publications dedicated to its art (and I don’t mean just syntax)? And wouldn’t these people get bored and burnt out extremely quickly if software engineering was anything like she describes?
But the most important people in the company don’t write the code, they tell the coders what to write. Coders don’t make the big decisions.
This can be true to various extents at many companies, and it can cause engineers to feel less invested or excited about the outcome of their work than they otherwise could be. But it isn’t true across the board. At many large technology companies, the most senior engineers are among the most important people at the company. Look at Jeff Dean, Sundar Pichai, or Urs Hölzle at Google. All are engineers, and are at least as respected within as any other exec — in many cases, even more revered by the massive engineering staff. (Context/disclosure: I used to work at Google.) And at Medium, the overall direction of the product is determined by a group of mainly less-technical people spanning various professional levels, but deciding what to build into the product to achieve those goals is owned by autonomous “initiative circles,” comprising product designers and engineers working together. For example, the Discovery and Delivery initiative gets to choose whether their goals to improve the reading and discovery experience are best met by improving search, building a new homepage, or architecting a new organizational site taxonomy. These groups that include technical people (aka mere “coders”) also work out the details of how those features should look and behave. Engineers do have a lot of input on key decisions, and this is true at an increasing number of companies.
Women don’t seem to want to code. They don’t choose it as a career, despite all the job openings and the high pay. In general, women are more intuitive and more perceptive.
There’s some lovely internalized misogyny here. I somehow missed the memo about nature vs. nurture having been definitively solved. The truth is that there’s no way to tell whether women are inherently biologically suited to code. We know that school-age girls outperform boys in math and science, which is counter to this claim. Perhaps if young girls were given construction, spatial, and logical toys while young boys were encouraged to play house, build friendships, and act out parenting, these “natural” strengths and affinities would be reversed (I’d be willing to bet that they definitely would be, if we treated biological girls as we currently treat boys and vice versa). Improving CS education for girls is itself likely to improve their affinity for coding, or help girls discover natural logical and problem-solving ability that they already possess. I grew up enjoying logic puzzles of all types, and I enjoy coding more than many other things. Can we please refrain from antiquated generalizations about women’s supposedly innate abilities or lack thereof?
But PET scans of the brain have led scientists to similar conclusions. The girls are not drawn to the same pursuits the boys are, no matter how hard you try to bring them up with gender equality.
This is actually just laughable because, as far as I’m aware, nobody has succeeded in raising a large enough group of children for a statistically relevant experiment, in a state completely isolated from all gender cues in the world. It’s well documented that adults treat even infants differently, depending on what they are told is the gender of the child.
Given that we cannot isolate for these factors, it is impossible to conclude that any differences in brain structure and behavior between men and women are the result of biology (the brain’s plasticity is also well documented).
There will be plenty of coders in the future. We happen to be in a period in which software rules, or as somebody once said, “software is eating the world.” But we’re fighting the last war here; we will eventually do the same thing with coders that we did with every other occupation where we identified a shortage: create a glut. We’ve done it with doctors, physical therapists, nail technicians, and lawyers. And then who will make the robots?
Cool, feel free to find me when that happens and maybe I’ll change my mind. Until then, I’ll continue to fight for women and girls to have the same opportunities as men and boys.
Actually, wait a second…are you telling this to boys too, or just to the girls?
The difference between good and bad code is like the difference between grammar and writing. Writing requires much more than just a knowledge of grammar and syntax. It also requires organization, imagination, creativity and experience. The analogue to writing in software development, IMHO, isn’t coding per se, it is system architecture and user interface.
Wrong again. I’ve already demonstrated that Hardaway lacks awareness of what an engineer does, and what a good engineer does. System architecture is indeed one analogue. (I would say that user interface is a different, but related skillset.)
But again, she misses a huge amount of growth that’s possible in the craft of writing code. If her analogy was correct, all code, as long as it compiles and works, would be of equal quality. Any engineer worth their salt knows this cannot be further from the truth. Bad code is hard to follow, bug-prone, doesn’t make much sense (and yet the syntax was valid, fancy that!). I’ve also worked with code that was structured elegantly, and was easy to understand and add to. This is not always related to the relative talent of the engineer, either — quite often, systems worked on by teams of talented and smart engineers evolve over time to the point that the code itself becomes difficult to work with needs to be refactored. So, yeah. There is a huge huge difference between good and bad code, and a huge opportunity for individual growth within the field of software engineering.
So here’s what I propose. Stop trying to coerce women to code.
Who’s coercing anybody? Do you need a dictionary?
Instead, hire them for the talents they have that tech companies sorely need: marketing, leadership, human capital attraction, and negotiating skills.
There’s that false dichotomy again! As if encouraging women to code is the same as saying they shouldn’t be hired for other roles! Of course we should hire women for the above roles. But we should also hire them to write amazing code.
In other words, stop forcing women into the male mold and accept them for who they are.
AHAHAHHAA go away.
