SIGCSE 2018 trip report: CS for All!
When I first started doing research on the learning of computing, most of my exposure to the topic was through the excellent ACM ICER conference. As a small, inclusive community of rigorous learning science and education researchers, it was the best way for me to learn about the best work in the field. I’d found my people.
From afar, the SIGCSE technical symposium was entirely different beast. My first experience was disorienting: not only was it nearly as large as the ACM CHI conference, my first academic community, but it was and is still dominated by practicing teachers, not researchers. As a researcher, this is both a blessing and a curse. The blessing is that there’s an incredible group of teachers that come ready to learn and change their practices; that’s an unprecedented resource for research dissemination: nearly everyone I talk to is someone who might adopt my lab’s ideas. The curse is that the research conversations I enjoy most about basic research questions about learning to code are rare. This has meant that attending SIGCSE has always felt like more of a dissemination event for me rather than an opportunity to learn about new discoveries and generate new research ideas.
This year’s SIGCSE was different. Not only was there a dedicated research track for the first time, improving the quality of the research work and attracting more researchers than ever before, but the dialogue between teachers and researchers was more mature and urgent than ever. This was fueled by the national and international efforts at providing access to computing education to everyone, not just those who show up.
Before I share some of themes from my SIGCSE experience, first a disclaimer: this is just one of 1,700 attendee experiences. I highly recommend also reading the #SIGCSE2018 Twitter feed for the conference for a broader view of people’s experiences.
Big ideas
Tim Bell received an award for Outstanding Contributions to Computer Science Education. He gave a wonderful keynote on the big ideas of computer science, and why youth need to understand these ideas. He started out talking about the efforts in New Zealand and Australia to require computing in K-12 learning, and what might be at the heart of that learning. Tim discussed his efforts in CS Unplugged, which strips away computers from computing, allowing youth, teachers, and parents to understand that computing is really about understanding procedures and calculation, not about hardware. He gave the example of bar codes on products, how digital images are composed of digits, and how algorithms shape interactions for better or worse. Tim also argued that computing includes HCI and Design, which he suggested was central to conveying to the world why computing matters. The session ended with many heartfelt thanks to Tim from attendees about just how profoundly CS Unplugged has helped teachers without access to computers teach computing, but also how well it has helped students see the relevance of computing to their everyday lives.
Ruthe Farmer, the Chief Evangelist for CSforAll, gave the closing keynote about the CS for All consortium and it’s goals of providing access to computing education to every public school in the United States. She started with a bit of her own personal history with computing, which actually didn’t involve any computing. Ruthe shared all kinds of amazing stories of youth finding computing and envisioning new ways of solving problems with computing, including a a group this weekend that is gathering data about gun control. Ruthe’s “aha” came in 2009 when she sent out a poll to some students and found that students didn’t have access or interest. She began to think about education as a master key that opens doors, but also a key that few people get access to. She talked about President Obama’s huge investment in the Office of Science and Technology policy, and his amazing literacy about science and technology. She talked about a “scout and scale” method of change, finding good examples of great work, make it public, and use that visibility to scale, replicate, and resource efforts.
CSforAll is a great example of how to catalyze education reform. It remains to be seen how much impact it can have and for how long, but I’m optimistic that the strategies the team are developing with help develop the leaders necessary for achieving change at scale.
Inclusion
The conference was about more than just the ideas in computer science and our goals of spreading it. In fact, the more dominant theme in my experience was inclusion, which is at the heart of efforts to broaden participation in computing.
Brenda Wilkerson of AnitaB.org gave the first keynote of the conference. AnitaB envisions a future where “the people who imagine and build technology mirror the people and societies for whom they build it.” Brenda encouraged us to think of efforts to democratize ideas in computing not just as an education reform effort, but a revolution. Her argument was that if we change education to incorporate CS, and youth embrace CS, we won’t just change what they know and can do, we’ll change the face of who creates and designs technology, which will change technology, which will change the world. Brenda then talked about how to grow this revolution, reviewing her work in Chicago, where CS is now required across K-12 (but not quite yet fully implemented). She also argued that to achieve this change, we first have to change adults: what they believe, how they behave.
I spent the rest of the first day of the conference also talking about inclusion. Richard Ladner, Brianna Blaser and I kicked off the new Inclusion track for the conference on a session about incorporating ideas from accessibility into computer science classes. We had about 20 attendees, all curious about how to teach accessibility, how to integrate it into existing topics, and how to learn more. We generated many interesting ideas about integration. For example, some who teach machine learning realized that there were fascinating ways to teach about bias in data by talking about how outliers can emerge from variation in ability. This variation shouldn’t be discarded; rather, machine learning algorithms should be robust to it, which actually means that diversity is a grand challenge for machine learning. Another example for data structures classes is that screen readers, which are used by people who are blind, or people who have dyslexia, require content to be serial or hierarchical. That means everything must be a list or a tree. Thinking about how to translate or navigate non-list, non-tree data structures as lists or trees is therefore a grand challenge of accessibility and a fascinating accessibility problem that can motivate students new to computer science. Attendees really wanted resources that conveyed all of these resources (this is something my lab and AccessComputing is working on). Attendees also felt they needed some basic resources to develop their own expertise about accessibility, such as a book covering all of the foundations that they might also use for teaching.
These conversations mirrored the results of a survey that Kristen Shinohara, Saba Kawas, Richard Ladner and I did to understand who is teaching accessibility in the U.S., to what extent they are. We had a robust audience of 50 attendees with many interesting questions about the cultural changes that might be needed in computer science departments to incorporate even small amounts of accessibility into classes.
My Thursday marathon of inclusion and accessibility culminated in back to back birds-of-a-feather sessions on AccessComputing and TeachAccess. AccessComputing (of which I am an co-PI) helps students with disabilities engage in computing. TeachAccess is an industry effort that aims to get students in computing and information science to learn more about accessibility, so they can engineer more accessible technologies. There was quite a bit of overlap in the 20 or so attendees, and since the group was small, we talked a lot about tactics for combining our efforts to achieve greater organizational and community change. I left these conversations convinced that the community really needs a book about accessibility that teachers, engineers, and designers can use to quickly learn the basics.
On Saturday I helped lead an AccessComputing session on inclusive learning and teaching session. There were about 25 attendees were from high schools, colleges, universities and even the College Board, and included some department chairs. Everyone came to learn what inclusion means and how to support it in classrooms and culture. Achieving inclusion is no easy task, and covering the basics in an hour wasn’t easy either. We provided a few basics about universal design and norms, and then walked through some scenarios about students with physical disabilities, learning disabilities, and other issues of neurodiversity.
Programming
Since my lab studies programming, we’re fascinated by research on how to teach and learn programming. My student Benji Xie gave the first conference talk of his Ph.D. on a novel strategy for teaching how to read programs that rapidly improves students abilities to read programs correctly. Benji’s work was not only incredibly popular in a session of nearly 100, but also triggered important questions about evidence. Some demanded a better evidence standard for how we measure prior knowledge amongst students, so we could combine results across institutions. Some instructors wondered whether we needed evidence at all, leading to a rich debate between researchers and practitioners about the value of evidence.
We had a great lunch with Baker Franke and GT Wrobel from Code.org about opportunities to disseminate our work on tracing and problem solving strategies to Code.org’s curriculum and professional development materials. Our pedagogical research is luckily simple to implement and adopt, and so Baker and GT were interested in incorporating our ideas into the teacher professional development and curricula that Code.org develops and maintains. We spent the lunch describing the ideas, brainstorming opportunities for integration, and planning out how to project manage this research dissemination. If we’re lucky, our recent discoveries might make it into the classrooms of hundreds of teachers over the next year or two. Impact!
I also had lunch with Peter-Michael Osera at Grinnell College, and who will be doing a pre-tenure sabbatical at my institution, the University of Washington. He’s starting fascinating work on interactive program synthesis, which is a compelling new vision for how programming of the future might involve collaboratively searching for programs with the help of tools, rather than authoring them wholly through human creativity. We talked about the profound changes required to convert batch program synthesis algorithms into interactive, mixed-initiative interfaces that combine human and computer knowledge for better results.
Software engineering
There was a surprising number of papers on software engineering education. This is great to see; after all, most students become software engineers, and so focusing on this skillset seems key. The primary focus of most of this work was on how to manage teams and projects in the context of a class.
Many of these efforts are coordinated through Humanitarian Free and Open Source Software projects, through the project POSSE. Three TOCE papers One paper explored how institutional context effects capstone project management, finding that institutional initiatives are key to bootstrapping, and that team management is similar to project management in industry, but different in key ways due to the educational context. Another paper explored four different types of software processes (Agile Scrum, Agile Kanban, CRISP—a cross industry standard waterfall model for DS—and no defined process). Scrum didn’t work very well: students weren’t compliant with the process and couldn’t self-organize.
Mentorship
One of my undergraduate researchers, Leanne Hwa, presented our work on different roles and impacts of computing mentoring relationships that evolved organically in a set of students from underrepresented groups. Attendees asked great questions about the students’ different conceptions of computing, and about the surprising variation in students’ preferences around age and expertise.
The paper that followed Leanne’s investigated research experiences for undergraduates. This paper modeled survey responses, finding that self-efficacy around research increased, but intent to go to graduate school decreased, despite the strong mentorship they received. The third paper in the session also talked about mentorship at the University of Illinois Urbana Champaign’s CS department; they reported formal mentorship as entirely unhelpful, and fear about talking to professors who they viewed as potential mentors. Students instead relied on advising staff, since they were the ones available and open to supporting them.
A third research paper on mentorship investigated the role of mentorship in change in self-efficacy and interest in CS after near-peer mentoring program for high school. The study found that mentor “relatability” predicted about 20% of the variation in participants’ self-efficacy and interest in CS, further reinforcing our paper’s findings (and our ICER 2017 paper on mentorship as a predictor of interest that the authors didn’t cite).
Bootcamps
Following our initial study on bootcamps at ICER 2017 last year, there were several followup papers this year. My student Kyle Thayer served on a panel about it, and described it as follows:
This panel was on alternate pathways and had people who researched undecided undergraduate students who decide on CS later, students transferring from community college, Salesforce admins learning programming to be able to do more in their job, and coding bootcamp students. They discussed how the current conception of a stereotypical path to a programming career and the terminology of “alternative” paths can lead to people feeling like outsiders. Having visible examples of people who have taken these paths can help normalize them. They then discussed why these alternate paths have greater diversity including the longer time it takes for many diverse people to decide they want to learn programming, and the way, for example, some (though not all) bootcamps create more inclusive environments. They also discussed the need for multiple pathways to exist due to the diverse needs of students, including how bootcamps teach a different set of skills (current technology and team work) than CS programs do (overview of the science of computers).
There were also several papers on bootcamps. One found that hiring managers see graduates as having unique qualities in the soft skills of teamwork, passion, and persistence, likely because of their extended work experience in other professions, but they still viewed a four year degree in some subject as critical. This is consistent with my experiences as an engineering hiring manager. (The paper unfortunately did not cite or build upon our ICER 2017 paper on bootcamps).
I also had a nice conversation with undergraduate Sherry Seibel at Simmons College who’s been doing research on bootcamps and equity. She’s found that the cultures of inclusion vary considerably, especially from a gender perspective.
Ethics
I had a great conversation with Casey Fiesler about some of the challenges and open questions around ethics education in the context of computing. She presented her award-winning experience report paper on an ethics course that involved current events, real-world problems, and artistic provocations. They found that all of these efforts amplified student engagement and that many students framed the course as the most thought-provoking course they had taken.
Measurement
I had a few great discussions about measurement. Kathi Fisler from Brown University noticed that many of the research papers that she, I, and other faculty have been doing on tracing haven’t really had robust measurements of prior knowledge. This has made it hard to compare results across studies. We had a productive discussion about developing an evidence standard around this. While we didn’t brainstorm any obvious lightweight measurements of prior knowledge that we could all agree upon, we did all pledge to do better to articulate what prior knowledge we think we’re measuring, and precisely how we measured it. This is often in tension with the restrictive page limits of conference publications, but seems like a worthwhile goal for improving our ability to build upon each other’s work.
The other great conversation as a unique session that brought together researchers and program evaluators to try to find common ground around measurements for impact. The attendees of the session reflected on the need for validated instruments to improve both research and evaluation, but also the challenge of building them as part of short-lived research/practice partnerships. This seems like a big gap in basic computing education research that labs like mine should be filling.
I had a great time this week in Baltimore. There’s so much energy and passion in this community, across all kinds of institutions and organizations. It’s not at all the normal research conference I’m used to, but I think that’s a good thing: if only for a few days a year, leaving the ivory tower and contextualizing my basic research is invaluable to me and I hope to the world.
