The Price of Having Men Dominate Software Development

Computer programming at its infancy, from the 1940s onwards, used to be a field dominated by women. As a detail-oriented job with no hard physical labor, requiring collaboration and patience — with an old-fashioned view on gender roles it makes sense. After a gradual switch over decades, today things are very much at the opposite end of the gender spectrum. Along with the automatically heightened pay and prestige such a switch (sadly) tends to bring, the men brought their masculinity into the craft, and it has always fascinated me how that masculinity manifests itself.

It’s not quite locker room talk but not that far away either. I’ll call it server room talk.

Software development has none of the traditional hallmarks of male-dominated fields. There is no physical aspect, there is no uniform, often no rigid ranks or hierarchies or other explicit signs of power — you cannot tell who’s the top dog by counting the stars on their collar, gauging the sharpness of their suit or the shade of white on their business card.

The flaunting of power creeps in in other, subtler ways. Gatekeeping and elitism are common, presenting as looking down on (or even flat out refusing to use) certain tools and technologies, and in general having an overly dogmatic approach. I’ve seen projects with extremely intelligent and technically capable developers nearly fail due to communication devolving into a clash of egos with pragmatism thrown out of the window — 21st century chest beating that I have a hard time seeing happen in a more diverse environment.

The “boys club” atmosphere is also prevalent in the banter and smack talk sometimes thrown around. It’s not quite locker room talk but not necessarily that far away either, and is a factor in perpetuating the lack of diversity. I’ll call it server room talk.

“Feminine” developers tend to be not as highly regarded or noticed, regardless of their gender.

The masculinity, with its drive for competitiveness and status, also manifests in favoring certain aspects of the actual programming work as well. Traits that emphasize the prowess of the individual, such as wanting to solve narrow but complicated problems, optimization of algorithmic efficiency and looking to master bleeding edge technologies tend to give the most status and are thought of as being the most desirable. They also tend to disproportionately dominate recruitment and job interviews.

Meanwhile the importance of vital traits that focus on empowering the collective, such as diligence in communication and documentation, adherence to beneficial processes, being open to alternatives, thinking of the big picture and striving for cooperation, many of which could be classified as stereotypically feminine, is diminished. That’s not to say that members of any gender can’t be “feminine” developers — they certainly can, and I find them to most often be the silent but important contributors that don’t get recognized or compensated according to their merits. And you really do need all kinds of developers in your team to truly flourish. In software development, diversity is strength.

If you have straight white men coding an algorithm, you will get a straight white male algorithm.

So, the lack of diversity has a negative effect on the efficiency, open-mindedness and enjoyability of the work environment. But it leaves a mark on the end product as well, which is increasingly important as more and more of our society depends on software and automation.

There’s this fallacy that if a task is done by a computer analyzing vast amounts of data, there’s no bias. That’s a load of crap. If you have straight white men coding an algorithm, you will get a straight white male algorithm, emphasizing the values they consider most important. This has already come up in alarmingly important matters such as criminal justice, but an example on how pervasive of a problem bias in data analysis can be, even snow plowing schedules can be sexist. And things get even worse when delving into intersectionality.

Educate yourself on what people are like. You know, other people, besides yourself.

So how should people act in light of all this? I’m not sure if I’m the best person to give advice on that, being largely part of the homogenous stereotype, but I can tell the advice I try to give myself:

• Figure out what kind of developer you are. Work on your weaknesses and appreciate the strengths that different people bring into the team. You might have to work on even noticing those strengths. Everybody is better than you at something.
• Foster work environments that are enjoyable for people in general, not just people like yourself. It is also in your own best interest if you want to build better software.
• Don’t build systems using yourself as a measuring stick. The population does not share your characteristics. They have differences in eyesight, color vision, hearing, dexterity and other physical ability, physical appearance, gender, height, weight, skin color, sexuality, technical expertise and aptitude, culture and religion, among a thousand others. Educate yourself on what people are like and how it affects their usage of technology.

So in a nutshell: start by thinking about others and don’t be a jerk. Simple advice, but bears repeating. And while it is valid advice for everyone, it most often gets forgotten by those who the societal default is greatly skewed towards— which happen to be the same ones who write a disproportionate chunk of the software we use every day.