Blog‎ > ‎

Debugging Diversity

posted Jul 7, 2015, 2:05 PM by Anjuan Simmons   [ updated Jul 9, 2015, 12:39 PM ]
Diversity is Elementary

For the past fifteen years, it has been my honor to work with amazing teams to get working software into the hands of users. I love shipping software, and technology is a big part of who I am. However, there is something that supersedes even my identity as a technologist. And that is my identity as a father.


simmons_familymy_daughter


I am the father of three kids ages 10, 9, and 7. The two oldest are boys, and my youngest is a girl. While I love all of my children, my daughter has a special place in my heart. I adore her smile that shines when she laughs, the way her eyes widen when she makes a joke (she is hilarious!), and the many ways that my wife braids her curly hair. She is involved in many activities like ballet, soccer, and piano, but, like any Geek Dad, I am especially interested in her schooling. She always earns high marks in school and brings home arts and crafts that I always think are remarkable for a first grader.


A few months ago, my wife let me know that she wanted to talk to me about something that occurred to my daughter in her first grade class. I came home wondering if she had won another award or perhaps learned to spell a new word. After all, I think she will be killer some day at the Scripps National Spelling Bee. However, the news my wife had to share about my daughter was unexpected, but, unfortunately, not surprising. My daughter is the only Black student in her first grade class. She and the other students in her class were given an assignment to draw a picture of their families. My daughter started her project and drew a picture of her two brothers, my wife, and me. However, one of her fellow students saw her picture and said, “You drew your Dad wrong. He should be holding a gun with a bunch of dead bodies around him. Because he’s Black.” This was not the first time my wife and I were put in a position to address the Black experience of our kids as they navigate through mostly White schools. I am sure that it will not be the last.


The Perceptions Game


I share this experience with you because diversity in technology is often presented as a numbers game. Huge companies like Google, Facebook, Yahoo, Linkedin, and others jump-started the conversation about diversity in tech a couple of years ago by publishing their diversity numbers. However, while numbers are necessary, they are insufficient to fully solve the diversity problem in tech. In fact many of you probably saw the published diversity numbers and wondered what they had to do with you? After all, you're just a developer or a system admin or a software project manager.  Furthermore, you've never engaged in the racist or sexist behavior that are hinted at by the numbers. You have never used the N-Word, you have never killed people at a church simply because of their skin color, you have never groped a woman in a bar. And, you're right, those behaviors are horrible, and I'm glad no one here is guilty of them. However, my daughter's first grade classmate also never did any of those things, but her actions were still destructive. And her actions were driven by her perceptions. Diversity is not primarily a numbers game. It is primarily a perceptions game. And these perceptions are easy to understand. You don’t have to be much smarter than a first grader to get them.


It was somewhat fitting that I presented the ideas in this article at CodeConf 2015 in Nashville, the capital of Tennessee which was the last state to secede from the Union. Alexander Stephens, the Vice President of the Confederacy, which included this state and my home state of Texas said these words shortly before the Civil War began about the new nation the had been created by the Southern States:


“...its foundations are laid, its cornerstone rests, upon the great truth that the negro is not equal to the white man; that slavery, subordination to the superior race, is his natural and normal condition.”

Although the Confederacy ended more than a century ago, the perceptions that Stephens shared in his speech still linger. While the violence of the Civil War has ended, we are still subject to the damage of those perceptions. While it is easy to see how damaging these perceptions are when acts of violence are reported in the news, the subtle ways in which they affect our society are far more destructive. While flags can be removed from state buildings and statues torn done, the perceptions that drive inequality are much more difficult to destroy.  


Furthermore, I believe that the technology sector is more vulnerable to the pain caused by a lack of diversity precisely because we think that we’re different. “Talk is cheap, show me the code!”, right?


However, we are not different. We are not immune. Yet, we are positioned to solve our diversity problems in ways that people in other industries are not. This is especially true for software developers. I’ve developed enterprise software for almost two decades, and I’ve seen the structured thinking and problem solving skills required to be successful. I challenge all of you to think of the technology field as a software system and the lack of diversity as bugs in the system. By thinking this way, you will see that that you already have what it takes to not only understand our diversity problem but also to know your role in debugging diversity in tech.The Diversity Debugging Tools are based on the code debugging techniques of Expected Behavior, Tracing, Refactoring, and Sample Code.


Expected Behavior


Let’s start with the Principle of Expected Behavior. I’m the Scrum Master for a team that is trying to get a release out, and we are dealing with a lot of bugs. So, debugging is fresh on my mind as we try to harden our product. In fact I'm seeing bugs everywhere. When I'm checking out at the grocery store, I see bugs in that horrible experience. Seeing bugs everywhere can get me in trouble, though. I've been married  for 13 years, but a lot of my buddies have divorced and are dating much younger women. So, when they introduce me to them, and I see the bugs in that situation? I have to keep telling myself,  "Defer to the next release, defer to the next release!"


But, back to my team.  As we fix the defects reported by our QA team, we often have to remember that the first step in understanding a bug is knowing the expected behavior of the feature. Likewise, The first debugging principle we can apply to fixing the diversity defects in technology is the Principle of Expected Behavior. We cannot understand the problems caused by a lack of diversity in tech without knowing the expected behavior of technology environments. Whether it's a workplace, conference, or happy hour, most White males in technology understand and benefit from the behavior patterns they expect from others. However, they often fail to see how underrepresented groups are often denied those benefits.


I have a friend who is the  founder of a successful startup called The Muse. Kathryn has shared an experience that I’ve heard echoed by many women in technology at all levels. She goes to a happy hour where a bunch of tech founders are having drinks. Someone turns to her and asks, “So, which one is your boyfriend?” Now, raise your hand if you are a White male who has been mistaken for someone’s boyfriend at a happy hour?


