Step 74: Address the Election

The big news from this past week is, of course, the election of Trump as the 45th president of the US. The atmosphere around Oxy has been subdued for most of last week, and there has been articles and blog posts about how colleges have responded to the unexpected turn of events.

For my part, Wednesday morning felt numb. My CS lecture was on parsing – normally a mind-bending topic due to the heavy mutual recursion, but which in context felt irrelevant. I hastily added a slide to my lecture about understanding if students can’t focus, offering to listen if they want to talk, but otherwise gave the lecture I had prepared before the election results came in. There were noticeably fewer students in class; one or two had emailed me saying that they were too distracted for class to be helpful, but many simply did not show up.

I co-teach a cognitive science class right after, where we made roughly the same announcement. Luckily, that class was dedicated to peer-review of papers, so students mostly worked in groups. Still, the conversations were hushed, and some students decided to pay with my colleague’s puppy (which she brought to class) instead.

What I did do was rethink some of my future lectures. One of them was the security and privacy lecture yesterday, which was depressing already. In addition to the standard narrative about strong passwords and limiting information leaks, I also added a slide about the privacy implications of corporate acquisitions. The reading was about Microsoft and LinkedIn, but I also brought up the NSA and government transitions. I will be changing one more lecture as well: the last lecture of the semester was originally going to be on version control, but instead I decided to more generally address the role that technology might have played in the election, specifically job loss due to automation. The plan to conclude on the message that, as students who how computers work and what technology can do, they must be deliberate in applying that knowledge to the social good.

All that, and I am not sure what else I can do for my students. I know some of my other colleagues have had students message them, even the night of the election as Trump pulled ahead of Clinton, seeking both advice and comfort. I have not had students come to me, and to be honest I am relieved for that. I have never been great at comforting people, and I have never learned to navigate that especially in the context of student-teacher relationships. I guess, for students reading this: you should know that many of your professors are feeling as helpless, and as lost for words, as you are. We don’t know what the next months or years will entail, but if you need to rant, or just a place to sit and take a deep breath, we’ll be here.

Step 74: Address the Election

Step 73: Reflect on the Grace Hopper Celebration

It’s been two weeks since GHC, and I want to reflect on the experience a little. I have been other smaller conferences – namely, the Wonder Women Tech conference/expo in July – and to be honest, that event left a bad taste in my mouth. There were too many “motivational” stories and not enough dissection of the challenges of recruiting women and minorities. There was a panel of director-level women which I enjoyed, and I got to ask Nicole Stott a question about sharing our passions with others, but those were the best moments.

Still, GHC is the largest and best-known event for a reason, and although it didn’t blow my mind, I also didn’t think it was a waste of time. I share the other faculty’s view that the event is heavily focused on industry, and I would even characterize GHC as a giant career fair with talks on the side. Most of the suggested policies in the talks are also aimed at companies, not schools – a flex work policy to retain women, for example, is a moot point for students who can already work whenever they want. Similarly, seeking out technical opportunities is much easier for students, who get to choose their classes every semester, than for early-career professionals.

Nonetheless, I think it is worthwhile for me to go, if only to have a better idea of what I will bring students to. I did learn a few things from the Redefining Mentorship panel, have some met people who I might keep in contact with. But let me conclude with one experience I didn’t blog, which occurred minutes after arriving at the convention center. I tweeted,

“Most salient feeling after five minutes at #GHC16: not belonging at a women’s celebration. …Except that’s the default for women in tech.”

I should tape that on my wall, because it’s so easy to forget that the lack of belongingness may have any single cause, but as an emergent property of the accepted culture. I’m not sure I know how to fight it, but at least I have a small taste of what it might feel like.

Step 73: Reflect on the Grace Hopper Celebration

Step 72.4: Attend the GHC Faculty Lunch

The GHC schedule leaves the lunches free for attendees, but also defines events for particular groups to socialize. One of these is the faculty lunch on Friday, which I attended. I sat at a table with Linda Sellie (NYU Tandon School of Engineering and, to my surprise, Occidental alum; she’s the second alum I ran into), Deb Richardson (UC Irvine), Soha Hassoun (Tufts), Marie desJardin (University of Maryland, Baltimore County), Aaron Gember-Jacobson (Colgate), Alexa Sharp (Oberlin), David Liben-Nowell (Carleton), and several others whose names I have forgotten.

