Programming as a second language

A recent article in ACM Inroads caught my attention after it was posted and discussed on the Computer Science Education: Research & Practitioners Facebook page. The article, which is quite a long read, discusses a paper published back in 2014 about an fMIR study that showed when students were trying to understand a piece of code, the parts of their brain that activated were the parts of the brain associated with language, not the parts of the brain associated with math and logic. The author of the Inroads article, a high school computer science teacher by the name of Scott Portnoff, takes aim at computing education and holds no punches in attacking the historical teaching practices as well as current efforts to broaden exposure to CS in secondary education through survey courses that don’t actually teach programming skills. It’s an interesting read.

What really got my attention though, was this main idea that learning to program is like learning a second language. As I read through the article, I saw a lot of parallels between what is considered best practice in second language acquisition, and what we have done with our fully flipped, lightweight teams, active learning intro programming classes. Here I’m going to highlight four findings from the article and how they fit with what we are doing in remaking our programming courses.

  1. The traditional prescriptive linguistics approach to teaching a second language (by teaching the grammatical structure) was abandoned decades ago because it is less effective than implicit, immersive approaches. In our media computation-based CS1 class, we spend the first month leading students through engaging programming labs with very detailed instructions on how to make Turtles draw fun pictures on screen. We don’t mention objects, classes, methods, variables or any other programming constructs, but we get students to learn how to make the turtles do fun stuff and increasingly encourage them to play with the code to make the turtles draw more interesting pictures. After the first month, we start explaining the concepts behind the code. By then students have already been programming, but they aren’t bored or turned off. They’ve been immersed in something enjoyable, and as we explain what a method is, they have a non-abstract example (turtle draws hexagon with these separated 6 lines of code) that helps them to understand the concept and it’s usefulness.
  2. Learning a second language takes time. Our students come in with widely varying backgrounds in terms of how much programming they have previously done and the students who have more experience fare better (this has been empirically demonstrated with a lot of studies as well). So, it’s really important to set appropriate expectations for students who haven’t programmed before – we tell them repeatedly that learning this simply takes time, and they shouldn’t expect to be able to be awesome programmers after a single semester. This is also why I consider the Data Structures course (which is the third course taken by our majors) to be a continuation of intro programming. If you study a second language at university as your major, you have to take four semesters of that language before you are considered to have achieved some level of competency and fluency.
  3. Learn a second language deeply before trying to learn a third. Students who gain full competency and fluency in a second language can pick up a third language more easily than students who try to pick up a third language when they only have minimal acquisition of a second language. Similarly, it doesn’t make sense to change programming languages in the middle of learning to program. When I arrived at UNCC, the standard programming sequence taught was a first course in procedural C++ followed immediately by a second course in object-oriented Java, after which students are expected to be able to do basic programming. This is like thinking a student should study a semester of French (an indo-european language) and then a semester of Mandarin (a sino-tibetan language) and have proficiency in speaking foreign languages. Moving from procedural programming to object-oriented programming is hard. Moving from one programming language to a second programming language, when you haven’t had time to master the first one, is confusing. Combining these two things together is a disaster.  Of course we want our students to be able to learn other programming languages, but this is likely to be easier if they have acquired deep competency in their first programming language. What that language should be is an entirely different discussion. When we developed our flipped, lightweight teams series of courses, they have all been taught as objects-first Java.
  4. Practice. This is an element of secondary language acquisition that is really important. Students need to practice using the language frequently in order to gain competency. The flipped, active learning approach involves in class activities (peer instruction quizzes, parsons problems, etc.) that give students small bits of practice looking at code (reading), talking about code (listening and speaking), and producing code (writing). In a traditional lecture and lab class, students only get practice with the reading and writing part in the lab. They may get some practice listening to one person (the instructor) while in the lecture. With our team-based version of the class, where they spend 3 hours a week in class talking with others about programming, and reading and writing programs plus 3 hours a week in lab doing pair programming exercises, they are doing all of these fundamental practice activities (reading, writing, listening and speaking) much more frequently.

