Posts tagged ‘non-majors’

When do we know that a programming course is not working for non-CS majors?

There’s a good discussion going on in Facebook that I wanted to make more public and raise as a question here.  The crush of undergraduates in CS today is making it difficult to offer tailored introductory CS courses to different majors.  The problem is particularly acute when designing instruction for future CS teachers.  If you put the CS teachers in the same course as the CS majors, it’s cheaper and easier — you just teach one big course, rather than multiple smaller courses. But is it as effective?

Some of my colleagues suggest that we can design undergraduate introductory computing courses that are effective for both non-CS and CS majors.  Here’s my question: How do you know when it’s not working?  At what point would you admit that the one course option isn’t working? It’s an interesting empirical question.

Here are some possible measures:

  • Learning is a tricky measure.  For any discipline, the majors in that discipline are more motivated to learn more than the outside-the-discipline majors. You can’t expect the non-CS majors to learn more than the CS majors.  Then again, the non-CS majors probably come in knowing less.  If you do pre- and post-tests on CS knowledge, do non-CS majors have as large of a gain as the CS majors?  I don’t know, but in any case, it’s not a great measure for deciding if a class is succeeding for the non-CS majors.
  • Taking more CS courses may be an effective measure, but only if you have more than one course that’s useful to non-CS majors.  If the rest of the classes are about software development, then non-CS majors will probably not want to go on, even if the intro course was effective and well-designed.
  • Retention is a reasonable measure.  If more of the non-CS majors are dropping out from the course than the CS majors, you may not be meeting their needs.
  • My favorite measure is relevance I argued in my blog post on Monday that programming is a practice that is relevant to many communities. Do the non-CS majors see the relevance of computing for them and their community after the introductory course?  If not, I don’t think it’s meeting their needs.
  • Another tricky measure is use. Should non-CS majors be able (after their first course) to build some program that they find useful?  Certainly, if you achieve that goal, you have also achieved relevance.  How do you judge useful?  CS faculty may not be good judges of what a non-CS major would find useful, and CS faculty are most likely going to assess in terms of code quality (e.g., modularization, appropriate variable and function/module names, commenting, code style, etc.), which I consider pretty unimportant for as a measure for the non-CS students’ experience in the first course.

What do you think?  How would you know if your intro course was meeting non-CS students’ needs?

November 9, 2018 at 7:00 am 13 comments

Why programming in a non-majors, CS course is unlikely to lead to computational thinking (but is still a good idea): We must go beyond Intuition to Evidence

The March 2015 issues of Inroads (linked here) has a special section on “The role of programming in a non-major, CS course.” I was disappointed by several of the articles in the special section for making arguments without empirical evidence, and decided to write my February Blog@CACM article on the need for evidence-based practice in computing education (see post linked here).

I left out Henry Walker’s second article in the Blog@CACM post, and will discuss it here. In the first article, he argues against teaching programming because it would not leave enough time for other, more important topics. In the second one, he argues for teaching programming, if your learning objective is computational thinking.

If a non-majors course in computer science seeks to help students sharpen their skills in computational thinking, then students must be able to write solutions precisely. Further, students must be able to analyze the correctness of solutions and compare alternative solutions. Such work requires precision in writing. English or another natural language allows precision, but does not require precision.

Like in his first article, Henry offers no evidence for his claims. I do agree that programming requires greater precision than natural language. Henry argues for a value of the use of programming that is not supported by our research evidence.

If defined in sufficient detail, pseudo-code can enforce rigorous thinking, but pseudo-code cannot be run to check correctness or test efficiency. Ultimately, the use of a programming language is essential if computing courses are to help students sharpen their problem-solving skills.

In the decades of studies that have tried to find such transfer, the research evidence is that computing courses do not help students sharpen their problem-solving skills. I am not aware of studies that have rebutted David Palumbo’s 1990 review of the literature on programming and problem-solving (see paper reference here). It is possible to teach problem-solving skills using programming, but students do not gain general problem-solving skills from computing courses (with or without programming).

