Here is the abstract for the session that I proposed for GitHub's 2015 CodeCong:
Despite the media attention given to the diversity in tech problem, many technology practitioners don't see how a lack of diversity affects their daily life. So, it is not surprising that they neither understand the magnitude of the problem nor how they can fix it.
However, the principles and language of debugging, something technology practitioners understand well, can be used to help them understand diversity and their role in solving the problem. So, technologists already have a set of terms that they can use to tackle diversity. They just need to know how to apply those terms in order to effect positive change. These terms are expected behavior, tracing, refactoring, sample code, and debug='false'.
The first step in understanding a bug in knowing the expected behavior of the system. Similarly, understanding diversity is impossible without knowing the expected behavior of technology environments. Whether it's a workplace, conference, or happy hour, the dominant demographic in technology understands and benefits from the behavior patterns they expect from others. However, they often fail to see how underrepresented groups are often denied those benefits. The ability to see these lapses in expected behavior is vital to helping the dominant demographic understand that the key problem behind diversity is a lack of inclusiveness.
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 lines of code as the program runs. If technologists turn their diversity tracers on, they can see the ways that underrepresented groups are often excluded from information and often exposed to micro-aggressions by the dominant demographic.
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 disrupting the 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.
One way to debug code is to see a sample of similar code that runs well. Essentially, another programmer "lends" you code that helps your code work better. Just as a person can "lend" code to another person, a person can "lend" privilege to another person. This can be done by helping underrepresented groups get access to information and events that naturally flow to the dominant demographic in most technology companies.
Most languages come with a debugger that should be turned off when deploying production code. This is done by setting debug='false'. However, it is not uncommon to deploy code with debug='true' because of the false sense of security given by the additional information provided by the debugger. Making technology a more inclusive environment means that false explanations for the lack of diversity in technology (like the "Pipeline Problem") should be avoided because of the false sense of security they provide.
Attendees of this session will leave with an understanding of the diversity in technology problem that is illuminated by terms that they already know. They will gain techniques that they can immediately put into action for making technology the inclusive environment in which we all deserve to build our careers.