One aspect of the article that I found really interesting was that the author claims to have had good success in getting students to learn programming by forcing them to memorize small programs or code segments. The idea is that by memorizing these, students internalize the structure. He says that after doing this, the number of syntactic errors students make is greatly reduced, and presumably this means that they can then focus more on understanding the semantic meaning of programs. This is not something that we have tried. I have to admit, forcing memorization doesn’t sound fun. So, I’m going to think of a way to implement this so that it is fun. Perhaps this is a good candidate for gamification.

Counting Friends

We try to measure so many things, but we are aware that measuring things in academia can incentivize perverse behavior and lead to weird side-effects. So, I’ve decided to measure something that isn’t commonly cared about in education and I’m hoping that measuring this objective and incentivizing its maximization will lead to a (non-perverse) side-effect of happier students and increased learning.

When I first revamped our CS1 course and turned it into a fully-flipped, active learning, lightweight teams version of Guzdial & Ericson’s Media Computation course, I noticed a huge difference in the community atmosphere inside the classroom. The team-based approach works really well, especially in that first year when students are really trying hard to make friends and fit in. After observing this in the first semester of the course, I decided that I wanted to start measuring it, and so in the anonymous final course feedback in subsequent semesters, I asked the following question:

friends_question

The first few terms this class was taught, we created lightweight teams with 5 people per team. In subsequent semesters that number has varied, based on classroom setup, but it has always been between 4 and 9 in our flipped classes.

Here are the results from the first term we collected this data in 2013:

NewFriendsFeedbackFall2013

What you are seeing here is that more than 60% of students in the class reported making 5 or more new friends. This, to me, is critical. It means students feel accepted, normal, part of the group. It means that when they get to harder courses, they have a support network. I expect it increases their likelihood to graduate.

In later courses where I adapted the same model and in later sections of that same intro course, we had different classrooms with different layouts that led to some larger team sizes. In my flipped, team-based Data Structures course, I’ve sometimes had students at tables of 9, though split into two teams of four and five, but often really working together as a larger team. Thus, I changed the friends question to be more granular. The graphs below represent ‘friends’ data over three semesters of the flipped Data Structures course.

friends--semester

These bar charts represent percentages of students in each semester who made a particular number of friends, but the absolute data is at the top of each bar. In Fall 2016, we had 32 (of 67) students respond to this question, in Spring 2017 we had 36 (of 56) students respond and in Fall 2017, we had 100 (of 114) students respond. What we see here is that the first semester was a bit rocky, but over all semesters, most students are making at least a few friends, and some are making a lot of friends.

We can also look at this by sex. The following graph averages over the three semesters of the class.

friends--gender

What we see here is that female students are making friends, but not typically lots of friends. There aren’t many female students in each of these sections, so these females are likely making friends with each other and with the guys in the class. What is important here is that most female students are making at least one friend and having even one friend can make a huge difference in feeling supported and like you belong.

friends--race

This graph, which looks at students by race over the three semesters, is tricky. First of all, it completely ignores intersectionality. And, the categories of ‘N/A’ and ‘other’ are hard to parse. What I do see here is that African-American students do seem to be making friends in class, at similar rates to Asian and white students, but Latinx students are not making as many friends. This is troubling. If my Lightweight Teams approach is helping most students make friends and feel supported, but not Latinx students, I want to know what is going on. I don’t have an answer here, but because I collected the data, at least I can ask the question.

The ‘friends’ question has been adopted into the final course feedback surveys used by a number of faculty in our college who are adopting active learning and team-based approaches. What we measure impacts what we optimize. And counting how many friends our students make means that we will try to optimize the social atmosphere of our classes. However, we have a whole set of goals and our institutional governing body likely doesn’t care about this. We are a state school, and they want to know about retention and graduation rates. As a college we also care about diversity and inclusiveness.

We might be able to increase the friends count if we put students who were like each other all together all the time. But that would inversely impact our diversity and inclusiveness goals. I’m not afraid that the ‘counting friends’ measurement will lead to major perverse side-effects because it is a tertiary measurement. I am hoping that it allows our faculty to be more balanced in pursuing the primary objectives of retention and graduation and remember that our students are also here to become social citizens that engage in our multicultural society.

