Macho Anti-Patterns

The Pool Party

Indulge me in an analogy: Imagine you’re at a pool party. There’s laughter, splashing, someone’s tossing around a beach ball. And then this idyllic scene is pierced by shrieks of horror. The once-happy swimmers are swarming out of the pool, their faces contorted in disgust. There are tears. People are wrapping themselves in towels, heading for the exit. The news spreads like wildfire. There is a turd in the pool. Where did it come from? Who is the culprit? How long has it been there? What is to be done?

Into this scene comes the party’s host. His face is red, his martini glass dangles in his hand, for the moment forgotten. “Wait!” he shouts! “Don’t ruin the party!” He dips a toe in the water. “It’s not such a big turd! Just ignore it!” He makes a show of splashing about. “Everyone! Get back in the pool!”.

I work in the tech industry. I help make software in a large company, and I participate in what is broadly defined as “tech culture”. There is a turd in our swimming pool. That turd is sexism, along with a kind of filthy miasma of other prejudices. And as much as we shout about wanting to get women and other underrepresented groups back into the industry, their absence is only a symptom of the problem. We won’t fix tech by fixing its demographics. We’ve got to get that goddamn turd out of the pool.

This is an essay about the complex pattern of expectations, values, and habits of thought we have around sex and gender — the patterns that are sometimes identified as “sexism” or “patriarchy” or “misogyny” — and how those patterns shape — and to a large extent harm — tech culture. This is not an essay about gender diversity in tech. That’s an important issue, but it’s a natural consequence of the deeper problems in our industry. This is an essay about those deeper problems.

To be clear, I am by no means an authority on any of these things. Smarter people than me have done a great deal more work than I have on this topic, and taught me what little I know. The fact that I’m able to write this essay at all is due to that huge amount of work, the burden of which has been chiefly borne by women and other minorities. I think we have tended to view tech’s sexism problem as mostly a “women’s problem”, and women have certainly been on the receiving end of some of the worst effects of this problem. But tech’s problems affect everyone in tech. It’s past time that we talked about the ways that tech’s misogyny affects both men and women, and talk about it from a perspective of how men in the industry can change those patterns of behaviour. I want to talk about how we can make tech better.

Anti-Patterns

The lens I’ve chosen to use for this essay is one that should be familiar to many people in tech. The “anti-pattern” is a concept used by developers to describe common solutions to problems that either fail to solve the problem, or in solving the problem, introduce even greater problems. Technology anti-patterns are often esoteric and domain-specific. But the concept of anti-patterns can be applied more broadly. In the field of management, for example, “micromanagement” is a common anti-pattern. A manager who wants to ensure a result is achieved resorts to minutely controlling the actions of their staff. But this exacting control has a counterproductive effect, producing resentment and reducing initiative and motivation.

I’d like to propose the concept of “macho anti-patterns”: solutions we have created in tech culture to address gendered anxieties, which have unintended or counterproductive consequences. As inhabitants of a patriarchal culture, we are beholden to its expectations and influences. Our culture in tech is a microcosm of that wider culture, and the tools we have developed for navigating that culture are creating problems for us. We need better tools, and we can start by identifying and dismantling our existing solutions.

The Hero Developer

He is part rock-star. Part ninja. Somehow he simultaneously embodies the concepts of stealth and precision, and showmanship and recklessness. The legends say he built half the site in the space of a weekend. He’s the only one who understands how most of it even functions. His code is flawless, beautiful. And if anyone else was smart enough to appreciate it, they’d say so too.

The Hero Developer is a myth we have created in tech that turns some of the worst stereotypes of our profession into strengths. The Hero Developer represents the platonic ideal of a particular image of what tech work is. The myth valorises the aspect of development work that is about logical problem-solving, and ignores all others. In this conception of tech work, writing code is a pure meritocracy, where the smartest will inevitably rise to the top. This anti-pattern fetishizes caffeine-fueled all-nighters, blistering feedback on other people’s pull requests, and an “us-against-them” approach to management.

Anti-patterns are solutions to problems, and the Hero Developer is not an exception. The problem that this anti-pattern attempts to solve is, I think, a crisis of masculinity. Especially in the early days of tech culture — the dot com boom that shaped a lot of the ideas about what it meant to work in tech, the kids who got jobs writing code were not the kids who were succeeding at traditionally masculine pursuits. They didn’t play sports, they didn’t drive trucks, and they didn’t get a lot of dates. Tech culture invented a series of myths about itself in an attempt to “butch up” the act of sitting at a desk for hours on end.

But it’s not a very good solution to the problem. The myth is already starting to break down. The poor cost/benefit ratio of this kind of developer is becoming apparent. In a smaller company, where the entire application might practically be understood and managed by a single developer, these people can be an asset, at least in the short term. They can deliver huge quantities of work in a short timeframe, and as long as they’re the only one who has to work with it, their code functions fine. But in larger companies, or over a longer timeframe, they are hugely dysfunctional. No one else can work with their code. No one wants to talk to them to try. New developers are intimidated by them and quickly learn not to question their decisions.

