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:


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:


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.


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.


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.


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.

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.

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.