There were two main topics of discussion at my table. The first was how GHC could be improved for faculty. All of us felt that the GHC was heavily industry focused, and that there were not many events for faculty to learn something. Accord to Deb, who has been at all but the first two GHCs, this trend towards commercialization is not new. We were surprised to hear that only about a third (5000 of the 15000+ attendees) were from academic (ie. faculty and students). Some thought that the number of company recruiters made up for the rest, but having been in some of the more professional-development-like sessions (like the technical career session), I actually believe that a significant number of attendees are early-career workers, looking to switch into a more technical position. I think this is evident in the sessions as well: some are entirely non-technical, otherwise require only an undergraduate-level of knowledge. Very few sessions are targeted at the PhD level, however, and Deb suggested (although she said it was not her idea) that Anita Borg should create a technical track taking female-authored best-papers from ACM and IEEE conferences.

It’s a good idea, but it doesn’t help the second problem: GHC is too crowded. The most popular talks had lines that wrap around the hallways, and apparently this was already happening last year when there were 4000 fewer attendees. (GHC was also at the same location last year.) None of us had good solutions to this problem: there was the suggestion of separating into multiple local conferences, but I suspect the West Coast (Silicon Valley) celebration would remain equally well-attended. One good thing about local conferences is that it would reduce travel costs for students and schools, especially since GHC is a major factor in attracting and retaining female CS students.

From there, the table turned to discussion strategies for teaching CS1 and CS2. There was a general consensus that we need to put the most personal, least scary professors in CS1, so that beginners are not scared off. Most of the other pedagogical strategies, however, are already well-known (to me, at least): encouraging in-class group discussions, soliciting multiple answers first (potentially then asking students to convince each other who is correct), and incorporating real-world scenarios and datasets into assignments. I got the feeling that none of us are satisfied with the literature, and are hoping that others will have additional ideas that would help.

I enjoyed the short hour that I got to talk to other faculty, and I wish there were more events where faculty can learn from each other. But, I understand that GHC is mostly an event aimed at students, and I’m glad to have any formal opportunity to meet faculty at all.

Step 72.4: Attend the GHC Faculty Lunch

Step 72.3: Help Non-CS Students Start Technical Careers

One of the most promising sessions – which I found myself, but also which several students caught and recommended I attend, is titled Pursuing a Technical Career without a Computer Science Degree. Clearly it was relevant for Occidental College, where students can’t get a CS degree even if they wanted to! Victoria Wobber (People Analyst at Google), Alison Song (People Analyst at Google), Gabriela Alcala Murga (Data Scientist, Facebook), and Manizeh Khan (Data Scientist at Amazon) hosted the session. Although they called themselves a panel, most of the session was interactive, with only one panelist on stage while the others walked around to talk to the audience. The session started with stories from each panelist of how they ended at their current positions, but then turned into pair/group discussions of our individual aspirations for a technical career.

Two things struck me about the introduction of the panelists. First, although they may not have any programming background, most of them were already in a STEM (or STEM-ish) field before switching. Tori has a doctorate in biology, Manizeh has a doctorate in psycholinguistics, Allison majored in 2012, and Gabi majored in math and stats. Second, the focus of the workshop was decidedly on data analyst positions: all four panelists mentioned learning SQL, and at least two of them mentioned R. My original interpretation of “technical career” was about software engineering, so I thought the title was ambiguous in that way. (I wonder if there are technical careers that are neither programming nor data analysis; perhaps lab-technician like positions might qualify?)

I was surprised a second time to find out that the main interactive portion of the session was about concrete steps to learning skills. First, our hosts helped us identify what each person wanted to learn, what resources they had to learn it, and how it might tie into their current or future jobs. The second half was then about setting short term (next week) to intermediate term (next year) goals, and how they might make themselves accountable. It was obvious that the session was a success, as the specific topic and the concrete steps meant most people walked away with an action item.

My main thought, as I was leaving, was how I could apply what I learned to Oxy’s students. When I decided to attend this session, I was hoping for more perspective on what careers exist that mix technical knowledge with other fields, or perhaps stories of transitions, or tips for navigating the job search and interviews. As it stands, the session was targeted more at early career professionals than at current/graduating students, who have a lot more opportunity to learn a technical skill while not juggling other responsibilities. So, although I thought the presenters did a great job leading us through the exercises, culminating in a concrete plan for improvement, I’m not sure it would be as helpful to my students as I want the session to be.