Henry’s evidence that this does happen is an anecdote:

An upper-level political science major who took my introductory computer science course indicated that her logical thinking in computer science had a clear payoff when she put arguments together for her papers in political science.

As a rationalization for a teaching decision, this is weak evidence. It’s self-report from a single student. The student probably did learn something interesting and useful from the class. Maybe the student did gain in logical thinking. Given the preponderance of evidence against general problem-solving skills coming from a programming class, I’m skeptical. Maybe she just saw her existing skills in a new light because of the computer science class — a useful learning outcome. In any case, is the positive experience of one student justification for designing a course for dozens or hundreds?

The conclusion of my Blog@CACM post still applies here. We don’t know what non-CS majors need or what they can learn. We shouldn’t just guess, because our intuition is very likely wrong — and it’s dangerous, since our experience (as mostly white, mostly male, CS faculty) is so different than those of most non-CS majors. We need the humility to admit that we don’t know. We must seek out evidence to inform our decision-making.

February 23, 2015 at 7:22 am 12 comments

Too little and too much self-efficacy is bad for interest

What an interesting paper! (Pun slightly intended.)  In this paper from Paul Silvia, he found experimentally that self-efficacy and interest are related on a bell-shaped curve.  Too little self-efficacy makes a task seem too daunting and uninteresting.  Too much makes the task boring.  This is important because we know that self-efficacy is among the most significant factors influencing non-majors success in learning to program.  It’s clear that there’s a sweet spot that we’re aiming for.


November 28, 2013 at 1:25 am 11 comments

A Question that Everyone should Ask their CS Professors: Why do we have to learn this?

There’s a meme going around my College these days, about the 10 questions you should never ask your professor (linked below).  Most of them are spot-on (e.g., “Did we do anything important while I was out?”).  I disagreed with the one I quote below.

One of our problems in computer science is that we teach things for reasons that even we don’t know.  Why do we teach how hash tables are constructed?  Does everybody need to know that?  I actually like the idea of teaching everybody about hash functions, but it’s a valid question, and one that we rarely answer to ourselves and definitely need to answer to our students.

Why we’re teaching what we’re teaching is a critical question to answer for broadening participation, because we have to explain to under-represented minorities why it’s worth sticking with CS. Even more important for me is explaining this to non-majors, and in turn, to our colleagues in other departments.  Computing is a fundamental 21st Century literacy, and we have to explain why it’s important for everyone to learn.  “Stuck in the Shallow End” suggests that making ubiquitously available can help to broaden participation, but we can only get it ubiquitously available by showing that it’s worth it.

I’m back from New Zealand and ICER: today, yesterday, tomorrow — days get confused crossing a dateline.  (We landed in both Sydney and Los Angeles at 10:30 am on 13 September.)  I spent several hours of the trip reading Mike Hewner’s complete dissertation draft.  Mike has been asking the question, “How do CS majors define the field of computer science, and how do their misconceptions lead to unproductive educational decisions?”  He did a Grounded Theory analysis with 37 interviews (and when I tell this to people who have done Grounded Theory, their jaws drop — 37 interviews is a gargantuan number of interviews for Grounded Theory) at three different institutions.  One of his findings is that even CS majors really have no idea what’s going on in a class before they get there.  The students’ ability to predict the content of future courses, even courses that they’d have to take, was appallingly bad.  Even our own majors don’t know why they’re taking what they’re taking, or what will be in the class when they go to take it.

We will have to tell them.

Why do we have to learn this?” In some instances, this is a valid question. If you are studying medical assisting, asking why you have to learn a procedure can be a gateway to a better question about when such a procedure would be necessary. But it should be asked that way–as a specific question, not a general one. In other situations, like my history classes, the answer is more complicated and has to do with the composition of a basic liberal arts body of knowledge. But sometimes, a student asks this because they do not think they should have to take a class and want a specific rationale. In that case, I respond, “Please consult your course catalog and program description. If you don’t already know the answer to that question, you should talk to your advisor about whether or not this is the major for you.”