An all girls team in a CS course?

I teach a course with 76 students and 7 of them are female students. My course is flipped: during class time groups of students are working on various activities, using lightweight teams for practicing the concepts in the lecture on some days and project based teams for applying the concepts to project assignments on other days. I suggested an all girls project team to each of the female students via individual email messages, and each of them said no! One of the female students wanted to know why I would even suggest this.

Why did I ask them such a question? Well, I use reflection questions to provide the students an opportunity to think about themselves as part of a team. In a response from a female student, she said she doesn’t talk much in the team meetings, probably because she is the only female on the team. So, I thought I could make sure there is more than 1 female student on any team that has female students, or, I could suggest an all girls team.

Why an all girls team? The project teams are designing the user experience for an app that would engage people to make Charlotte a better city – sponsored by the City of Charlotte. This app will be implemented if the City sponsors like it. Our course is an HCI course and we are to design the user experience, not to build the app. I thought that an all girls team would come up with a user experience that would be different to an all boys team.

Why did every single female student say no to the idea of an all girls team? Some said that they had already started in a team with male students and they thought their team was doing well. Some said that didn’t think it reflected what they would experience in their career and preferred to learn how to be in a team where they are the minority.

Needless to say, I didn’t create an all girls team in this course. Maybe next year I can start that way, but I am not sure if it will have the effect I am looking for.

I had a similar situation with advising: a Professor that is an advisor for over 100 students, has received awards for their excellent advising, and is a person of color, suggested that our students of color should be assigned to their list of advisees. I liked this idea, but when I asked other faculty, they emphatically said “no!” Why would we single them out? Should we give the white male students white male advisors? Should we give the Asian students Asian advisors? I want to repeat that this suggestion came from a person of color, and that the faculty saying “no!” are not people of color. There are no other advisors that are persons of color.

Should we create all girls teams for design courses? Should we assign students of color to advisors that are people of color?

 

And now for something completely different….

Hi, I’m the Lead Evaluator in the Center for Education Innovation (CEI). You may be asking, ‘what’s an evaluator?’ My parents asked me how to describe my job to their friends- and how on earth it relates to my degree in counselor education.  Let’s start with evaluation; I’ll save the counseling piece for another day.

Evaluation is an ugly word in my opinion, and I do think the field needs a new term, but that’s also another day, another forum. Evaluation implies external judgement, and in fact, that is exactly what it’s designed to be. Entities that fund projects want to know if their investment is/was worthwhile, and therefore they need an evaluator to make that determination. An evaluator develops measurements and deploys tools via the scientific method to gauge whether or not a project has merit. These surface definitions are incomplete, and can be misleading as to what the true nature and purpose of evaluation is. In fact, these terms are laden with implications about power- who has it, how is it used. As we know, judgement is in the eye of the beholder so to speak. The good news is that the field of evaluation is evolving, becoming more aware of the implications about power within its practices.  This evolution is similar in some ways to the shift toward active learning in computing pedagogy, which is the awareness that one size of teaching doesn’t fit all students.

Because I am not value free, as no one can be without bias of some form or another, I subscribe to two newer theoretical models of evaluation: empowerment and participatory. In my view, the common theme between these two approaches is the intent to engage the people involved in and impacted by the program (being evaluated) into the evaluative process. These models are dramatic shifts from the ‘evaluator as expert’ approach, which places the power of value judgments in the hands of evaluators (who are supposedly detached and objective).

