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?

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

Alexander presenting a graph of strategies and factors that can influence “older” developers’ perceived or actual employability, on both the individual or company sides.

A Theory of Software Change — Ayushi Rastogi

A model of six circles (factors) surrounding+connected to  a central circle labeled “software change”. Labels in text
A model of six circles (factors) surrounding+connected to  a central circle labeled “software change”. Labels in text
Ayushi’s model for the theory of software change, highlighting how each factor interacts with change.

How can we include the EU Accessibility Directive in our on-line teaching materials? — Ita Richardson

A slide with five bullets on it. Each bullet = 1 of the 21 Qs educators can ask themselves to ensure materials are accessible
A slide with five bullets on it. Each bullet = 1 of the 21 Qs educators can ask themselves to ensure materials are accessible
The first five of Ita’s 21 questions for educators distilled from the EU Accessibility Directive.

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:

  1. 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.
  2. 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

A screencap of a person presenting slides virtually, with automatic captioning along the bottom. Text of the slide in caption
A screencap of a person presenting slides virtually, with automatic captioning along the bottom. Text of the slide in caption
Domnique presenting the Equity Engineering team’s goals: Dismantle systemic bias in engineering globally; Empower and drive access to the tech industry at large; Share findings with open source to promote universal equitable frameworks.

Empathy, Opportunity and Inclusion in Accessible Design: A perspective from undergraduate CS education — Stephanie Ludi

A screencap of a slide from Stephanie’s presentation, with four findings of student perceptions. Text on slide in caption.
Stephanie’s findings on student perceptions of accessibility as they reached the end of their programs: Accessibility is often “tagged onto” a project rather than integrated in; Accessibility is usually ignored unless it’s an explicit requirement; Short term knowledge gains don’t seem to transfer to later courses; Empathy to user needs is often lacking.
  1. Make accessibility part of the grading scheme for large projects so students can’t ignore it
  2. Provide resources that students can use in their projects
  3. Be aware that students might not necessarily know or interact regularly with disabled people
  4. Absolutely DO NOT rely on students with disabilities to educate their peers (as unfortunately ended up happening on occasion)
  • 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]

Agile Inclusive Accelerator: A research and education program for an equitable tech future — Rafael Prikladnicki

Hidden Figures: Different Roles and Success Pathways in Open Source — Anita Sarma

A slide with a picture of mountains and a rainbow on it, with four findings from Anita’s talk. Text in caption.
A slide with a picture of mountains and a rainbow on it, with four findings from Anita’s talk. Text in caption.
Anita’s takeaways from her team’s work on hidden figures in OSS: Recognize them & their roles in open source; Individuals follow flexible and fluid roles; Contribution can take three forms: time, talent, and treasure (a quote from P3); Identify support to help them reach success.

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.

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.

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.

they/them // any pronouns. Strategies, techniques, and tools for teaching inclusive HCI design. PhD Candidate @UW_iSchool. www.alannaholeson.com