Step 72.3: Help Non-CS Students Start Technical Careers

Step 72.2: Blur the Mentor/Mentee Line

The first session I attended at GHC is Shattering the Old Boys’ Club: Redefining Mentorship for Women in Tech, which was a panel discussion and a short presentation by Nisha Dua (founder of Built by Girls), Stasia Efremkina (student at UPenn), Natasha Shah (software engineer at Verizon), and Susan Kelly (Director of Software Development at Verizon).

As with most mentorship panels, the discussion started with the exchange of what qualities the panelists look for in mentors. “Brutal honesty” is the standard answer for this question, and was predictably brought up. There were several other common answers (such as someone who genuinely wants to know the mentee), but one answer surprised me: that the mentor should be a confidant. This is not something I have thought about explicitly before, but makes a lot of sense in an industry context, since mentees may be looking for advice about switching jobs, or (less positively) looking for help on dealing with harassment. Less monumentally, however, it is also obvious in hindsight that for mentors to gain the trust of their mentees, sometimes the things they learn may be confidential or otherwise personal. As a professor, the latter is the more common case, and it’s useful to explicitly think of that information as private.

To be honest, I was more interested in how the focus of the conversation changed towards deconstructing the idea of mentor versus mentee. For one, mentorship still applies no matter how high up you are on the corporate ladder; there are always others who are in a more senior position, or have more experience from which you can learn. So while you may be a mentor to junior employees, you yourself may be mentored by someone else. Speaking personal, this is definitely the case when I mentor students but am still learning to be a faculty member and professor from my colleagues.

But the line is even blurrier than that: it’s not that you might play mentor for one person and mentee with another, but that it’s possible to be both mentor and mentee at the same time with the same person. This first came up in a story about how a cohort of new hires started relating each others’ perceived strengths and weaknesses, and how they can learn from each other even though they all have roughly the same amount of experience. That is, mentorship does not have to be about the differential in positional experience, but could also be about the differential in specific fields or skills. In fact, mentorship could sometimes be as simple as listening to the other personal, being the “rubber duck” as the mentee explain what they are thinking. (Maybe this is a temporary differential in headspace?) This rubber-duck-mentorship means that the amount of experience may not be relevant at all – all you need is one person being willing to pay attention and ask clarifying questions.

It was clear at that point where the panel/presentation was going: we need to break out of the idea that mentorship can only be one-to-one or one-to-many, or that it can only be hierarchical based on experience. The phrase “ecosystem of mentorship” was used near the end, and I think it perfectly captures the ideal of everyone simply having relationships with each other, and freely switching between the mentor and mentee roles depending on what is necessary at the time. To quote the presentation, the focus is not on “getting ahead” but on “getting better”, and we can all help each other with that task.

What struck me is that “getting better” is just another phrase for “learning”, and that is something I have more expertise on. Do we not do group projects, or active learning activities like think-pair-share, exactly so students can learn from each other despite their relatively equal amount of experience? I suspect that education research, especially ways to create informal learning environments, may have a lot to add to mentorship. Oxy does not currently have a STEM mentorship program, but there has been discussions about starting one (whether faculty-led or student-led), and I would love to see this ecosystem idea be incorporated into what we end up creating.

Step 72.2: Blur the Mentor/Mentee Line

Step 72.1: Set Learning Goals for GHC

I’m heading to the Grace Hopper Celebration today. I would have gone for the full conference (which started today), but teaching and other duties kept me in LA for the morning. Since I’m the only person going, I set some goals for myself, which I thought I would share:

  • Meet people virtually. I volunteered for a number of events at GHC, including sharing blog posts (all tagged GHC16, like this one!) and taking notes (which will show up on the wiki) . As a volunteer, I have already interacted with others who are contributing, and will likely pay more attention to other people’s accounts of GHC (which is aggregated on the GHC website).
  • Meet people in person. Since I’m blogging about particular sessions, this also makes me go to a lot more sessions than if I was just attending. I have also volunteered as a mentor, which will be opportunities for me to not only meet students, but also other people in academia and industry. My personal goal is to establish ongoing relationships with at least one new person each day, in addition to whatever conversations I will have during GHC.
  • Understand GHC through students’ perspective. As an Asian male, I am not the primary audience for GHC. But since I do not have students with me, reading the blogs of people who are the primary audience would help me understand why GHC is valuable. Luckily, I know a student who went before, and also some students just came back from SACNAS (Society for Advancement of Chicanos/Hispanics and Native Americans in Science). Some things they suggested I should pay attention to:
    • How GHC (as a conference) fosters an atmosphere where women feel welcomed and not isolated.
    • What recruiters are looking for, especially since Oxy students cannot (yet) major in computer science.
    • Research on the gender gap and what can be done to close it.