Ok, so what? (My dissertation advisor repeatedly asked this question- and for which I am now grateful- thanks Jack!)  In terms of evaluating computing pedagogical approaches, the empowerment and participatory models mean that the voices of students, faculty, and the community are equally important in deeming the value of teaching strategies and the quality of learning experiences. In other words, experts who are detached from the real experiences of participants are not making the value determination, instead, the collective community is judging. As evaluation is not ‘done to people’ (Patton, 1990) in these models, education is not something that is performed on students. A central mission of the CEI is the scholarly investigation of computing pedagogy, to test out new ways of teaching computing that differ from the  traditional view of computing education as lecture plus lab, sink or swim.  Some of these new ways of teaching have already been presented in our blog, and I refer to them broadly as engagement pedagogy. These teaching practices are engaging because they create interactive space in the classroom, where students and faculty work together. This is very different from the ‘sage on the stage’ approach, which, like the ‘evaluator as expert’ model, creates power barriers. See these sources for discourse on power distance. As an evaluator, I seek to hear from many voices about perceptions, experiences, outcomes, not just the ‘resident experts.’ In engaging computing pedagogy, we seek to include the students who have often been overlooked in this discipline. Together we seek inclusion, and reduction of institutional bias that unconsciously suppresses the voices of the already marginalized populations in our society.

Onward we go.

To Categorize, or Not To Categorize, That is The Question (Part 1)

In my last post, I talked about categories, particularly race and gender. Let’s dive farther into the general idea of categories this week.

Our brain’s ability and need to categorize serves a base function in our day-to-day lives. Think about the sheer VOLUME of information your brain processes in nanoseconds–size, shape, smell, taste, color, texture, temperature, time, weather, movement, etc–often below any real level of our awareness. This rapid processing helps us navigate our complex environment with efficiency and, arguably, a fairly high degree of learned accuracy.

Let’s say you’re out for a stroll. It’s a beautiful day in your neck of the woods. The sun is shining, nary a cloud in the sky. You keep seeing these tall (size!) things with green tops (color!) and black/brown/gray stems, some smooth, some rough (color! texture!). While their tops rustle in the gentle breeze (weather! movement!), their columnar stems (shape!) appear stationary (lack of movement!). Now, if you’ve been on this big, blue marble of ours for even a relatively short period of time, you probably know that these things are what we have collectively categorized as “trees”. And in your experience with trees, you expect them to “appear” and “behave” a certain way when you encounter them, even if they don’t all look exactly the same. So unless you’re strolling through Middle Earth or the Land of Oz where trees can speak and move, you learn to reasonably expect trees to appear and behave consistently, regardless of context (excepting an external cause perhaps, like a tornado).

Your individual understanding of trees is learned via others as you make sense of the world. Now, you could assert your individuality and define and label trees per your own preferences, but effectively communicating with your fellow humans about trees requires a shared understanding of “what a tree is”. In other words, “what a tree is” is socially constructed. While trees existed long before humans evolved, they were so named and defined by us. It was through the process of human interaction that trees were thus categorized. To wit, we have collectively agreed that there are such things as trees and we have collectively agreed on what trees are.

This collective agreement applies to everything in our world. We have ascribed shared meanings and definitions to tangibles, such as bananas and mouse pads, as well as intangibles, such as reputation and cultural heritage. We can touch, smell, and taste bananas (at least for the near future), but “banana” as a shared concept is a social construct, identified by its size, shape, color, taste, texture. While we can’t touch, smell, or taste reputations, “reputation” as a shared concept is also a social construct. We typically know what differentiates a “good” reputation from a “bad” one and that while it can take a long time to build good reputations, they can be ruined in a matter of minutes.

Good so far? Everybody with me?

Now for the BIG REVEAL…drum roll please…

Race and gender are also socially constructed.

“WHAT?!?!”

“But Tonya,” you might be thinking, “men and women are biologically different! And skin color varies due to the amount of melanin in the epidermis!”

Indeed.

But the categorical meanings we have collectively ascribed to those differences and variations are all socially constructed. “What a man is” versus “what a woman is” are shared concepts we have constructed through social interaction.

“Gotcha. So if we collectively define things such as trees, bananas, reputations, and gender through our interactions with one another, then we can be nearly certain that our social constructs are ‘correct’ and ‘right’, right? Wisdom of the crowd and all that?”

Sometimes. But we’ve made our share of collective mistakes over the centuries. A geocentric universea flat earthseparate but equal, to name a few.

So then, what if our collective beliefs about race and gender are wrong too?

Til Part 2.

