Archive for September, 2015
The Chronicle‘s column on people has a piece about computing education researcher Steve Cooper who is moving from Stanford to the University of Nebraska-Lincoln. I just recently blogged about Steve’s terrific ICER 2015 paper (see post here). As Ben Shapiro quipped on Facebook, with Steve at U. Nebraska-Lincoln and Brian Dorn at U. Nebraska-Omaha and Omaha is hiring another computing education researcher (see job ad here), Nebraska (a relatively low-population state) likely now has the highest number of computing education researchers per capita in the United States!
From Stanford to Lincoln
Stephen C. Cooper doesn’t like being “smack dab in the middle of things.” He’d rather be out at the edge, he says, and trying to go in different directions.
In July, Cynthia Lee, Leo Porter, Beth Simon, and I held a workshop (funded by the NSF IUSE program) for new faculty at research-intensive universities, to help them to be more effective and efficient teachers. We had eight new faculty attend. We taught them about peer instruction, worked examples, how to create a syllabus, techniques for dealing with plagiarism, how to make time for teaching, and how to create a more inclusive classroom. The response was terrific. As one participant told us, “I can’t believe how much actionable knowledge I picked up about teaching in just a day and a half!”
We’ll be inviting new faculty from research-intensive universities again in Summer 2016.
The below list was created by Cynthia Lee for the workshop participants. I loved it and asked if I could offer it here as a guest post. I’m grateful that she agreed.
- Email top performers on a recent homework or exam to congratulate them; be sure to include a diverse group.
- Personally invite a woman or minority student who is doing well to major in CS, apply to an internship, or go to grad school. If your TAs work with small groups of students in a discussion section, have them do this as well.1
- Review today’s lecture slides to make sure that your gender pronouns are varied, and not in ways that conform to stereotype.
- Avoid heteronormative examples (e.g., bijective function between sets “boys” and “girls”).
- When using arbitrary names in examples, choose a broader selection (Juan, Neha, Maria, Mohammed, instead of just Jane Doe and John Smith). To represent your school’s population, use a previous quarter roster for ideas.
- At the beginning of the quarter, ask each student to email you to introduce themselves by naming one of their core values, and one way that CS relates to or could be used in service of that core value (or write it down in class, and/or share with a neighbor in class).2
- Never say, “This UI is so easy your mom could use it” or “How would you explain this to your mom?” or other phrases that equate women with lack of tech savvy. 3
- Review today’s lecture slides to make sure that stock photos and illustrations with people in them include diverse races and genders in non-stereotyped roles.
- Believe that hard work and effective practice matters more than DNA. Your beliefs influence students’ beliefs and impact their performance. 4
- Take a moment in class today to encourage students to focus on their “slope,” not their “y-intercept.” That is, in the long run it matters how fast you’re growing and learning, not advantages or deficiencies in where you started. 5
- Start class today by telling the students you’re proud of them and how hard they are working. Tell them you are enjoying working with them this quarter.
- Start class today by renewing your encouragement to students to come to office hours. Explicitly instruct them how to do it: “you don’t need to have a particular question-you’re welcome to just stop by for 5 minutes to introduce yourself” and “I’m not just here for homework questions-if you are considering changing your major to CS and want to talk about it, if you want to know what it’s like to work as a software engineer, if you are thinking about applying to grad school but don’t know where to begin, I’m happy to discuss that kind of thing as well.”
- Have very clear written expectations for student work (coding style, project components, etc.). Where possible, show sample solutions exactly as you would want a student to write them (don’t just give a “sketch” of the solution).
- Allow and encourage pair programming on assignments. 6
- Provide students with clear and timely feedback, including class-wide distribution data. Women and minority students often fear the worst about their position relative to the class and can be reassured by data. 7
- After a midterm exam, step through the math showing that they can still pass the course even if they did poorly. It’s just some multiplication, but take the time to talk about it. Be factual-no need to “sugar coat”-but provide facts that will help students who think things are worse than they really are.
- When a student is speaking, wait for the student to finish then count “one one-thousand, two one-thousand” in your mind before responding. Both men and women are prone to prematurely cutting off women when they speak. You may do this unconsciously unless you consciously add that pause. 8
- Occasionally choose a lecture to actually write a tally of how many times you’ve called on men vs women in the class. Both men and women are prone to calling on men more often. You may do this unconsciously unless you consciously do otherwise. 9
- Actively mitigate when students may be intimidating each other. When a student uses jargon in a question (often one of those questions that is more of a boast than a real question), explicitly identify when you expect that most students will not be familiar with that jargon, and/or it is not something other students are expected to know for the class (“Thanks for your comment. For the rest of the class, I’m sure most of you aren’t familiar with some of those terms-don’t worry, you’re not alone. Those terms are outside the scope of this class and not necessary to know.”)
- Ensure that you and your TAs call each student by their preferred name and gender pronoun-including allowing students to write their preferred name on homework and exams-even if these do not match their current legal and/or registrar records of name and sex. This issue deeply affects transgender students, and also many students who prefer to have an alternate anglicized name. Some institutions are good about allowing students to easily make these changes with the registrar so the preference will automatically show up on your roster. Find out about your school’s policies. You could also put a statement in your syllabus that you welcome students to email you about their preference.
- Watch out for examples or anecdotes about your childhood or daily life that may cause students to feel excluded for economic reasons (e.g., talking about pricey gadgets or vacations in Hawaii as normal). Even if you know that you did not experience these things and are simply using them as an example, students don’t know that and can mistakenly assume you are referring to them in a normative way.
- Mid-quarter, reach out to a student who has filed a disability accommodation form with you and ask them if their needs are being met in your class. Reaffirm your commitment to complying with their approved accommodations and your willingness to receive complaints if there is a problem.
- Encourage your colleagues to do the items on this list. Advertise your good example by bringing up your performance of these items in conversations with other faculty.
- Holly Lord and Joanne McGrath Cohoon. “Recruiting and Retaining Women Graduate Students in Computer Science and Engineering,” 2006. ↩︎
- Research shows this intervention mitigates stereotype threat. Reduced racial gap by 30%. https://www.gsb.stanford.edu/insights/value-values-affirmation. ↩︎
- This sexist trope is something women have been working to expunge from our vocabulary. Unfortunately, still often seen in discussion of UI design. http://geekfeminism.wikia.com/wiki/So_simple,_your_mother_could_do_it ↩︎
- Carol Dweck. “The New Psychology of Success.” http://s3.amazonaws.com/ebsp/pdf/mindsett.pdf This research shows that minority students perform worse in classes where the professor believes in a “fixed mindset” (talent is innate) when compared to performance in classes where professor has a “growth mindset” (talent can be developed through effort). See also CS-specific work on mindsets: Laurie Murphy and Lynda Thomas. “Dangers of a fixed mindset: implications of self-theories research for computer science education.” ITiCSE 2008. ↩︎
- Articulating this idea as slope/y-intercept is from Professor John Ousterhout of Stanford. ↩︎
- Among other research showing benefits of pair programming: Leo Porter and Beth Simon. “Retaining nearly one-third more majors with a trio of instructional best practices in CS1,” SIGCSE ’13. http://dl.acm.org/citation.cfm?id=2445248 ↩︎
- These fears are related to “Imposter Syndrome”-even highly talented students from under-represented groups fear that they are unskilled, and more unskilled than everyone else. Overview of Imposter Syndrome research: https://en.wikipedia.org/wiki/Impostor_syndrome ↩︎
- Occasioned by a news item about a panel discussion in Silicon Valley, NYTimes reviews research on women being interrupted when speaking: http://nytlive.nytimes.com/womenintheworld/2015/03/19/google-chief-blasted-for-repeatedly-interrupting-female-government-official/ ↩︎
- Jere Brophy and Thomas Good. “Teachers’ communication of differential expectations for children’s classroom performance,” 1970. http://psycnet.apa.org/journals/edu/61/5/365.pdf ↩︎
We now have TWO ebooks supporting CS Principles (see website here) now available — one for teachers and one for students.
Our teacher ebook summer study is now ended. (Announcement about launching the study is here.) We’re crunching the data now. We’ve already learned a lot about what teachers want in an ebook. We learned where our user interface wasn’t obvious, and where we needed to explain more. We learned that teachers expect end-of-chapter exercises. We have used what we have learned so far to produce the two new ebooks.
STUDENT CSP EBOOK: About a year ago, we received additional NSF funding (from the Improving Undergraduate STEM Education (IUSE) program) to develop a student version of our CSP ebook. We have been running participatory design studies and gathering usability surveys from students to get input on what a student ebook should look like. We have now released the first version of the student ebook.
The student CSP ebook is available at http://interactivepython.org/runestone/static/StudentCSP/index.html It doesn’t require a login, but we recommend that teachers have their students login. Without a login, we store saved answers on the local computer, but if the student logs in, we save the answers by the student’s username. The course name is StudentCSP.
We recommend that teachers create a custom version of the student ebook for your students. This allows teachers to customize the ebook, assign homework, and view student’s progress, and even create additional assessments for students.
New Version TEACHER CSP EBOOK: We iterated on our teacher ebook at the same time that we were developing the student ebook. We hypothesize that the student CSP ebook may actually encourage teachers to complete the teacher ebook. We can imagine that teachers who use the student ebook might want to stay one step ahead of the students, e.g., “My students are starting Chapter 3 on Monday, so I better finish Chapter 3 this weekend.”
We have now created a second version of our teacher CSP ebook. This one is in lockstep with the student CSP ebook, includes all the end-of-chapter exercise answers and teacher notes (e.g., on how to teach particular concepts, common student difficulties, etc.). We are not making the second teacher ebook available openly (because it includes answers to the student problems).
Teachers, please contact us at firstname.lastname@example.org with the name and location of your school, and we’ll send you the URL.
We recommend that teachers create their own course for their students. See http://interactivepython.org/runestone/static/overview/instructor.html for why a teacher might want to build a custom course and how to do it.
- You must register on Runestone first at http://interactivepython.org/runestone/default/user/register. Enter StudentCSP as the course name. Be sure to record your username. We find that users often forget what they entered and assume it was their e-mail address — and it may not have been. You can also choose to sign in with your account on Google Plus, Facebook, Twitter, or several others.
- Then go to http://interactivepython.org/runestone/admin/index and select “Create your own Course”.
- Create a unique name for your course (use your school name and StudentCSP and year maybe), add a description, and your institution, and then select “CS Principles: Big Ideas in Programming by Mark Guzdial, Barbara Ericson, and Briana Morrison“.
- Leave the rest as defaults and click the “Submit” button. This will build a custom version of the student ebook for your students and it will have a unique URL and course name. You will be listed as the instructor and can look at the log files and view other information on the instructor page (you can get to this by clicking on the icon that looks like a head and shoulders and the top right of your screen when you are in the ebook).
I recently moved offices. In the process of packing and pitching, I found the above editorial from the Georgia Tech student newspaper. Dated September 2002, it urged the faculty in the Liberal Arts, Architecture, and Management Colleges to reject the newfangled Media Computation class that was being proposed.
I had heard the argument being made in the editorial before, and continue to hear it today. The argument is that we do our students a disservice if we don’t give them “real” computer science. The editor cited above is arguing that all students at Georgia Tech deserve the same high-quality computer science education. If we don’t give them the “real” thing, if liberal arts and management majors aren’t getting the same thing as CS majors, they are only getting “CS lite.”
That phrase “CS lite” gets applied to our BS in Computational Media regularly. (See the blog post where I talk about that.) Which is funny, because all but one of the CS classes that CM majors take are the same ones that CS majors take. Georgia Tech CS majors take many more credit hours than other majors (including CS majors at other institutions), and the CM major has enough CS courses to be ABET accredited as a computing program. So, what’s “lite” about that? Are other schools’ BS in CS programs “Georgia Tech CS lite” because they have fewer credit hours in CS?
Media Computation wasn’t lite. It was different. MediaComp didn’t cover everything that the intro course for CS majors did. But the course for CS majors didn’t cover everything that MediaComp did. In fact, after a few years, the CS instructors complained that our CS majors didn’t know about RGB and how to implement photo effects (like how to negate an image, or how to generate grayscale from a color picture) — which non-CS majors did know! Content on media got added to the CS majors classes.
Computational Media isn’t CS lite. It’s CS different. The one course that’s different between CS and CM is the required course on computer organization. CS majors take a course based on Patt and Patel’s book. CM majors take a course where they program a Nintendo Gameboy. The courses are not exactly the same, but have a significant overlap. We did a study of the two courses a few years ago and published a journal paper on it (see link here, and article is on my papers page). There was no significant difference in student learning between the two courses. But the CM majors liked their course much more. Now, there are projects on programming the Gameboy in the CS majors classes, too.
Different is good. Different is where you invent new things. Some of those new curricular ideas helped CS courses. Some of those different ideas stayed in the CM and MediaComp courses. Those courses serve different populations and different needs. Not all of it was appropriate or useful for CS majors.
Just because there is difference doesn’t mean that it’s lite. Do we call mechanical engineering “physics lite”? Or chemical engineering “chemistry lite”? I’m sure that there are people who do, but that’s disparaging to the difference and diminishes the value of exploring different combinations of subject areas. Valuing different combinations with computing is a particularly important idea for computer science, because interdisciplinary computing degrees are the only ones where the percentage of women majors are growing (see RESPECT report here). We should value interdisciplinary courses and programs because it’s good for our students and for diversity. We should not disparage the CS + X perspectives as “CS lite.”
Lecia Barker had a terrific paper in SIGCSE 2015 that I just recently had the chance to dig into. (See paper in ACM DL here.) Here’s the abstract:
Despite widespread development, research, and dissemination of teaching and curricular practices that improve student retention and learning, faculty often do not adopt them. This paper describes the first findings of a two-part study to improve understanding of adoption of teaching practices and curriculum by computer science faculty. The paper closes with recommendations for designers and developers of teaching innovations hoping to increase their chance of adoption.
I’ve published in this area before. Davide Fossati and I wrote a paper about the practices of CS teachers (based on interviews with about a dozen CS university teachers): how they made change, what convinced them to change, and how they decided if the change worked. (See blog post about this here.) The general theme was that these decisions rarely had an empirical basis.
Lecia and her co-authors went far beyond our study. She interviewed and observed 66 CS faculty from 36 institutions, explicitly chosen to represent a diverse set of schools. The result is the best picture I’ve yet seen of how CS faculty make decisions.
Lecia found more evidence of teachers using empirical evidence than we did, which was great to see. But whether students “liked” it or not was still the most critical variable:
On the other hand, if students don’t “like it,” faculty are unlikely to continue using a new practice. At a public research university, a professor said, “You can do something that you think, ‘Wow! If the learning experience was way better this term, the experiment really worked.’ And then you read your teaching reviews, and it’s like the students are pissed off because you did not do what they expected.”
Lecia discovered a reason not to adopt that I’d not heard before. She found that CS teachers filter out innovations that didn’t come from a context like their own. Those of us at research universities are filtered out by some teachers at teaching-oriented institutions:
Faculty trust colleagues who have similar teaching and research contexts, share attitudes toward students and teaching, or teach similar subjects. In describing what conference speakers he finds credible at SIGCSE, a professor at a private liberal arts university acknowledged, “I do have the anti- ‘Research One’ bias. Like if the speaker is somebody who teaches at <prestigious public research university>, the mental clout that I give them as a teacher—unless they’re a lecturer—I drop them a notch. When someone stands up to speak and they’re from a really successful teaching college <names several> or universities that have a real reputation of being great undergraduate teaching institutions, I give them a lot of merit.”
The part that I found most depressing (even if not surprising) is that research evidence did not matter at all in adopting new ways to teach:
Despite being researchers themselves, the CS faculty we spoke to for the most part did not believe that results from educational studies were credible reasons to try out teaching practices.
Lecia’s study is well done, and the paper is fascinating, but the overall picture is rather dismal. She points out many other issues that I’m not going into here, like the trade-off between cost and benefit of adopting a new practice, and about the need for specialized equipment in classrooms for some new practices. Overall, she finds that it’s really hard to get higher education CS faculty to adopt better practices. We reported on that in “Georgia Computes!” (see post here) but it’s even more disappointing when you see it in a large, broad study like this.
The New York Times weighs in on the argument about active learning versus passive lecture. The article linked below supports the proposition that college lectures unfairly advantage those students who are already privileged. (See the post about Miranda Parker’s work for a definition of what is meant by privilege.)
The argument that we should promote active learning over passive lecture has been a regular theme for me for a few weeks now:
- I argued in Blog@CACM that hiring ads and RPT requirements should be changed explicitly to say that teaching statements that emphasize active learning would be more heavily weighted (see post here).
- The pushback against this idea was much greater than I anticipated. I asked on Facebook if we could do this at Georgia Tech. The Dean of the College of Engineering was supportive. Other colleagues were strongly against it. I wrote a blog post about that pushback here.
- I wrote a Blog@CACM post over the summer about the top ten myths of computing education, which was the top-visited page at CACM during the month of July (see post here). I wrote that post in response to a long email thread on a College of Computing faculty mailing list, where I experienced that authority was able to sway CS faculty more than research results (blog post about that story here).
The NYTimes piece pushes on the point that this is not just an argument about quality of education. The argument is about what is ethical and just. If we value broadening participation in computing, we should use active learning methods and avoid lecture. If we lecture, we bias the class in favor of those who have already had significant advantages.
Thanks to both Jeff Gray and Briana Morrison who brought this article to my attention.
Yet a growing body of evidence suggests that the lecture is not generic or neutral, but a specific cultural form that favors some people while discriminating against others, including women, minorities and low-income and first-generation college students. This is not a matter of instructor bias; it is the lecture format itself — when used on its own without other instructional supports — that offers unfair advantages to an already privileged population.
The partiality of the lecture format has been made visible by studies that compare it with a different style of instruction, called active learning. This approach provides increased structure, feedback and interaction, prompting students to become participants in constructing their own knowledge rather than passive recipients.
Research comparing the two methods has consistently found that students over all perform better in active-learning courses than in traditional lecture courses. However, women, minorities, and low-income and first-generation students benefit more, on average, than white males from more affluent, educated families.
The linked blog post below bemoans the fact that the AP CS is growing, perhaps at the expense of growth in AP Statistics. AP Stats is still enormously successful, but the part of the post that’s most interesting is the author’s complaints about what’s wrong with CS. I read it as, “Students should know that CS is not worthy of their attention.”
It’s always worthwhile to consider thoughtful critiques seriously. The author’s points about CS being mostly free of models and theories is well taken. I do believe that there are theories and models used in many areas of CS, like networking, programming languages, and HCI. I don’t believe that most CS papers draw on them or build on them. It’s an empirical question, and unfortunately, we have the answer for computing education research. A recent multi-national study concluded that less than half of the papers in computing education research draw on or build on any theory (see paper here).
Though the Stat leaders seem to regard all this as something of an existential threat to the well-being of their profession, I view it as much worse than that. The problem is not that CS people are doing Statistics, but rather that they are doing it poorly: Generally the quality of CS work in Stat is weak. It is not a problem of quality of the researchers themselves; indeed, many of them are very highly talented. Instead, there are a number of systemic reasons for this, structural problems with the CS research “business model.”