This is not an article about women in tech. Not because I don’t believe that female bodies in chairs and in the boardroom matters, and certainly not because I don’t want to meaningfully contribute to all the groundbreaking and awesome work being done to get them where they belong. Instead, I want to talk about a metaphor.
I work as a software developer on Media Temple’s Managed WordPress team, but as a curious young optimist (and student of feminist philosophy), what got me into coding was a metaphor. To be honest, I hated computers until I discovered Linux. GNU/Linux and Free/Open Source Software got me thinking about the implications of how objects of real value could be created in this world, right now, without the restrictions of a strong hierarchy, financial incentive, ownership, trade secrets, or even strict accreditation. This curiously egalitarian approach was such an incredible contrast to the concepts and metaphorical assumptions I was used to seeing in the “real world” that it appeared that I had stumbled upon some sort of feminist reality. I haven’t let go of my .vimrc since.
So, assuming that imagery and underlying assumptions matter, I want to discuss women-ness in tech. Specifically, what appears to be a quiet proliferation of distinctly feminine metaphors shaping the modern software industry’s best practices and, in turn, informing how we think about complex technical issues.
If language allows us to draw the boundaries around our world, then what are the implications in the language of what and how we can code? What are the paradigms and structures shaping the way we talk to our machines? What are the trends in the development of code? And what could this mean for the future of tech and, in particular, of our shared ability to world build?
Let’s Build It.
Select * FROM modern_software WHERE best_practice LIKE “Women’s Studies Required Reading”;
Since the SQL language sounds a lot like English, let’s use the above statement as the point of departure into a world where modern software development best practices are oddly reminiscent of some feminist principles. While we’re getting settled in, let me explain “duck typing”.
In object-oriented parlance, duck typing is a way of determining the class (or nature) of an object (or thing) based not on where it says it comes from, but what it acts like. If you have no idea what object-oriented programming is, don’t worry. Just imagine that all you care about is how an object behaves. For example: If it looks like a duck and talks like a duck… you get the point.
So, we’re going to look at duck typing the modern trends in coding practices (i.e. the software development process itself), in the context of a more feminist way of looking at the systems we prefer and the best practices we employ. How do these behave?
Let’s query our imaginary cognitive database, limiting the results to six for the sake of brevity, and consider the following result set:
Though it’s the least technical of the six, let’s look more closely at the first one.
Let’s “duck type” it.
To give some background, the engineering department at Media Temple has embraced the Agile software development process. While I could go on and on about this, here’s the TL;DR version: Agile proposes an incremental and iterative approach to designing software and solving problems, treating each stage as continuous and simultaneous. This is in contrast with the traditional “waterfall” method of software development, in which phases of development are treated as discrete and ordered, each terminating and flowing into each other like, you guessed it, a waterfall.
Duck typing Agile development methodology as a framework for radical receptivity is, surprisingly, a breeze. In Agile, there is a real consideration for how the most relevant feature works on the ground and not in theoretical construction. This philosophical groundedness is, once again, in contrast to the more abstract nature of value equality in the waterfall method. Waterfall assumes that one can model the process in one’s mind, sufficiently enough to plan a project start to finish. Therefore, the emphasis is on planning, documentation, and (most deeply) abstraction.
Conversely, Agile assumes that all projections and abstractions are no match for the nature of reality. Agile assumes that assumptions and requirements will change. It is a hands-on-based approach to cognition and world building with a strong focus on an ability to receive, to respond, to pivot, to pay attention, to shift assumptions and ideas quickly, without ceremony or pride. As such, Agile is a distinctly feminine worldview, and as our requirements become more complicated, it has emerged as the dominant approach in the industry.
From Metaphor to Reality
It would be a bit foolhardy to claim that, somehow, feminism is so alive and integrated in the control statements and system architecture powering the digital world that no further engagement is required. Certainly (and if we are to be consistent), gender parity on the actual ground matters most as we improve salary gaps, head counts, and work environments. Something really exciting is happening, slowly but surely.
What I want to know: Could it, somehow, be the case that, in the field of computer science—a landscape in which all possible realities are generated by the interplay of 1’s and 0’s—we are uniquely capable of learning and teaching each other out of the spirit of gender inequality?
Is it possible that, as we develop more and more sophisticated ways to build systems, our approach becomes less and less masculine? When we move toward writing code that is more transparent, reusable, testable, and responsive to the needs of our customers and product owners, are we writing more feminine/feminist code? How differently might the world look when we tell more new-old stories about more balanced metaphorical engagement with the masculine and feminine energies?
Right now, I cannot say. But as a student of feminist epistemology writing code in an Agile software development team, it sure does feel like an awesome time to ask.