With profound apologies of oversimplification to arborists, cognitive psychologists, linguists, sociologists, anthropologists, J.R.R. Tolkien, L. Frank Baum, and others. And though he wasn’t referenced, I feel obligated to acknowledge Joyce Kilmer.

Let’s Talk Intersectionality

How do you categorize yourself? Do you think of yourself primarily in singular terms of gender and race, such as “I’m a man” or “I’m a person of color”? Do you ever think about how your categories overlap? Let’s take me, for example. I’m a woman. And I’m white. While I’m frequently aware of my gender in my day-to-day life, I rarely think about my race (which we’ll unpack in a future post). But my experiences as a woman are informed by my race, even if I’m not always aware of it. So a more nuanced way to describe myself would be as a white woman and acknowledge that I exist in both categories simultaneously–that is, my gender and race categories intersect with one another and that particular intersection shapes my life and experiences.

Historically and conceptually, we have treated race and gender as separate categories. Think about the troubled arc of US history for a moment. The anti-slavery and abolition movements that gave way to the 20th century civil rights movement and to today’s Black Lives Matter movement focus(ed) their efforts on dismantling systemic racism. In a similar vein, the women’s suffrage movement of the 1850s-1910s gave way to second wave feminism in the 1960s and the failed ratification of the Equal Rights Amendment in the 1970s, with their efforts focused on dismantling systemic sexism. While the two movements have overlapped at times, their respective efforts have been separate more than they have been unified.

This bifurcation of race and gender is not simply an inadvertent byproduct of the civil rights and women’s movements. It is also reflected in US legislation and labor laws. When the US Congress passed the Civil Rights Act of 1964, Title VII of the Act prohibited employment discrimination based on race, color, religion, sex, and national origin. On the face of it, this was a fantastic, historic, and long overdue moment! Despite good intentions, however, the law’s treatment of race and gender as separate categories actually reinforces the very things it seeks to eradicate–racism and sexism–because the law simply cannot fathom that people can exist in more than one category at one time!

Let’s look at this succinct summary of a 1976 employment discrimination case (Degraffenreid v. General Motors) to unpack this a bit:

The gist here is that General Motors had been hiring white women to work in administrative positions, and hiring Black men to work in industrial positions, but not hiring Black women at all. A group of Black women sued General Motors under Title VII of the 1964 Civil Rights Act, alleging that they had been discriminated against on the basis of race and gender—which seems like a no-brainer, right? But incredibly, they lost the case: the US District Court found that, because General Motors had hired (white) women, the company wasn’t discriminating on the basis of gender, and that because General Motors had hired Black people (who were men), the company wasn’t discriminating on the basis of race. This might be one of the Top Ten Most Facepalm-Worthy Rulings of the last 50 years, but that’s seriously how it played out: the court simply refused to wrap its collective head around the fact that neither “women” nor “Black people” is a uniform group with uniform experiences (Boesel, 2013).

In short, the law could not recognize the unique experiences of women of color as determined by their specific intersection of race and gender, rendering them invisible (see Crenshaw, 1989).

OK, Tonya. I think I get the gist of what intersectionality is about. But why are you talking about this on an “Innovations in Tech Education” blog?

Over the last several years, there have been numerous efforts to “broaden participation” in STEM. Widely embraced by computer science education researchers and practitioners, “broadening participation” is commonly considered an acknowledgment of and a means to rectifying the lack of diversity in CS. I’m an organizational scientist and a critical theorist. Part of my research examines the failures of diversity and inclusion initiatives across sectors, organizations, and institutions and the potential for intersectional theory and methods to remedy these failures. My focus on this ITE blog will be to thus engage thought, reflection, and discussion around broadening participation in CS through a critical, intersectional lens. In the sage words of Audre Lorde, self-described “black feminist lesbian mother poet”:

“There is no such thing as a single-issue struggle because we do not live single-issue lives.”

References

Boesel, W. E. (2013, April 3). Difference without dualism, part III (of 3). The Society Pages: Cyborgology. Retrieved March 5, 2018, from https://thesocietypages.org/cyborgology/2013/04/03/difference-without-dualism-part-iii-of-3/

