Trip Report: 2020 Software Developer Diversity and Inclusion Workshop
Building community and brainstorming concrete ways to support D&I in software
Last Thursday, a tweet floated across my timeline with an invitation: “On Monday, August 17th, we’re having a virtual workshop on Software Developer Diversity and Inclusion Research. Join us, won’t you?”
Following the accompanying link, I found out about the second annual Workshop on Software Developer Diversity and Inclusion (SDDI 2020). With a self-stated goal of “rais[ing] awareness about developer diversity and inclusion challenges faced by industry today” and a public attendee list of software engineering and human-computer interaction researchers I’d heard about and read work from, this seemed like a great opportunity. On top of that, it was free to attend and open to all through virtual participation! I signed up, looking forward to Monday.
Day 1: Talks and Discussion
The first day of the workshop consisted of a series of short (~10–15min) talks from researchers and practitioners with accompanying live Q&A afterward. There were a few keynotes in there as well. The workshop’s #questions4speakers Slack channel provided an interesting stream-of-consciousness-esque view into attendees’ thoughts and reactions alongside each talk, with participants both posting questions and linking to resources for others to use.
Is 40 the new 60? How popular media portrays the employability of older software developers — Alexander Serebrenik
Due to some A/V issues on my end, I wasn’t able to catch the first talk of the day live. However, all of SDDI’s talks this year were prerecorded and uploaded to YouTube, so I caught up on Alexander’s talk during the mid-day break.
Ageism in tech is one bias that lurks beneath the field, but up to this point it hasn’t received as much attention as, for instance, sexism or racism in the industry. Alexander and his team collected publications from popular media outlets like Medium and TechCruch to see what kinds of common themes arose in public discourse around age and the software industry. They found a number of strategies suggested to increase “older” workers’ employability in what turned out to be a largely young-coded field, ranging from different hiring emphases for workers in different age groups on the company side, to practices like specializing and adopting “youthful behaviors” on the individual side (which included detrimental practices like working late and working weekends). Notably, Alexander’s team found that many of these articles defined “old” as 40 years or older, which is well below retirement age in most industrialized countries. Overall, this was a fascinating look into the way ageism perpetuates not just within tech companies, but in the discourse around them as well — which likely influences who applies for those jobs in the first place. A preprint of Alexander et al.’s work can be found here.
A Theory of Software Change — Ayushi Rastogi
Ayushi presented her process theory of the factors which influence software change on GitHub, which she mentioned was intended to be a representation of the world as it was, not necessarily a prescriptive theory of what the world *should* be. By reviewing literature on the nature of GitHub pull requests and related workflows, Ayushi found six main factors that relate to software change: Available unit changes, the existing codebase, the community, existing governance, tools and technology available, and the overall ecosystem in which the software exists. During Q&A, attendees brought up some of the tensions that might impact these factors (such as if the community and the governing authority have conflicting goals) and what that might mean for making meaningful software change. This work is ongoing, and Ayushi is currently refining this theory by soliciting feedback from developers and researchers.
How can we include the EU Accessibility Directive in our on-line teaching materials? — Ita Richardson
Now that most institutions are teaching online, creating accessible materials becomes incredibly important for equitable remote learning. The European Union put out a 152-page Accessibility Directive for remote learning that mandates certain accessibility features be integrated into educational materials (lectures, assignments, etc.). Ita’s team distilled this document into a set of 21 questions for educators to audit their materials with, in order to hopefully support better compliance with the directive. Ita pointed out that some of the questions were simply traditional usability concerns for software interfaces (e.g. “Is there something in place to notify users when making a change in the user interface?”, and another about error prevention). Others were more targeted at particular disabilities and conditions that could present barriers to learning if overlooked.
During Q&A, I asked Ita’s opinion about the best ways to balance accessibility with student engagement for remote learning. Methods of teaching that use more active learning styles often rely on synchronous student engagement, which in the COVID-19 era has translated into video chats over platforms like Zoom or Google Meet. However, this can present barriers to students that don’t have constant reliable Wi-Fi or electricity (as at least five of my forty students struggled with during spring quarter), not to mention concerns about real-time accessible audio or video. Ita, who’s done some work on techniques like Problem-Based Learning, suggested structuring classes around smaller synchronous student groups that meet together to work on activities. She also noted that flexibility on educators’ parts is key in the time of remote learning — doing what’s best for your students’ learning should supersede any generalized recommendations.
Keynote: Diversity and Heterogeneity — Biao Xiang
Biao’s keynote began by discussing the undercurrents of structural racism through the lens of the recent upswing of Black Lives Matter activity in the wake of George Floyd and others’ murders at the hands of police. Biao drew parallels to structural inequities that discriminated against groups of people in other countries and other times. He noted that even the recognition of diversity often unsettles these entrenched structures (which are often predicated on assumptions of homogeneous majority populations), which can disenfranchise and drive out those who hold minortized identities. Biao raised three “D” concepts throughout his talk — diversity, differentiation (of stakeholder groups and their goals/actions), and divide (between ideologies that drive what kinds of software gets developed). At the end of his talk, Biao challenged us to do three things:
- Continue to celebrate, protect, and enhance diversity in the high-tech industries.
- Be mindful that diversity initiatives that are taking place at universities and in industry are only impacting those who could make it there in the first place, and look for opportunities to expand beyond those borders.
- Pay attention to differentiation that exists (or doesn’t) around us, and actively work to create heterogeneous high-tech spaces.
Equity Engineering: Impact & Opportunity — Dominique Wimmer
Dominique introduced us to the Equity Engineering team at Google, sharing their goals and processes for ensuring that products can be used by as many diverse users as possible with the result of equitable outcomes. The team starts with User Experience (UX) research that prioritizes the most marginalized users first (with a focus on racial and gender diversity). Additionally, the Equity Engineering team tries to build what they call “equity fluency” across different departments within the company, with efforts to teach and train technologists who can effectively put these ideas into concrete action. Dominique highlighted that the team’s efforts involved not only the developers and designers, but also human resources and hiring practices, since creating inclusive technology requires a diverse group of employees and a supportive company culture. The team subscribes to the philosophy “Don’t build for everyone. Build with everyone.”, which means including users who are the most unlike the development team in all stages of design and development and centering marginalized voices. Dominique was optimistic that while change wouldn’t happen overnight, concerted efforts like these could start to change the culture of software development to be more inclusive and welcoming to folks of all genders, cultures, races, abilities, backgrounds, and experiences.
Empathy, Opportunity and Inclusion in Accessible Design: A perspective from undergraduate CS education — Stephanie Ludi
After a short break, Stephanie presented her work on teaching undergraduates the skills they needed to design and develop accessible software. As most folks in the HCI education space know, teaching and learning these skills is difficult. Stephanie discussed some findings from a recently-wrapped-up four year longitudinal study of students who took courses which involved an emphasis on accessible software development early on in their undergraduate educations. Unfortunately, interviews with these students two or three years later revealed that students tended to ignore or devalue accessibility concerns in their final capstone project unless it was explicitly incentivized by the grading scheme, suggesting any attitude changes toward accessible development didn’t stick in the long term. Stephanie closed her talk with some recommendations for teaching accessibility concepts:
- Integrate accessibility early and often in undergrad curricula
- Make accessibility part of the grading scheme for large projects so students can’t ignore it
- Provide resources that students can use in their projects
- Be aware that students might not necessarily know or interact regularly with disabled people
- Absolutely DO NOT rely on students with disabilities to educate their peers (as unfortunately ended up happening on occasion)
The Q&A for Stephanie’s talk was lively, with questions on topics ranging from teacher expertise, to embedding accessibility concepts throughout the curriculum, to how we might promote empathy with diverse user groups in a way that persists when they enter industry.
At this point I had to step away for some other meetings, which took up a bit more of my afternoon than I expected, so I couldn’t make a good chunk of the afternoon talks. Even the titles looked intriguing, so I’m sorry to have missed them!:
- Predicting Developers’ Negative Feelings about Code Review — Carolyn Egelman
- Investigating Bias in Code Review using Medical Imaging and Eye-Tracking (and A Summary of Diversity Work at UM) — Yu Huang
- Keynote: What I learned from 6 years of building CodeNewbie — Saron Yitbarek
- Experiences Running a D&I Program at ASE 2019 — Andrew Begel
- Conducting Covert x Overt Inclusion Research—Denae Ford [accompanying paper here]
One upside of the workshop’s virtual format is that the talks were largely pre-recorded, and the workshop’s Slack backchannel has a persistent record of (some of) the comments and questions for each speaker. The wonders of modern technology will allow me to catch up on Carolyn’s, Yu’s, Andrew’s, and Denae’s talks when I have time. (Saron’s keynote wasn’t recorded.) I caught the tail end of a discussion on bias in community-based research after Denae’s talk when I hopped back into the Meet room, so I’m sure there was some good stuff.
If you’re interested in checking out some of the pre-recorded talks yourself, you can find speakers’ videos and slides on the SDDI 2020 homepage.
Agile Inclusive Accelerator: A research and education program for an equitable tech future — Rafael Prikladnicki
Rafael spoke about a program running at his institution for nearly a decade that focuses on preparing diverse students to succeed in the tech field by teaching the basics of the Agile software development workflow. Though the project began with undergraduates, the team found they didn’t have enough folks in their target population at the university, so they expanded to high schools. The Agile Accelerator saw big improvements in gender and social class balance over recent years, the result of inclusive application practices like selecting students not on the basis of their technical skills, but through a more holistic view of their fit for the program. Rafael also gave a brief overview of the newest version of the program, the Inclusive Accelerator, which had an explicit goal of supporting social and economic inclusion. He closed by describing some challenges that still faced the program, including emphasizing students’ learning over their desire to deliver a finished product, and figuring out how & whether this experience could be replicated in different contexts (both in Brazil and in other countries).
Hidden Figures: Different Roles and Success Pathways in Open Source — Anita Sarma
To close out the first day of the workshop, Anita presented on some of the work she and her team have done on diversity and inclusion in open source. Anita described the current state of OSS as a field where contributors are largely male, English-speaking, college-educated, and socioeconomically secure enough to have volunteer time. To figure out how to improve OSS community diversity, she and her team conducted a series of interviews to understand the pathways different folks followed into open source work. The diversity in participants’ paths led their team to call for more recognition of the “hidden” roles and work often overlooked in customary representations of the OSS community, and especially around how we can support folks in these less-visible (but still vital) positions. Anita et al.’s freshly-minted CSCW paper with more details on the topic can be found here.
Day 2: Breakout Sessions
The second day of the virtual workshop was structured around breakout sessions: two parallel tracks of 90-minute informal chats with other attendees. Topics for the breakouts were sourced from workshop participants on day 1, and we self-sorted into groups based on our interests. I was able to attend three in the (Pacific Time) morning hours. Each group made good use of Google Docs for collaborative notetaking during the breakouts, with participants sharing resources and commenting to share their thoughts.
Diversity and Inclusion (D&I) in Software Education
The first session I attended focused loosely on D&I in educational settings. Attendees raised a number of challenges they’d seen or experienced around diversifying the incoming populations to computing higher education, as well as how to support minoritized groups enrolled in CS courses. When someone mentioned that the focus on higher ed limited our scope to folks who’d already managed to get there, the conversation naturally turned to attempts to improve perceptions of computing for students in younger (primary and secondary) contexts. With many of the workshop attendees being current or former educators, there was a lot of sharing about institutional efforts to improve D&I, what worked, and what didn’t. The idea of situating computing as a culturally relevant and social topic threaded through many of the efforts that worked. Others reported success from interdisciplinary computing courses located in non-CS departments (e.g. a “CS for bio-engineers” type of class). We also briefly discussed how to combat anti-Black racism in CS education, but we ran out of time to do the topic justice. I ended up dropping a bunch of links in the shared document to articles my anti-racist CS education reading group discussed over the summer.
There were some plans to tidy up our notes from this breakout session and make them publicly available, so I’ll update this section with a link if & when that happens.
Understanding Challenges and Barriers to achieving D&I in Software Development
Before trying to fix something, it never hurts to get a good strong understanding of the challenges facing you. This session focused on surfacing those barriers to D&I research and brainstorming concrete ways to get around them. One topic that surfaced early on was that of ensuring anonymity for our participants — If we’re working with groups that are by definition small, how can we ensure they feel safe and comfortable sharing their experiences with us? We discussed good interviewing and reporting practices in these cases, with some attendees sharing personal anecdotes about methods they’d found useful when working with different populations. From that, we moved to what it meant to “meet” D&I goals — What does success look like, and how can (or should) we measure it? I chimed in with a shameless plug for the usefulness of qualitative analyses in these situations, which led us to revisit the anonymity question.
During the latter half of the breakout session, someone asked how we might respectfully do research with communities we aren’t necessarily a part of. Many folks shared their strategies for community research, stressing the importance of including community members in all stages of the research design process as well as ensuring the work you’re doing is aligned with community goals. The importance of learning from other disciplines’ successes in this area was brought up (with Indigenous studies and anthropology being two that were mentioned). One attendee suggested cross-department collaboration and sitting in on other researchers’ processes to gain an understanding of how participatory research methods worked. The general sentiment seemed to be that CS researchers could learn a lot by looking to other social science disciplines on this topic.
Doing D&I Research in Company Settings
The last breakout session I was able to attend focused on the realities of doing D&I-related work (mostly research) in industry settings. As someone without a lot of industry experience, it was neat to gain some insights into how some lager tech companies’ internal reviewing and legal constraints shaped the kinds of work employees participated in, as well as how D&I research in particular often interacted with existing codes of conduct or mandatory reporting measures. We also chatted at length about the nuances of conducting research internally (with the company’s own developers and their processes) versus externally (with other populations), as well as how those distinctions could impact the publish-ability of any findings. Toward the end of the session, talk turned to the differences in conducting D&I research in academic versus industry settings. We had a number of attendees in the session who had both kinds of experience and were able to relay the contrasts they’d seen.
At this point, the workshop took a longer mid-day break. I had other prior commitments for the rest of the day, so this is where my trip report ends, but there were at least six more breakout sessions in the afternoon that I’m sure sparked good conversations.
I’m glad I got the chance to attend SDDI this year. Since I started my PhD and pivoted toward HCI education research, I’ve spent more time in design and education spaces than primarily software engineering-focused spaces. If not for the fortunate coincidence of me being online at the right time to see Emerson’s tweet, I doubt I would have stumbled upon the workshop. Being immersed in this community for two days felt like I was revisiting some threads of my undergraduate research on gender-inclusive software engineering and design (in a good way!), with the added experience and perspectives I’ve gained in the past few years. The workshop’s virtual nature and open participation was certainly a plus as well — It allowed folks to join in from numerous locations without the financial and logistical burdens of travel.
Shout-out to the SDDI 2020 organizers (Emerson Murphy-Hill, Google; Margaret-Anne Storey, University of Victoria; Denae Ford, Microsoft Research; and Sophie Qiu, Carnegie Mellon University) for their hard work, and to all the speakers for taking the time to share their expertise with us.
Depending on what the world looks like at this time next year, I’ll be looking forward to seeing folks again (virtually or not) at SDDI 2021.
