This article is actually in favour of anti-discrimination policies. This is about frustrations around poor implementations.
Anti-discrimination policies are like degrees from fake universities: they look good on paper but you wouldn’t want people’s lives to depend on just that.
I have three observations to share:
People don’t believe in discrimination they don’t experience
Stated differently, the obstacles that they can’t experience aren’t seen as discriminatory
Thus the removal of these barriers is deemed unfair, an imposition, and divisive
These beliefs define the lens through which anti-discrimination policies are conceived and implemented. Hence anti-discrimination policies are in virtually every organization and yet little has changed for women or other disproportionately underrepresented groups.
One factor I think is that these policies are about accountability in theory, but in practice are tools to absolve organizations of responsibility. They get introduced in discussions about discrimination as a conversational book end, rather than in their absence creating the space for uncomfortable self-reflection. They often require victims to act as agents of organizational change, which is worse than having no such requirements.
That’s not to say that i think all such policies are worthless. When paired with a lot of unpopular work distributed across the organization, things change. But what I’ve observed is that organisations almost never want to put in that work. They leave it at producing a document and some token gestures. There’s little desire to break some eggs and to be accountable over outcomes.
So then these policies end up being great sounding statements with no real actions to back them. There’s another word to describe documents like that: bullshit.
I carry a lot of privilege. I am a white settler in a country that devalues black and indigenous lives. I am able-bodied in a country that puts barriers for those who are not. I have been perceived as a boy in a country that pushes down girls. I grew up with affluent parents in a country that punishes the children of poor parents. I work as a software developer in an economic system that removes opportunity, diminishes time with close ones, facilitates bad housing situations, denies health care, restricts mobility, and otherwise punishes those in other lines of work. An economic system even more cruel to those without employment. I have been lucky in an environment where that luck is largely determined by privilege.
I’m also a transgender woman. Men shout at me from cars and mock me from the streets. I’ve been assaulted for being visibly trans after a date. I’ve been yelled at in a change room and outside a washroom. I have been harassed walking on a sidewalk, shopping for clothes, getting my brows done, and attending a concert. My family didn’t support me: my sister refused to use my name and pronouns because it would “confuse” her children while my step-dad also refused telling me it would harm my mom. The Globe & Mail and National Post regularly publish op-eds portraying people like me as threats to children, as have politicians and Canadian television personalities. It’s emotionally draining. A quarter of Canadian men are uncomfortable with a trans person moving next door and about half don’t support access to washrooms and these people get to decide if I get hired. I am afraid to use washrooms especially when there are children there. I am afraid to go to the gym or buy underwear.
In short, I experience discrimination. But I also came out as pansexual in 2007 and transitioned in 2013. That matters, because while I’ve endured some violence, it is nothing compared to the losses that have been incurred by those before me. Every trans person I know has been penalized for opening up to the world with those losses diminishing as both the age and year in which they came out increased. My privilege has insulated me from much of that violence. The violence they endured like all violence is self-perpetuating, continuing despite a more accepting world. A more accepting world won’t change the cumulative effects of decades of denied opportunities and poverty. A more accepting world won’t remove trauma from undergoing conversion therapy, being homeless, being sexually assaulted doing sex work, or being fired. It won’t remove criminal records.
But because I experienced discrimination, I thought it was right to take the space created for advocacy in the name of trans people to speak. I gave workshops. I spoke at various events. I lobbied. I participated in a panel on trans health care for a year. I was wrong. I am not sure what is the right amount of space to take, but it is much less than the space I have taken.
My forebears faced the most violence and fought hard to create a place in this world. Their success in turn created greater room for advocacy. That space has become filled with people such as myself, who mistake our own experiences of discrimination as making us qualified to take that space. We are not. Our voices have been elevated above more marginalized voices by design from a system that always prizes those with most privilege. Meanwhile, the pioneers who created that space to advocate aren’t desired in that space because the privilege they lack makes them unpalatable. I have wondered as to the mechanisms that create the transition from advocating for those most on the edges to elevating those closest to assimilation.
I suspect, perhaps, ignorance has been the engine of this shift. Increased acceptance reduced the losses for those with more privilege and helped them preserve that privilege. They then did what those with privilege almost always do – take space and elevate that privilege while ignoring those without it.
I launched http://transphobic.media/ today, a site to let you know if a movie or television show features any transphobia.
It was borne out of me getting really tired of watching a show to relax, only to have a character spit out a joke that mocks trans people. It happens regularly.
“And that lady you European-kissed last night, was actually a gentlemen.” -30 Rock
I had planned to do this for a while, but the turning point was a few weeks ago when I was watching La Mante (The Mantis). The serial killer who is the namesake of the show turns out to be a trans woman, or rather a horrible caricature of one with some of the most transphobic dialog I’ve ever heard. As in 20% of all representation in television shows since 2002, the trans character was cast as a killer/villain.
I started reviewing sources to put together a database. I chose to restrict the titles to anything that appeared in IMDB, so that I could then be able to leverage data on IMDB for later data analysis. Then I integrated it into a website, which took me a few days to do. The site was done using NodeJs, React, Bootstrap, FontAwesome, and Google Fonts. You can download the source code for it here.
If you have any suggestions for titles to add to the database or corrections to existing ones, please do so on the Issues page.
I’ve been a professional software developer for ten years. I have picked up on a few things which I thought I’d share.
People skills
The most important skill in software development has nothing to do with the code itself. It has to do with how you treat other people.
This touches everything from the type of comments in a pull request, to whether individuals are faulted for mistakes instead of addressing systemic issues, to a sense of safety to ask questions, to being able to listen to other people’s input, to making sure remote employees don’t feel left out, to how you deal with assholes and sexual harassment.
Never badmouth others
Never badmouth people on your team. Never badmouth people on other teams. Never badmouth other teams. You are all on the same side, trying to give the best product to the client.
Don’t do overtime
Except on rare occasions. The most important thing in your life is your health and the time you spend with those you love. Those things are fragile. Don’t take them for granted.
Interview interviewers
Interviews go both ways. You want to make sure the company is a good fit for you too, not just the other way around. What’s the percentage of women in technical positions? What do they use for testing? How do they do CI?
Welcome discomfort
Whatever you know now will become obsolete at a rate that is faster than any other science. Entire stacks change in years. If you want to stay competitive in this job market, you will need to constantly be uncomfortable and learn something new. Play with the stacks used at young and popular start-ups.
It’s legacy from the start
Every project you work on will become legacy. Legacy apps often require old tool-chains and are difficult to maintain. This is preventable to a point. I’ve found it helpful to view projects from their inception onward as legacy and keeping tabs on how hard it would be to modernize.
I’m a big fan of simple, independent, applications with well-defined interfaces. I’m also a fan of avoiding reinventing the wheel. You want to go with the simplest design with a focus on making it refactorable. Following the advice of books like Clean Code by Robert Martin help tremendously. Prize unremarkable code.
Technical debt accrues at a pace that is hard to notice day to day. Take metrics to make that more evident, such as line of code per source file limits (with flexibility) and architectural reviews oriented towards cognitive simplicity.
Old isn’t always worse
There’s a tendency to want to refactor projects to adopt the latest language, framework, hardware, etc. While it’s important to stay current, it’s equally important to grasp of the benefits of the established tech. Adopting the latest isn’t always the greatest depending on the needs of the project.
Everything as code
There should be no manual steps anywhere to get from code to deployment in prod. Your server and networking infrastructure should be code. Your tests should be code. Your embedded environment build process should be code. If you need to follow a guide that involves following a series of steps: that should be automated. Deterministic all the way.
Check your assumptions
You will make assumptions for every line of code you write. That’s okay, but it’s also important to sometimes step back and ask yourself if this is an assumption that needs validation.
If users can, they will
If users can do a thing, they will do the thing. It doesn’t matter if it doesn’t make sense to you to do that. So if you don’t want them to do it, put that in code. This extends to APIs as well.
Use the tools
For new developers, learn to use the tools that you hear about. Use an IDE. Use a debugger and learn to set breakpoints. Use a code versioning tool like Git. Implement unit tests. Learn about contemporary software methodologies like Agile and what problems they address. If you’re new, the benefits of these things will likely seem elusive to you and you’re liable to believe that they’re more pain than they’re worth. So trust my words: it’s worth it.
Today I’m proud to show off a short work of interactive fiction that I wrote, about being trans in Ottawa. You can play through the story by clicking here.
In the rest of this post, I’ll talk a bit about the process behind the creation of this game.
Four Stages
From the outset, I realized that I wanted to create my own interactive fiction engine, that is to say, my own tools to create works interactive fiction. I did this because I thought it would be quicker to write my own than learning to become proficient in someone else’s, and because I had the ultimate goal of making the works I produced available online. I thought it would be easier to accomplish the latter if I didn’t have to work with someone else’s tools.
This would be the second interactive fiction engine I created. I used lessons I learned from my first go at it, Story Creator. Story Creator was designed to be easy to learn, but wasn’t scalable – writing longer and more complex stories became unmanageable.
If I wanted to create this work, I needed to follow four steps:
Design a scripting language with which to create stories.
Put together an interactive fiction engine that could turn those stories into playable games.
Create a tool that would use the interactive fiction engine, and create a website through which people could play the game.
Write the work of interactive fiction I had intended.
Creating the Scripting Language
I set out to create a scripting language – a way to formulate stories that a computer could understand as to make playable experiences. I spent a week or two writing tidbits of code on paper, imagining how a story could be written. This was a really fun challenge for me.
I realised that these stories, much like computer programs, could be boiled down into two fundamental ingredients: state machines and the means to move between them.
Everything in a story can be reduced to a state. The location of a player (bottom left) or a conversation with a character in the story (bottom right).
State machine representing a player’s location.
State machine representing a conversation tree.
In the case of a work of interactive fiction, each state can have text associated with it. If the player is in a bedroom, then there can be text specific to that, talking about the bed and so forth. If the player is in a different location, say, a washroom, the text can be different, talking about the sink and tub.
The other fundamental ingredient, actions, change the state of these state machines. These actions can have different names depending on the state machine. For changing the location, the action could be called walking. For navigating a conversation tree it could be called speaking. The name is irrelevant. They all do the same thing: change state machines from one value to another.
With that in mind, I separated the scripting of these stories into two: entities which would contain the state machines, and actions to change their state. The state machines would be defined using a graph description language called dot.
In them, only the states of a state machine would be defined and how the states went from one to another.
For the text to display with each state, I used a lightweight markup language called Markdown.
# location
## house
### bedroom
You are in the bedroom. It hasn't changed since your childhood. Your pink
bed sheets. The blue walls. Your plush animals. Your polly pocket and
transformers lining the shelves. Traces of your teenage self - the boxes
of video games you kept perfectly. The computer you built, and rebuilt.
An entire life that suddenly stops midway through university.
### bathroom
You are in the bathroom.
### entrance
You are at the entrance.
Then for anything else related to the state machine, such as what initial state the state machine should be in, and what actions apply to the state machine, YAML was used.
location:
value: bedroom
actions: [walk]
Actions were also written in YAML. The idea was to trigger a change in state, to a specified value, by pattern matching against the sentences written by a player.
action: change
templates:
- walk to the @value
- walk to @value
- walk the @value
- walk @value
synonyms:
walk:
- travel
- go
- head
- enter
The scripting language I designed on paper only received minor alterations during the implementation.
Writing the Engine
Writing the engine took place over the course of many months; I wrote about my efforts here when I was done. The task was broken into four parts:
The first was creating a compiler which would take works of interactive fiction written in the scripting language defined earlier and turn it into state machines it could use.
The second part was creating an engine which took the state machines and changed their state according to what the player wrote to advance the story.
The third was creating a command-line tool that could act as a front-end for the compiler and engine.
The fourth was documenting everything including how to write stories and all the parts of the engine. There’s no way I’d remember all the details in six months.
In reality, all parts took place more or less simultaneously. I put together short works of interactive fiction, which I would pass through the compiler/engine using the command-line tool to test.
I was very pleased with the end result. You could write simple sentences, and the engine would understand it, or present alternatives that it thought it understood.
Writing the Web Tool
Command-lines like that above were very convenient to me, as a software developer who enjoys retro experiences, but inaccessible to most people. If I wanted to create something other people could experience, I needed to put it online, and I needed to remove the part where people could write sentences in plain English. I created a tool that made websites for the interactive fiction, so that the only thing someone needed to play them was a web browser.
This portion only took a week to do. The majority of the work had already been done when I created the engine. Meanwhile creating simple dynamic websites was easy with React, Bootstrap and Gulp. I wrote the code to combine the two.
Creating the Interactive Fiction
With tools in hand, I set out to create the work of interactive fiction. I had wanted to do a story about being trans in Ottawa. I wanted to show how transphobia was embedded in the everyday – whether walking down a sidewalk, going into a shop, reading a newspaper or using the washroom. I also wanted to show other aspects, including queer spaces and friendships.
The story I ended up doing was about a life in a day in Ottawa. The protagonist starts off in their apartment bedroom, and is able to explore the city. Main Ottawa streets like Bank, Somerset, Wellington, Rideau, King Edward, etc. are here. So too are places like the Byward Market, shopping center, etc. The player is tasked with three objectives: get a coffee, go for a laser hair removal session, and attend a potluck.
I’m very pleased with the final product. Though most of the content will go unread by a casual player, there are many random events, four characters that can be conversed with, and perhaps a slightly different view of the city.
Feel free to give it a go yourself! The playable story is found here.
The code for the story, in the scripting language I created, is found here.