Crenshaw, K. (1989). Demarginalizing the intersection of race and sex: A black feminist critique of antidiscrimination doctrine, feminist theory and antiracist politics. U. Chi. Legal F., 139.

 

Patterns of Problems in CS education: perspectives from a reformed lecturer

After several decades of teaching computing using lectures, I am a reformed lecturer and only teach based on the principles of active learning. This does not mean that I do not include lectures as part of my teaching tools. It means that I have come to appreciate the benefits of starting from the concept of active learning, rather than starting from improving engagement during my lectures. This appreciation was realized when we adopted the concept of pedagogical design patterns to identify best practices in our active learning in CS education. A design pattern is a generalized representation of pairs of problems and solutions. Design patterns appeal to those that want to improve their teaching by addressing the problems they experience in practice. Design patterns are also an easy way to describe how to fix specific aspects of the teaching and learning experience: describe a specific problem (students fall asleep in lectures) and a simple solution (keep the lecture short and interspersed with activity).

We decided to compare our active learning patterns to other pedagogical design patterns in CS education and found that a majority of the published patterns are about improving lecture-based teaching. On closer inspection, we saw that many of the same problems appeared in the lecture-based patterns as in our active learning patterns: students don’t remember what they hear in a lecture, students come unprepared to the lecture, students don’t pay attention in a lecture. The difference is that the patterns for lecture-based CS education are about improving the lecture. The solutions in our patterns have a different starting point: make it social. Engage the students in activities that lead to the social construction of knowledge with their peers.

If you start with the premise that active learning is about enabling the students to learn from and with each other, then you think more deeply about setting up the classroom experience to be about activities that rely on communication and interaction among students. This leads to ideas such as lightweight teams, mini lectures on demand, and peer pressure for students to do the preparation before they come to class.

Gender-Paired Programming

Our College offers a variety of CS1 sections, including the fully flipped, active learning, team-based, media-computation version that I designed (with the help of Bruce Long). All CS1 sections have a lab component, but in our version, we do gender-paired programming. There’s a lot to unpack when you talk about this, and in this post I will explain our rationale for doing this and detail how it works.

Learning how to program is a skill. Think about something that you are really good at, and you will realize that the way you became good at it is by doing it a lot. In order for students to become good at programming, they need to do a lot of programming. Now, this might be an argument for forcing students to do programming labs by themselves, but the research has shown that pair programming, when done well, is really helpful. By talking through the programming tasks with another person, a student is forced to think about why a particular solution may or may not work. With two people, there is less of a chance of getting totally stuck. Sharing multiple perspectives helps students see that there are often multiple ways to approach a programming problem. So, having students pair program theoretically gives them half the practice they need, but also gives them the benefits of multiple perspectives and discussion.

But, a problem happens when one person in the pair takes over and does all the programming, and the other person just sits and watches. Of course, this can happen with any two people, but what I observed and had several people report to me, is that this often happens in intro programming courses when a guy and a girl are paired up together. In this situation, the guy takes over the keyboard and the girl sits on passively watching the guy do the programming exercises. This is highly problematic for a number of reasons. Typically, women come into our program with less programming experience and exposure then men (not always, but typically). So, when this happens, the guy gets more practice and exposure and the girl gets less. So, the experience gap between them widens instead of shrinking.  Over time, that experience gap becomes worse and worse. I’ve met female CS majors who have told me they don’t know how to program because this happened to them.

