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.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.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.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 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 70: Apply for a Tenure Line

I apologize for the very late post; some search-related duties kept me busy.

Now that the job posting is public (please advertise it widely!), I want to describe the administrative process we went through to get the approval to post the ad. This is a part of faculty life that I’ve never thought about before, nor have I read about it anywhere, so I thought it would be useful to describe. I’m not sure how much of this applies outside of Oxy, and other institutions may have completely different terminology and procedures.

To start, the college often refers to funding a faculty as a “tenure line” – that is, from funding someone from assistant professor level, through their promotions over the years, until they retire. I like to think of tenure lines as belonging to a department: for example, if someone is retiring, the department may try to hire a new faculty to replace that person. This is not entirely correct, since departments can grow or shrink, and sometimes entirely new departments are created, but I imagine that the total number of tenure lines across the college only changes slowly.

The application process starts with a position request completed by the department. The request is half about the need for a new faculty member, and half about how such a hire would impact the rest of the college. I found the latter particularly interesting, since these considerations presumably only exist at small liberal arts colleges. Beyond the need to fill a gap or to remain competitive with peer institutions, the other departments and/or campus entities should also be benefiting from the new faculty. Reading back through the request for this post, I get the feeling that this is the heart of how the college grows, by the careful consideration of whether the new faculty would contribute to the college’s strategic plan, and how it generally enhances the quality of the education here.

The position requests usually takes several weeks to write, although for us it took less time due to great collaboration within the department. The completed request is then sent to our Academic Planning Committee (APC), together with signatures and at least one support letter external to the department. APC, a committee composed of the Dean and faculty from a cross section of disciplines, then decide whether to approve the request. Since it’s mostly tenured faculty who serve on APC – while it’s possible for untenured faculty to be appointed by the Dean if it was felt that they would offer a missing perspective, such appointments are unlikely – I am not privy to the discussion that occurs. All we get, via a response to the department chair, are comments on the position request, and whether an acceptance is possible after revisions.

Assuming the revisions are completed, the final obstacle before posting the ad is the detailed search plan. As the name suggests, this document covers the details of how the search will be run – from the exact ad to be posted, to how applications will be processed, to the timeline for the various interviews. The most interesting part of writing this document, at least for me, was the discussion on how to ensure we are reaching out to underrepresented applicants; in particular, borrowing an idea from a search in Philosophy, we are reaching out to diversity-focused organizations for help. This and other such strategies seemed to satisfy our Affirmative Action committee, who worked with the Dean for the final approval of our search.

Which is where we are now: job ads posted and waiting for applicants. I will likely write about the search process again when I am allowed to, since it’s fascinating to be on the other side of the job market. As I said at the beginning, please do share the ad with anyone you think would be interested in the position.

Step 72.0: Volunteer at GHC

I’ve written before about missing the registration for Grace Hopper, which is why I am going alone instead of with some students. Seizing the opportunity, however, I registered to be a volunteer note-taker and blogger, which will make me go to interesting sessions and meet new people.

This post mostly exists to populate the currently-empty #GHC16 tag, but I will post more under there as GHC gets closer – and of course when I’m actually in Houston!