The pattern is dysfunctional even for those developers who are succeeding according to its standards. The pace of work is unsustainable, the pressure of keeping on top of every piece of code is impossible. Every new hire, every new project, starts to feel like a threat to a carefully constructed house of cards.

Contempt Culture

The term “Contempt Culture” was coined by Aurynn Shaw in her 2015 essay of the same name. She called attention to the pernicious tendency in tech culture to pour scorn on so-called “lesser” programming languages, and to valorise “real” languages as objectively superior. I think the key insight in her essay is the way that this prejudice is leveraged to establish “contempt currency” — that people establish and maintain their position of belonging within tech culture, by rigidly enforcing the boundaries of what should be considered outside tech culture. Shaw exactly describes the process by which the more moderate voices are forced to the periphery of tech communities, leaving only the most toxic, the most ideologically pure voices in the center. She also describes the negative consequences, both personal and technical, of this process.

I think the “Contempt Culture” Shaw describes is also an example of a macho anti-pattern. It’s an attempt to solve a problem, in that Contempt Culture is leveraged to secure people’s position as belong within a social niche. It’s a solution to the problem of feeling insecure and unwelcome in the tech community. But it’s also inextricably linked with gender. The lines along which the boundaries of sanctified and scorned languages are drawn are inherently gendered lines. Look at the qualities of some of the most heavily scorned languages: Java, PHP, CSS, Javascript. These are, for the most part, languages primarily used for front-end development, and languages that are picked up early in a developer’s career, as they’re more accessible or immediately intuitive. By contrast, some of the most valorised languages, Haskell, C# and C, for example, are more abstract, more low-level, at least in their proponents’ opinion less concerned with making things look good, and more concerned with making things function. Miriam Posner writes in this article that this difference in the way we value front-end and back-end development leads to real gaps in the way these roles are paid.

I don’t think that’s a coincidence. I think that the scorn for these languages is part of tech culture’s wider scorn for the feminine. Anything associated with the “soft” world of user interactions, of appearance and design, is seen as lesser than the “hard” work of logical processes, of data structures and algorithms. This extends to almost every aspect of tech culture. “Hard” science fiction about warfare and politics is praised over the “soft” sci-fi that concerns itself with emotions and relationships. “Hardcore” video games, which concern themselves with violence and competition, are valued above “casual” video games which have more diverse themes.

Code Uber Alles

There’s a hierarchy in how we value work in tech companies. This hierarchy is apparent in salaries and in explicit power structures, but it’s even more apparent in the less tangible ways that work is valued. It’s apparent in who is considered to be doing the “real” work in a tech company, and who is considered to be “supporting” that work. It’s increasingly common for tech work to be done in small multi-functional teams, who bring a range of skills to bear on the problems they’re trying to solve. In theory, each team member plays an equally important role in bringing the project to fruition. But in practice we value some of those skills very differently to others. Organisational work, such as scheduling meetings, engaging with stakeholders, or managing delivery processes, is often seen as less valuable, or not “real” work. Other devalued roles include quality assurance, design, and user research. Even within roles that write code, the way different projects are valued is stratified by the kind of work they involve: maintenance work, keeping things running, or improving and documenting internal processes is valued less than building new things, less than “going fast and breaking things”.

This way of valuing work differently, and of valuing the work of writing code above all other roles in a team is an anti-pattern. Which is to say, it’s a solution to a problem. But what is the problem it is solving, and who is this solution useful to? I think that it is, to some extent, a solution to a sense of insecurity and inadequacy. That insecurity comes from dealing with complex and multifaceted problems, and having only a limited skill set for dealing with them. When all you have is a hammer, it’s comforting to believe that your biggest problems are caused by protruding nails.

But this is a solution that causes problems. Technically brilliant solutions which nevertheless completely fail to meet customer needs. Code which never quite works outside of the walled garden of some development environment. Dysfunctional teams which keep looking for technical solutions to interpersonal problems.

As with contempt culture, there’s a pattern to what kind of work is valued, and which is not. Work which is seen as “helping” is valued less than work that is seen as “doing”. We value “hard” skills over “soft” skills. This is a gendered dynamic. It’s no accident that the work that is valued less in tech companies tends to be done in roles that have a greater proportion of women doing them. Historically, support work has been seen as women’s work, and women’s work has been seen as less valuable than men’s.

Gender Theory

It’s not often that I get to say this, but this is a situation that calls for some poststructuralist feminist theory. If I’d studied computer science or engineering, my first response to this complex social problem would probably be to build an app. But before I was a data scientist, I studied Social Anthropology, so my first instinct when faced with complex social problems is to look at the cultural underpinnings of those problems, and to use academic theory to help me understand them.

The anti-patterns that I discussed above aren’t the product of random chance. It’s not an accident that they’ve worked out the way they have. There’s a structure that underpins them, and it’s a structure that’s been extensively studied and discussed by a body of academic work.