Now, one can ask all sorts of questions about this phenomenon. Why is it happening? Why don’t the female students demand their fair share of time? Why are the male students acting this way? Here are my thoughts:

  1. Females are socialized to be less assertive and more passive. So, if a guy takes over a work task that is supposed to be shared, we tend to just let it happen. It seems rude to fight about it or protest.
  2. The guys are sometimes trying to show off, which is something they are socialized to do. Male programming partners tend to assert, as one female student described, “their very masculine programming skills”.
  3. The freshmen female students tend to be under-confident in their programming skills, and the freshmen male students tend to be over-confident in their programming skills (again, not always – but this is fairly typical). So, it makes sense that the more confident student would tend to dominate the keyboard.
  4. The students all want to get finished and do well. If the guy says something like, “Hey, I know how to do this, so we can be done quickly and get full points”, why would his female lab partner argue with that?
  5. The guys are NOT intending to do damage to their female lab partner’s career in tech. I don’t believe that this is typically done with an intention to harm. I have a lot of trouble imagining male CS students thinking to themselves, “Hmm. I think I want to derail her career in tech, so I’m going to purposefully not share the keyboard.” Most male CS students are probably pretty happy to have any girls in their classes.

To avoid these issues, we pair students up by gender in our CS1 lab. We don’t do this in later classes. This is not about keeping the guys and girls separate forever, after all, that wouldn’t reflect the real world. We do this only in the first class. It’s a chance to get everyone comfortable working on pair programming and sharing the load. We hope that after the first semester experience, the programming ability is a bit more evened out and the female students have more confidence in their abilities.

How does it work? We assign lab partners every week. Students work with the same partner for two weeks in a row. The two-week duration is to give students a chance to get to know each other enough to possibly develop a friendship, but it is not so long that if the two students don’t really hit is off, there is tension, or there is too much of an ability gap between the two students, it won’t be damaging or annoying. So, we keep a roster of female students and a roster of male students and pair them up with partners of the same gender. If a student is gender fluid, they get to choose which group they would be most comfortable with.

We need more research in this area. And, I would contend that this phenomenon happens sometimes between two male programming partners and between two female programming partners, typically when there is a wide experience gap. As faculty wandering around in labs, we should be watching for this and talking to the partners about the importance of really sharing the keyboard.

Improving the team experience with reflection questions

We all struggle with how to enable a positive experience for students in teams. Here I explore how reflection may provide a way for students to understand their own experience so they can make it more positive.

One of the hallmarks of effective active learning in our College is the concept of lightweight teams. These are teams in which students are placed in groups before the first class, given seating assignments for the semester, and the impact of the team performance on their grade is small. The term “lightweight” implies the low impact on the individual final grade. The intention is to reduce the stress of students who worry about having people on their team that know a lot more or a lot less than they do. The benefit of lightweight teams is that it encourages students to get to know each other while engaging in activities related to the concepts being taught in the class. At the end of this post are some publications that describe the benefits of lightweight teams in more detail.

Lightweight teams are effective in introductory classes but at some point, the learning about how to be effective in a team needs to transfer to teams in which the stakes are higher. These high-stakes teams are the more traditional use of teams in education. The literature on forming teams is pretty well established.  Students can be placed in teams randomly, algorithmically, or by self-selection. Regardless of whether you are forming lightweight teams or high-stakes teams, many factors can get in the way of a positive team experience such as differences in work ethic, personality, and ability.

To address potential problems with teams, I introduced a reflection survey in my HCI class. The reflection survey consists of 9 open ended questions that the students answer as individuals during a class period. There is no grade associated with the reflection – it is a class activity that allows me to record attendance. The questions are intended to have the students reflect on their experience in the team, not to give the instructor feedback on the quality of their work. The premise is that just answering the questions will change the students’ behavior in a team. Here are the questions:

  1. Do you have trouble remembering the first names of the members of your team? Which names do you remember now?
  2. Who in your team talks the most during team meetings in class? Who talks or communicates the most outside class?
  3. How would you describe the collaborative style of your team? For example: the team waits until the last minute to finish, the team gets things done as quickly as possible, the team does a lot of the preliminary work for the final report ahead of time.
  4. Do you feel like you talk as much as you would like in team meetings?
  5. Do you feel like you talk as much as others, or more than others?
  6. Do you feel like your team works together, or works separately and combines the work after?
  7. Do you feel like you are part of the team? Why?
  8. How do you feel about the quality of the work your team does?
  9. Do your team members like the quality of the work you do for this project?

Students are not very self-aware of their behavior in teams and the reflection questions asked them to think about names, how much they talk and contribute, and how they liked the quality of the work the team produced. Asking the questions was more about asking the students to be self-aware than about the instructor using the answers to change the formation of teams.

