Works on my machine, or Problem exists between Keyboard and Chair
Trigger Warning (for video and content below): Includes mention of harassment, misogyny, transphobia, homophobia, racism, sexism, rape and death threats, and abuse.
Hi, my name is Lena Reinhard. I’m a team leader, consultant, writer, and photographer, and if you’re on twitter, my user name is @lrnrd.
And today, I want to talk to you about software bugs.
Raise your hands:
- Who of you here is a software developer?
- Who of you likes software with bugs?
- And who of you enjoys the moment when you’ve fixed a bug, and your code works again?
So, bug fixing. What are bugs? Software bugs are errors, flaws or failures in software that cause the software to produce incorrect, undesired or unexpected results. A bug can be many things – like a system error, a performance problem, configuration issue, or an issue with functionality.
(Gif – Source: Cartoon Network)
At all points in the the development cycle, we can end up with bugs in our software or systems. So we need to debug it, we need to find and resolve these defects.
But Debugging can be hard, and it becomes even harder the more complex our software becomes.
In debugging, one of the most interesting (and difficult) challenges is spaghetti code. Spaghetti code is slang for code that’s unnecessarily complex, convoluted and difficult to read or follow by a human. – Just like it’s difficult to follow one single piece of spaghetti when you have a pasta mountain on your plate.
Spaghetti code can be code that’s not organised, uses lots of GOTO statements, has many interdependencies, or jumps around between different areas or files. It has often grown over many years, and many people have worked on it. And – it’s very difficult to debug.
As people in tech, we’re used to bugs in our software – they’re part of our daily lives. But there’s another system that’s part of our lives as people in tech – another system that contains bugs:
the tech industry itself.
In this talk, I’ll show you ways in which this industry is buggy, why we should care about that, and how to debug it.
The tech industry is a lot like a big system of spaghetti code: it has grown over time, and many people have contributed to it. It’s also a system that consists of many different intertwined parts with dependencies. And it’s an important system with huge impact – it’s still one of the fastest growing industries globally, and technology – or lack thereof – influences the daily lives of many people worldwide. This is why we need to look at this industry and its effects.
To understand a system, it helps to understand its parts. So let’s look at which parts define the tech industry as a system. I’ve created a simplified venn diagram to show them to you.
The tech industry as a system (and its parts)
First of all, you can see society. Much like software systems don’t exist in isolation, the
tech industry itself also belongs to something larger.
Part of the tech industry are communities – like FLOSS or Free, Libre and Open Source software communities, or local tech communities.
Then we have companies. Some companies or the people in them are part of communities, so we have an overlap here.
And finally, there are humans, and here you can see one of us. This is me, and this is you.
Some of us work at companies, some of us are part of communities, all of us are in some way in tech. – And all these parts together influence this industry.
One of the most common problems in handling bugs is the misconception of what constitutes a bug: the classic question “Is it really a bug, or is it a feature?” – When debugging software systems, we bring our own, personal and technical skills, preferences, knowledge, and limitations.
So when we want to understand how these different parts we’ve looked at influence the tech industry, we need to understand ourselves first – our own skills, abilities, and limitations.
Some of us can exist in our society with ease and gain influence – which gives us advantages relative to other people: we have privilege. Privilege comes from various factors, like our gender, race, class, education, upbringing, ability, appearance, physical and mental health and many more.
Privilege is a shield that protects us from problems, and it blocks parts of our perception.
Privilege is like being in your cozy, sunny home over here, reading a book, and not even noticing…
that a thunderstorm is about to happen around you – a thunderstorm that could cost the people outside their lives.
Privilege in tech is: when you can attend a conference party without fear that someone will harass you. When you can have drinks with colleagues every other night because you don’t have to take care of your child or elderly relatives at home.
Privilege in tech is when you can stand in the daily standup meeting and don’t have to sit because of a disability or illness. And when you can publish a post about a framework without getting rape or death threats in return.
Privilege is a classic example of “but it works on my machine” or “it works in my life” – it puts us in a position where we don’t see problems in tech, because we’re not personally affected by them – a position where we don’t even have to think about the fact that not all machines and lives are the same. Privilege is a comfortable position of ignorance.
And we have to actively work through our privileges – to make sure we see more than our tiny portion of the world, and to understand what the tech industry really looks like.
Another factor that limits our perception are Biases. Every moment, our brains receive 11 Million pieces of information – but we can only process 40 of them with our conscious. Biases are assumptions that we use to deal with this huge amount of information in our subconscious, and biases are attached to the idea that we can judge something by looking at it. They’re based on our past knowledge, experiences and cultural norms.
Biases are great for seeing: there’s an animal. It has four legs, lots of hair, it’s light brown, and it’s not a dog or a cat – this is a lion, I should run. But Biases are not good for judging people – but we use them for it. And we even think we’re being objective when we’re just biased.
Our biases lead to unfair preferences: women earn less money for the exact same job than men do. Candidates who are interviewed on sunny days have a better chance of being hired than candidates interviewed on rainy days. And tall men move into leadership positions more frequently than shorter men.
We all have these biases. Understanding in which ways we’re biased can help us understand the status of tech better – and how we’re personally contributing to it.
An extremely important skill all of us need is empathy. Empathy is the ability to relate to another person as though they were us.
It’s a powerful skill that enables us to think of the consequences of our words and actions on real humans. As people working on software, empathy is our responsibility. And we need it to understand the status of the tech industry.
As we’ve seen up to now, Understanding our privileges, working through our biases and practicing empathy helps us understand the status of our system.
A systems Diagnosis
Now let’s use this knowledge to run a systems diagnosis of the tech industry and its parts.
The smallest entity in this system is one human, and we’ve talked about ourselves already – about our privileges, biases, and lack of empathy. Next up, we have
one company. Conway’s Law says that the systems which are designed in organisations are copies of the communication structures in these organisations. This means that our company structures will directly influence the software we build – whether we’re aware of it or not.
So what do the structures in our organisations look like?
Most European tech companies consist mostly of cis white men, and cis means that a person’s experience of their own gender matches the sex they were assigned at birth.
In Europe, less than 30% of employees in tech are women, and less than 10% work as software developers. So more than 90% of software developers in Europe are cis white men. And we don’t even have data on other aspects of humanity – we don’t even have numbers on how many people of colour, lesbian, gay, bisexual, queer, non-binary, intersexual people, or disabled people work in tech here. And these are just examples of many groups that are currently hugely underrepresented in the tech industry.
What we have are homogeneous organisations. We have a huge lack of diversity in ethnicities, genders, backgrounds, education, upbringing, life experiences, ages, languages, ideas, abilities and disabilities, and more.
Creativity is an important driver for good design and engineering – but our ability to be creative as teams depends on exactly these factors. This is one of the reasons why our lack of diversity is so harmful: it even blocks our ability to be truly creative as designers and engineers.
We all live in diverse societies – but our organisations don’t reflect that. The products we build in these homogeneous organisations just don’t work for our diverse population – which even makes many of our products completely unusable for so many people.
Thing is: even if tech companies manage to hire a diverse workforce – most of the times, they don’t keep them. 41 percent of women leave careers in technology after 10 years, that’s more than twice the number of men.
The reason for such bad retention rates is that our companies fail at inclusion.
Inclusion means that all individuals in a group are being valued, respected and supported, and it means facilitating cultures, practices and relationships to support a diverse workforce.
Right now, it’s hard getting members of underrepresented groups into tech, since it’s such a hostile environment. And as soon as they are in, we largely drive these skilled experts out again in a very short time – because we don’t really care about them.
This goes for our companies – and also goes for our
Communities. The lack of diversity and inclusion in our communities is even worse than in average companies. 85 to 95 percent of all Free, Libre and Open Source software contributors are men. They’re also mostly white, and most of them are software developers – very few people with other professions and expertise contribute to these projects.
And since these contributions are mostly expected to be done by people in their spare time, everyone who has other obligations like caring for children or other people is excluded. And most projects are neither accessible nor welcoming for beginners.
Another big issue in communities is harassment. There are hundreds of reports on harassment, misogyny, transphobia, homophobia, racism, threats, sexism, and abuse that people have experienced in Free, Libre, and Open Source Software communities and at events.
[If you don’t believe there’s harassment in tech / communities, here’s a small overview and timeline of *big, public* incidents. ]
Our tech communities are a completely unsafe space for underrepresented groups in tech.
And on top of all of that, our societies influence us and the tech industry.
We live in patriarchy, a social construct in which cis men hold most of the power. Patriarchy enforces gender roles and is oppressive on humans.
Our societies are also capitalist systems that have led to wealth and income inequalities. And we live in racist societies that center upon the false belief that white people are superior to people of other racial backgrounds.
Together, patriarchy, capitalism and racism have led to oppressive systems. These systems are big influencers on ourselves, our beliefs and our work in tech.
We’ve now only looked at all these parts isolated from each other. But a system is more than just the sum of its parts. All parts that influence the tech industry are intertwined, and accumulate characteristics of the other parts – which has made many of them even worse.
As a system, the tech industry is a place full of privilege, biases, that lacks empathy, diversity, inclusion, is full of harassment, and is shaped by patriarchy, capitalism, and racism.
So, how do we handle this?
Looking at the system output
When we want to understand and debug an unfamiliar system, it helps to play around with variables and see how they affect the output. One of the outputs of the tech industry as a system is the software we build. So let’s see what this output looks like.
Software can have positive impact on people’s lives:
Software can help satisfy our basic human needs for safety, belonging, and self-actualisation, e.g. by helping us communicate with others through applications, or by making information and communication tools accessible for people through screen readers.
Software like the application “Be my Eyes” can also help visually impaired people get help with certain tasks. And some software can also help people with mental or physical illnesses improve their situation through online self-help programs.
But software can also cause a lot of harm – and it can even endanger people’s lives.
Our software is sexist: When virtual assistants like Apple’s Siri, Google Now and Microsoft Cortana are told that a user had a heart attack, they redirect them to help. – But none of these assistants has been programmed to recognise what it means when a user says that they’re being abused – which affects 1 in 3 women worldwide.
Our software is racist: Face recognition algorithms and camera sensors keep on failing to recognise the faces of people of color correctly.
Our software worsens issues in societies: Vacation rental and accommodation sharing Sites like AirBnB are contributing to a growing housing crisis in cities like New York, London, and Berlin, by removing rental stock from already tight housing markets.
Our software exposes people to harassment and abuse: Major tech companies like Twitter and Facebook have been failing to address the harassment issues on their platforms for years – which has made these important technologies completely unusable and even dangerous for many people.
Our software puts people at risk: On a regular basis, we expose users to dangers through security flaws, and we’ve built tools that have enabled personal data to be exposed online – which has put people’s personal safety at stake. And Car dispatch startups like Uber keep on not doing anything to ensure passengers’ safety in the cars, despite several cases of assault against passengers.
Our Software is actively making people sick: The animations in our operating systems, apps and websites can trigger panic attacks and dizziness for many people. And software has helped cars emit more pollution on the road than in regulatory tests – pollution that is making people sick.
This is the output of the tech industry as a system. We’re part of this system, and this is what our work does to people.
And even if the software you’re working on right now may feel like a good project and you feel like it doesn’t do any harm: you need to care about that as well.
What we need to understand is that, as people in tech, we have a collective responsibility. We keep pretending that the technology we build is neutral. We still believe that we can be apolitical as people in tech. We keep pretending that our algorithms are neutral. We don’t care about ethical aspects of our work. And most of us are in a position where we don’t *have to* care. But it’s our responsibility to understand: Technology is not neutral, our code is not neutral. Our work is political. And our work has consequences on actual lives.
What we have right now is a completely broken system. Right now, this industry is a system built on privilege by privileged people for privileged people. This system works for cis white men inside and outside of this industry, but for almost no one else.
Right now, we’re failing many underrepresented people inside of this industry – and this system can’t generate meaningful output. We’re failing to build real solutions for our software users’ actual problems.
This is why we need to change this industry’s inner mechanisms and its output to something meaningful. We need to debug it.
Where debugging the Tech Industry happens
But who is “we”?
As we’ve seen, one reason for this industry’s problems exists between keyboard and chair – and this time, it’s not our users:
This time, it’s us. As humans, we are contributing to the status of this industry.
But: we’re also part of the solution for these problems.
Here’s why: If you look closely at this venn diagram again,
you’ll see that there’s one spot where all parts overlap.
This one spot with one person who’s in tech – as part of a team, or a community, or by themselves. This person is you.
This place, right where you are: this is where debugging the tech industry happens.
Everyone of us has this area where we can fix things. Everyone of us is part of something bigger: we’re working at companies, some of us are part of communities, we know other people in this industry.
Whatever you do in tech: you have such an area.
The sizes of our areas differ: The more privilege and power we have, the bigger our area is in which we can make this change happen – and the more it is our responsibility to debug this industry.
But what we experience right now as an industry is another case of “it works on my machine, so your problem isn’t real”:
Right now, many areas for change go unused – because many of us don’t know or don’t care about the brokenness of this system. Because the system works for us, and we benefit from the status quo.
Right now, most of the people who are already working on debugging this industry are members of underrepresented groups in tech. That’s a bit like telling the QA team in your company that they have to fix the bugs they find themselves, because you have better things to do.
But it’s the responsibility of all of us to help debug the tech industry. It’s my responsibility, and it’s your responsibility.
Change starts in this area. Change starts with me. Change starts with you.
11 Steps to Debug the Tech Industry
In the next minutes, I’ll show you 11 debugging tools and techniques that you can use to support the debugging process in the tech industry.
Debugging starts with ourselves, and the basis for all debugging work is step 1: learning. We need to educate ourselves and learn about systemic issues and oppression in tech. There are many great resources online that can help you understand these problems.
It’s not the responsibility of others to educate us.
Learning about debugging this industry is our personal responsibility.
[Since I got asked after the presentation: fantastic resources and great starting points for educating yourself are 1. Model View Culture who even have a list of resources for different topics (and you should get a digital or print subscription!), and 2. Geek Feminism Wiki, e.g. its Resources for Allies.]
We need to practice empathy. Empathy and *actually* caring about other people is a choice, and a skill we can improve. We need to understand that not everyone is like us, and understand that the life experiences of people who are different from us are just as valid as our own.
Empathy also means understanding that our software is a personal experience for our users. All expressions and interactions we build in our software are choices that affect the way our users feel. WE CAN’T BE GOOD DESIGNERS AND SOFTWARE DEVELOPERS IF WE DON’T WORK ON OUR EMPATHY.
Step 3 is to understand our position in the world. As people in tech, we have power. The tech industry has turned this notion of power into a culture of celebrating so-called “coder ninjas”, “rockstars”, and “unicorns”.
Well… we’re not. None of us are ninjas, rock stars, or unicorns. All of us are humans, and all of us fail. This should fill us with humbleness and awareness of our own limitations – and should have us work on our humility.
Step 4 is understanding our privileges. We need to understand how our position in the world has been shaped in terms of privilege and race, and in which ways we benefit from the existing systems around us. This can be a chance for us to learn which mistakes we’ve made in the past, and how we can prevent these mistakes in the future.
We also need to use our privileges for good: work on ourselves, and set positive examples for our peers.
We need to work through our biases. We need to be conscious about our past, present and future self, and be deliberate about our actions and interactions with people.
Practically, this also means being deliberate about the software we build – and making sure that the software is not only appealing to people who are like us. Every app icon matters, and every image matters.
Companies, and communities need to put policies in place to work through biases and avoid basing our work on assumptions about the people we work with, and about the users of our software.
We need to listen to what underrepresented people in tech have to say. We need to follow them on Twitter, read their blogs and other publications, and look outside our existing networks. We need to actively look for the voices we haven’t heard before.
– and we need to amplify these voices: the voices of people whose stories often remain unheard, to help them reach broader audiences.
Amplifying others’ voices also means speaking less. There’s no need to comment on everything that underrepresented people in tech are sharing. Listen.
We all need to work on diversity. First and foremost, diversity is our moral obligation. It’s the only way to do software development right – the only way to do right by the people in tech, and by our software users.
Diversity also enables us to build products that are actually useful for people.
It also allows us to solve complex problems better and faster, be more creative, make better decisions and generate more innovation. Companies with diverse leadership have better sales revenue, more customers, higher market share, and higher profits than their competitors. Diversity also helps companies with hiring, learning, leads to better software and happier customers.
And still: Diversity is our obligation. It’s the only way to do software right. There’s no alternative.
And there’s no alternative to inclusion either.
We need to work on inclusion in our workplaces and communities: we need to foster environments in which diverse groups of people can thrive. It’s our responsibility as privileged people to facilitate spaces in which underrepresented people WANT TO be.
We need policies for equality and social conduct, and we need to communicate openly about our values. We need to do everything to make spaces welcoming and safe for *everyone*.
Our efforts that go into inclusion show how much we *actually* care about diversity. 2810
We need to give: give our knowledge, technical skills, time and money to groups or individuals in this industry who are in need of support. We can become coaches at meetups, or become mentors.
And each of us needs to work on being an ally to underrepresented groups in tech. Being an ally means supporting them – by following the 10 aforementioned steps: by educating ourselves, practicing empathy, working on our humility, working through our privileges and biases, listening, amplifying their voices, working on diversity and inclusion, and by giving. –
And by continuing to learn and work on ourselves. Being an ally is ongoing work. As allies, we can support the people who are fighting to debug this industry.
This is what we need to do. And we need to do it now.
The code we’re writing today will soon be obsolete. The software we’re building today will already be outdated in a few weeks. The bugs we’re producing today will be fixed, and the features we build today will change again.
What we have now is a chance to build something bigger, something that lasts: What we have now is the chance to debug the tech industry – and make it a better system that is about justice and equality.
This debugging is already happening, and it can’t be stopped. It is the biggest challenge and the biggest task we have as people in tech right now. Now is the time for us to debug this industry and make technology a place for everyone. This is our chance to build our own legacy. This change starts with all of us. It starts with me. It starts with you.
Problem exists between keyboard and chair. Solution exists between keyboard and chair.
And the question is: now that we are debugging the tech industry – –