So it seems that someone has seen fit to publish an internal manifesto about gender and our “ideological echo chamber.” I think it’s important that we make a couple of points clear.

(1) Despite speaking very authoritatively, the author does not appear to understand gender.

(2) Perhaps more interestingly, the author does not appear to understand engineering.

(3) And most seriously, the author does not appear to understand the consequences of what he wrote, either for others or himself.

1.I’m not going to spend any length of time on (1); if anyone wishes to provide details as to how nearly every statement about gender in that entire document is actively incorrect,¹ and flies directly in the face of all research done in the field for decades, they should go for it. But I am neither a biologist, a psychologist, nor a sociologist, so I’ll leave that to someone else.

2. What I am is an engineer, and I was rather surprised that anyone has managed to make it this far without understanding some very basic points about what the job is. The manifesto talks about making “software engineering more people-oriented with pair programming and more collaboration” but that this is fundamentally limited by “how people-oriented certain roles and Google can be;” and even more surprisingly, it has an entire section titled “de-emphasize empathy,” as one of the proposed solutions.

People who haven’t done engineering, or people who have done just the basics, sometimes think that what engineering looks like is sitting at your computer and hyper-optimizing an inner loop, or cleaning up a class API. We’ve all done this kind of thing, and for many of us (including me) it’s tremendous fun. And when you’re at the novice stages of engineering, this is the large bulk of your work: something straightforward and bounded which can be done right or wrong, and where you can hone your basic skills.

But it’s not a coincidence that job titles at Google switch from numbers to words at a certain point. That’s precisely the point at which you have, in a way, completed your first apprenticeship: you can operate independently without close supervision. And this is the point where you start doing real engineering.

Engineering is not the art of building devices; it’s the art of fixing problems. Devices are a means, not an end. Fixing problems means first of all understanding them — and since the whole purpose of the things we do is to fix problems in the outside world, problems involving people, that means that understanding people, and the ways in which they will interact with your system, is fundamental to every step of building a system. (This is so key that we have a bunch of entire job ladders — PM’s and UX’ers and so on — who have done nothing but specialize in those problems. But the presence of specialists doesn’t mean engineers are off the hook; far from it. Engineering leaders absolutely need to understand product deeply; it’s a core job requirement.)

And once you’ve understood the system, and worked out what has to be built, do you retreat to a cave and start writing code? If you’re a hobbyist, yes. If you’re a professional, especially one working on systems that can use terms like “planet-scale” and “carrier-class” without the slightest exaggeration, then you’ll quickly find that the large bulk of your job is about coordinating and cooperating with other groups. It’s about making sure you’re all building one system, instead of twenty different ones; about making sure that dependencies and risks are managed, about designing the right modularity boundaries that make it easy to continue to innovate in the future, about preemptively managing the sorts of dangers that teams like SRE, Security, Privacy, and Abuse are the experts in catching before they turn your project into rubble.

Essentially, engineering is all about cooperation, collaboration, and empathy for both your colleagues and your customers. If someone told you that engineering was a field where you could get away with not dealing with people or feelings, then I’m very sorry to tell you that you have been lied to. Solitary work is something that only happens at the most junior levels, and even then it’s only possible because someone senior to you — most likely your manager — has been putting in long hours to build up the social structures in your group that let you focus on code.

All of these traits which the manifesto described as “female” are the core traits which make someone successful at engineering. Anyone can learn how to write code; hell, by the time someone reaches L7 or so, it’s expected that they have an essentially complete mastery of technique. The truly hard parts about this job are knowing which code to write, building the clear plan of what has to be done in order to achieve which goal, and building the consensus required to make that happen.

All of which is why the conclusions of this manifesto are precisely backwards. It’s true that women are socialized to be better at paying attention to people’s emotional needs and so on — this is something that makes them better engineers, not worse ones. It’s a skillset that I did not start out with, and have had to learn through years upon years of grueling work. (And I should add that I’m very much an introvert; if you had asked me twenty years ago if I were suited to dealing with complex interpersonal issues day-to-day, I would have looked at you like you were mad.) But I learned it because it’s the heart of the job, and because it turns out that this is where the most extraordinary challenges and worthwhile results happen.