Here are some of my favorite answers (names are changed to preserve anonymity):

  • I usually struggle with names but I know everyone’s name in this group. I’m absolutely terrible with last names though. I remember Donald, Keifer, Kay, and Peter.
  • I like them overall, although John’s contribution to the team I wonder about. Other than that, everything is good and I really like my team; John included.
  • I do not feel I talk as much as I may in other team meetings, and I think it’s because I am the only girl in my team. While the guys in my team are nice, I would probably feel more comfortable with at least one other girl on the team.
  • I do not feel like I am fully a part of the team. I feel that way due to my absence in the last class that this team met. I feel as though they may think I’m a slacker because of it. I just do not feel like opening up as to why I was not here.
  • As I have gotten to know my team better I talk frequently to contribute my ideas.
  • I feel like I talk the least in my group and I would like to change that.

I have the students answer these same questions 3-4 times during the semester, even though they are in the same teams. The changes in answers show that the feelings about the team experience improves. The students get better at remembering names and there is a better distribution of talking.

Publications related to Lightweight Teams:

Latulipe, C., Long, N. B., & Seminario, C. E. (2015). Structuring flipped classes with lightweight teams and gamification. In Proceedings of the 46th ACM Technical Symposium on Computer Science Education (pp. 392-397). ACM.

Stephen MacNeil, Celine Latulipe, Bruce Long and Aman Yadav. (2016). Exploring Lightweight Teams in a Distributed Learning Environment. In Proceedings of the 47th ACM Technical Symposium on Computer Science Education (pp. 193-198). ACM.

Maher, M. L., Latulipe, C., Lipford, H., & Rorrer, A. (2015). Flipped classroom strategies for CS education. In Proceedings of the 46th ACM Technical Symposium on Computer Science Education (pp. 218-223). ACM.

The problem with traditional CS Ed

I have a contention. It might be considered controversial by some. Others might think what I am saying is obvious.

Traditional computer science programs and old-school computer science professors have not been teaching computer science. They have been giving course credit and granting degrees to a small set of stereotypically nerdy students (mostly white and asian males) who have been teaching themselves computer science in their spare time because it is their passion. Those students are great and we want them in our programs. However, there are not enough of those students to fill the jobs and create all the technology that is needed to solve the world’s problems. We need many people doing computer science to work in our information economy and to hopefully make the world a better place. And there are many people, across gender, race and ability spectrums, who have the intellectual capability to do CS. But, these other people also have other interests and they are not going to spend all of their spare time teaching themselves CS.

It is our responsibility as computing educators to actually teach computer science to our students, in the classroom. We have to acknowledge that a larger and more inclusive community is going to include people who have other hobbies, who have other jobs, who have family commitments, and they can’t spend every waking hour teaching themselves the skills they need to be successful computer scientists. Passive lecturing to these students will not scaffold the skills and tools they need and will not give them enough practice at doing CS. It will not build their confidence, it will not help them build an identity as a computer scientist.

CS is a relatively young discipline. Many would argue that we don’t really know exactly how best to teach everything in computer science. But, we have an ever improving set of best practices with empirical research behind them. Ask any of the 1700 people who just attended the SIGCSE conference, or who attended the ICER conference last August. The problem is that only a small percentage of faculty in CS departments are actually making use of these best practices, and it is typically the teaching track faculty and lecturers. We need all faculty to understand their responsibility to adopt best practices in CS education and we need our award systems to adapt to incentivize and reward that work.

I hear faculty complain about students not knowing how to program. This is nostalgia for the privileged days in which faculty didn’t have to teach students CS because the students were teaching themselves. One of my favorite quotes sums it up: “We need to teach the students we have. Not the ones we used to have. Not the ones we wish we had. The ones who are in front of us.”

This blog is going to be about innovation and best practices in teaching computer science and informatics. I challenge all my fellow faculty members, teaching-track and research-track, to embrace this work and get to know the awesomeness that is our current set of students who really need us to teach them computer science.