Claud Levi-Strauss was a French social anthropologist who was the author of a very influential theory of social interaction and human thought called “Structuralism”. In this way of thinking, human beings construct meaning by imagining binary oppositions between sets of linked concepts. In his 1964 book “The Raw and the Cooked” Levi-Strauss extrapolated from prosaic sensory contrasts such as “raw” and “cooked” to explain and contextualise whole bodies of myth and cultural practices. This sounds hopelessly obscure and academic, but it’s a surprisingly interesting way of looking at the world, and especially for understanding how we construct gender. Poststructuralist feminists have expanded upon Levi-Strauss’ theory to describe how gender is understood in western society through a set of opposed concepts. You can spot structuralist and poststructuralist analysis by the way they like to draw up little tables of opposed ideas, like this:

Male — Female

Masculine — Feminine

Hard — Soft

Logical — Emotional

Functional — Pretty

Competitive — Cooperative

Acting — Supporting

Structured — Intuitive

The idea is that we tend to associate the things on the left together, and think of them as opposed to the things on the right. Moreover, our understanding of the meaning of these things is tied to these constructions — to be “masculine” is, to some extent, understood as the quality of “not being feminine”, along with all of the associated ideas. Poststructuralist feminists describe another dimension to this pattern — the effects of patriarchy on how we understand gender. In this way of thinking, the effects of patriarchy are twofold:

First, to rigidly enforce the division between these opposed pairs. Men must be masculine, and women must be feminine, and they both must display all of the other qualities associated with those ideas in order to successfully perform those roles.

Second, patriarchy tends to value male-coded traits more highly than feminine-coded ones. We reward people more highly for successfully performing masculinity than femininity. An interesting product of this is that while women who can perform some aspects of masculinity will be (grudgingly) rewarded for doing so, men who perform femininity will be scorned.

I think that recognising these systems, and especially being able to relate them to the macho anti-patterns I’ve described above, is key to understanding and eventually dismantling some of the problems we have in tech. I think that each of those anti-patterns has its roots in this patriarchal construction of gender, and that by understanding this, we can begin to confront it.

Grasping the Turd

So what is the solution to these anti-patterns? How do we get these turds out of our swimming pool? I think the solution lies in understanding that, as anti-patterns, these are attempts at solving problems, and unless we offer alternative, superior solutions, we can’t expect these patterns to go away. So let’s address those problems.

The “Hero Developer” is a response to a crisis of masculinity — it’s a way of associating masculine traits: hard, competitive, logical etc. with work that otherwise might not be seen as such. But I think that the underlying fear for people who embrace this anti-pattern is not that they won’t be perceived as sufficiently masculine. I think the fear is that if they are not perceived as masculine, they won’t be considered good at their job. I think to combat this anti-pattern we need to reshape the qualities we look for in good tech work. Rather than valuing individual heroic contributions, I think we need to value useful participation in a successful team.

Contempt Culture is an attempt to secure a sense of belonging in an exclusive culture. It works by rigidly drawing boundaries along gendered lines, and gaining currency from enforcing those boundaries. Only the most hardcore, the most logical, the most purely functional, can truly belong within tech culture, and there are always minute gradients of correctness to establish hierarchy and jockey for position. I think the problem at the heart of this is the exclusivity in tech culture, and the accompanying anxiety of being excluded. The best antidote to this, I think, is to inculcate a radical inclusivity amongst cultural leaders in tech. I think we need to replace contempt culture with curiosity culture — a passionate desire to understand people who have different experiences to ourselves, a hunger to learn new ways of working with different technologies and to appreciate the challenges and context which has shaped them. When we learn from each other, we form a community that is bound by mutual respect and participation, rather than exclusivity and anxiety.

“Code Uber Alles” is the idea that writing code is the most important part of creating new technology. It’s a reflection, I think, of the broader cultural trend to value male-coded skills over female-coded ones. People in tech who have only ever been taught the prized “hard” skills of writing code are invested in maintaining that distinction — that of all the skills that are required to solve problems in tech, theirs are the most important. Acknowledging that there are other, equally vital pieces to this puzzle means acknowledging their own less-than central role in solving these problems. But I think there is an easier path. Solving problems in tech requires more skills than any one person can master. In fact, there’s strength in the simple fact of having more diverse points of view, of having a wider breadth of opinions and ideas brought to bear on a problem. Decentralising one set of skills might be a difficult transition for some, but I think the tradeoff — of sharing both the praise and blame of successes and failures — makes for a more enjoyable and psychologically safe working environment for all of us.

Back in the Pool

This is not an essay about diversity in tech culture. While I absolutely believe that addressing the demographic imbalances in tech is a worthwhile goal, I think that the first step to this goal is starting to fix tech’s culture. We have a problem with machismo, and the solution is not just to hire a bunch of women to handle “the lady stuff”. We need to dismantle the entire paradigm which assigns a set of qualities to one gender, and values those qualities above all others. This is not about valuing the feminine above the masculine, or even about attempting to achieve some kind of balance between the two. This is about realising that we’ve been sold a false dichotomy.

We can be better people, and incidentally make better technology, if we recognise that we don’t have to embody only half of that table of opposed ideas. Form doesn’t have to be sacrificed for function. We can choose the right times to be hard, and the right times to be soft. We can be logical and emotional. We can be masculine and feminine. We can make a more inclusive, a more exciting, more productive and more innovative tech culture if we abandon these anti-patterns which have failed us, and look for real solutions.