People of Color, women, and LGBT people are exposed on an almost daily basis to behavior that the majority of people in tech would never expect. The ability to see these lapses in expected behavior is vital to helping the technology sector understand that the key problem behind diversity is a lack of inclusiveness.


Tracing


Here’s the second Principle of Debugging diversity in tech. <tracing> Since software programs are often very complicated, debugging them is often made easier by seeing the output of the underlying code. This is done by tracing which is the practice of displaying output as the program runs. Just as you can trace code to detect small defects in it, you can turn on your diversity tracers and see the often subtle ways that underrepresented groups are often excluded from information and exposed to micro-aggressions by the dominant demographic.


I know someone who is a Woman of Color who shared her experiences as the only Black person on an IT team at a large and well known tech company. She has shared her experience of working with a White co-worker who had ridiculous stereotypes about Black people. He assumed that she was abused by her parents as a child and by her then boyfriend. It’s amazing that someone who abused her was fascinated with her fictitious history of abuse. At other tech jobs she was often compelled to join the team at beer taverns despite not liking beer, learn classic rock songs, a genre that she did not care for, so that she could play Rock Band with her colleagues, and was often mistaken by those new to the office for an administrative assistant or security. Her experience is the norm for People of Color in tech. We all too often have to lose our lives to earn a living.


If someone had their diversity tracers on, they could have spotted this. For example, why assume that everyone wants to drink alcohol? Even if the majority of the team loves drinking, be sensitive to those who do not. Everyone here can step through the cultural code of your workplace and see if anyone is being hurt by it. You simply need the willingness to pay attention.


Refactoring


Let’s turn to the Principle of Refactoring. While the allure of adding new features can be powerful, legacy code is made easier to maintain and less costly to develop by refactoring. This is the practice of restructuring and improving the internal design of code without changing the external functionality of the system. Diversity refactoring is a good way for technologists to begin making the technology industry a more inclusive one. This is the process of improving the internal structure and design of how underrepresented groups are viewed in tech.


Let me give you an example of how to refactor diversity. A few years ago a famous founder of a giant technology company stated that he uses the “airport test” during interviews as one way to determine if a candidate should be hired. The airport test is applied by asking yourself if you would want to be stuck in an airport with the candidate. Due to the visibility of the founder who described the airport test, it became a popular part of the selection process at many tech companies. However, it is a terrible way to hire people, especially if you want a diverse workplace.


First, how does a hiring manager’s personal tastes determine if someone is fit to perform a job? Second, the airport test is meant to determine if a candidate fits the “culture” of the organization. Well, if the culture is composed of all White males, then guess what groups are most at risk when it comes to failing the airport test? After all, how many hiring managers have been stuck at an airport with a Black person? Or, a female co-worker? The airport test is a way to perpetuate a non-diverse workplace.


So, let’s refactor the airport test into the workplace test. Instead of wondering if the candidate would be someone you wouldn’t mind being stuck at an airport with, ask how they have solved problems at other workplaces. How have they reduced the amount of bugs that are reported after a release? What are some good practices for introducing a new developer to the team? How can developers better understand the end users for whom they are building software? The workplace test takes the “I” out of the selection process put there by the airport test and replaces it with the needs of your company. Stop trying to hire cultural rockstars. Make your company the Rockstar by making it more inclusive.


Sample Code


Finally, there is the Principle of Sample Code. One way to debug code is to see a sample of similar code that runs well. Essentially, another programmer "lends" you code that helps you fix or prevent defects. This can be production code or code that exists in a local branch.


Just as a person can "lend" code to another person, you can "lend" privilege to someone else. This is the diversity debugging principle of Sample Code. You can use this principle by helping underrepresented groups get access to information and events that naturally flow to the dominant demographic in most technology companies. So, men at technology companies, you can help women by letting them know about the golf outing next weekend that the guys talked about while playing pick up basketball during lunch. You can also, when a group of men are discussing a topic and you notice that a woman, who knows the topic well, is being ignored, say, “I’d like to hear what . . . “ she has to say.


I did this a couple of years ago when I was putting together a panel for South by Southwest Interactive. Getting a panel accepted into South by is an extremely competitive process. I had successfully done so three times in previous years so I knew the components of a great panel. One key factor is the quality of the people you list in your proposal. I had several men in mind with high profiles in tech. However, I knew a UX designer based in Mexico, and, since my proposal was about design, I decided to team with her for our dual panel proposal. It was a risk because she was far less well known than the men I could have selected. However, as someone with male privilege who had previously spoken at South By several times, I wanted to lend her some of my privilege as a speaker at South By. Our panel was accepted, and she gained a credential that helped her get her own panel accepted the following year and also fuel her own startup journey. You’d be surprised how useful it is for a female startup founder from Mexico to introduce herself to tell male investors as a speaker at South by Southwest.


Call to Action


I hope you have seen how you are already empowered to debug diversity in tech. The question is, “What will you do with your power?” I have a suggestion. When the treatment of marginalized groups in tech is discussed, it is often done in silos. Women talk with women, people of color talk with other people of color, LGBT technologists with other LGBT technologists. Why don’t these conversations ever happen by those with privilege? So, all of you can start by taking one aspect of your privilege and finding someone with that privilege and having an open and honest conversations about your perceptions of people who lack your shared privilege. Men, get with other men and discuss topics like GamerGate. Straight people, get with other straight people and talk about gay marriage. Use the diversity debugging techniques I just shared like Expected Values or Refactoring.


Think of these conversations as diversity pull requests. <pull requests> Like most pull requests, they represent how you your thinking has diverged from how diversity in tech is thought about in the main and your desire for others to consider your changes. Perceptions only change if you're willing to interrogate the reality of your shared privileged experiences.


So, those are your diversity pull requests. Use them wisely.