via 10 Questions You Should Never Ask Your Professor! – Online Colleges.

September 14, 2012 at 1:11 pm 12 comments

WSJ Coverage: Students Pick Easier Majors Despite Less Pay

Wall Street Journal is touching on some of the same themes as the recent NYTimes article.  I’m particularly excited by this one because my name appeared and I got two pictures in the paper! 🙂

Educators have tried to tackle the attrition problem with new programs that they say make engineering more accessible. In 2003, Georgia Institute of Technology split its introductory computer-science class into three separate courses. One was geared toward computer science majors, another to engineering majors, and a third to liberal arts, architecture and management majors. The liberal arts course cut down on computer-science theory in favor of practical tasks like using programming to manipulate photographs, says computer science professor Mark Guzdial. Since the switch, about 85% of students pass, he says.

via Generation Jobless: Students Pick Easier Majors Despite Less Pay –

November 9, 2011 at 9:35 am 2 comments

How important is a “useful” language for non-majors?

Jennie Kay of Rowan University asked a question on the SIGCSE mailing list: How important is it for the language in the non-majors CS1 course be “useful” to them?  Is important to use tools like Python, or is it okay to use a tool like Alice?  I posted a response this morning, and not wanting to lose the opportunity to reuse a post, I’m sharing it here:

It’s interesting what variables and constituencies we’re not considering so-far in this thread.  We’re talking about what content we should cover and what we feel is best for expressing that content, which are both important and good.

(1) What do the students want?

I’m not suggesting that we should give the students whatever they want, or that they know what’s best for them.  Carl Weiman told us in March that we should start by motivating the students.  (Former Sec’y of Education, Terrell Bell, is quoted saying: “There are 3 things to remember about education.  The first is motivation, the second is motivation, and the third is motivation.”)  Learning computing, especially programming, can be hard.  It’s worthwhile figuring out what motivates the non-major students to spend that time and effort.

In our interviews and surveys of non-majors studying Media Computation, we always find a significant percentage of the students who are worried that we’re teaching them a “toy” language.  It’s not that they want to learn to be professional programmers.  They want to learn something that “I might use later” (related to Brian Harvey’s comment about writing small programs for themselves).  They do worry that Python isn’t valuable enough to them, in terms of future recruiters/employers knowing what it is.  Now, that’s not all students, and I’m sure that different schools have different cultures (e.g., Georgia Tech tends to have a practical/pragmatic culture).  But it’s probably worthwhile asking the non-major students what they’re interested in learning.

(2) What do the non-major faculty say their students need?

Computer science is really general — I can teach variables using just about any kind of data.  I have lots of choices for contexts for homework and examples. I don’t presume to know what application areas or parts of computer science are going to have the most impact on the future of chemistry or sociology.

When we designed Media Computation, I had an advisory board of non-CS faculty.  They wouldn’t let me pick Java or Scheme for their students.  They felt that those languages were too hard and were too much about “serious computer science.”  They liked Python (a story related in a SIGCSE 2005 Symposium Paper on how we designed our non-majors course).  Recently, we had a series of meetings with Biology faculty about creating a CS1 for them.  They didn’t want Java because they said that “nobody in Biology works in Java” (surely an exaggeration, but probably describes accurately trends in their field).  Most interesting was the battles between themselves — half the faculty wanted MATLAB or SciPy for large data analysis and simulations (e.g., for ecology), and half wanted Perl or Python for doing analysis of genomes (e.g., regular expression matching for bioinformatics).

The issues being discussed in this thread are important.  There are other constituencies and stakeholders in the question.

June 18, 2010 at 9:16 am 4 comments

Enter your email address to follow this blog and receive notifications of new posts by email.

Join 10,184 other followers


Recent Posts

Blog Stats

  • 2,039,343 hits
December 2022

CS Teaching Tips