There are probably more goals that are not rising to consciousness, but these three are the big ones. I will be writing at least four more blog posts about GHC over this week, so stay tuned!

Step 72.1: Set Learning Goals for GHC

Step 71: Manage Crowdsourced Test Cases

One of the main reasons I wrote my own autograder is I wanted students to be able to test their code on other people’s test cases. This is my second semester teaching CS1, and although in both semesters I have used this feature, I have not found it as flexible as I would like. There is only a small window when students are sufficiently comfortable with the concepts – especially functions, but also loops – where they can write good test cases, but not may still struggle with writing the code. I suppose crowdsourced test cases are useful beyond that point, but that is also where CS1 starts becoming more creative, meaning I start reducing the use of the autograder. Together with the schedule of the course (weekly assignments), I really only get to use the crowdsourcing feature once.

This semester, the crowdsourcing was used on a Connect 4 lab. Students had to write a function that determined where a token would go in a column (lowest_empty_row), a function that asked for and verified user input (get_input), and a function that checked for the winning condition (has_connect_four). I motivated test-driven development at the beginning, then asked students to write and submit test cases for has_connect_four, using provided helper functions to easily create a board. The autograder is set so that during the lab, their own code would only run against their own test case. (Of course, they could also do this directly on their computer.) After the lab is over, I would then toggle the autograder so everyone’s test cases are used, then re-run all submissions on all the test cases. These results – both the correctness of the code, and the discrimination of the test cases – then become the students’ grades.

I thought the lab was mostly successful. The success is from students having “better” test cases than I did – there were a number of off-by-one errors that I didn’t catch, and some near-hits that I didn’t look too closely into. The failure is that, although students are rewarded/punished for the quality of the test case, I do not have any deliberate process for students to reflect on and improve their own test cases. The main constraint is time; although it’s a three-hour lab, students can only afford to spend an hour (more realistically, 30-45 minutes) on the test cases, so they still have time to finish the functions. Even if students had more time, however, I am not sure how I would guide this reflection. One idea would be for them to see the test cases that others (including themselves) failed, and see if they can identify the common programming error that caused it. I am not convinced that this is feasible, nor that it would transfer to awareness of likely mistakes in the future.

I have mentioned this test case crowdsourcing idea to several people, including the folks at zyBooks (which I use for my course), and interestingly I have had minor pushback on its utility. In addition to how students may not write good enough test cases – which this lab in particular offers a counter example – the argument was almost that testing (aka. quality assurance) is a whole different skill set, and therefore it does not play as big a role in CS1. To me, the fact that quality assurance exists as a separate department is evidence for the opposite – that writing good test cases is so hard we need experts to do it, which is all the more reason students should start learning early. That said, my inability to fully take advantage of the autograder, even in the second iteration of the course, suggests a mismatch between what I want to do and how I organize the course.

I want to end on some slightly technical thoughts on how test cases should be graded. For the Connect 4 lab, I graded not by test case but by test suite – that is, how many students failed any of the test cases that a student submitted. In particular, the student who fails the most people gets full marks, then everyone else gets a proportionally lower score based on how many people they did not fail. This means that everyone’s code was perfect, students would not be penalized for not finding bugs with their test cases.

While this gets the rough correlation correct, it doesn’t contribute to the goal of making students reflect on how to write good tests. I have a vague idea of grading individual test cases based on how many other students failed that test. The problem I don’t have a good way of combining this information; simply summing these numbers would favor quantity over quality of tests, while discounting students who fail multiple would revert the grading to what I do now.

I still believe in the idea of crowdsourced testcases. All the issues I brought up here are logistical and not technological, and I would love to hear success stories from others of how they teach test-writing skills.

Step 71: Manage Crowdsourced Test Cases