Teaching Computer Science Better to get Better Results

October 15, 2014 at 8:32 am 35 comments

This is my third blog post in a series inspired by a thread in the SIGCSE-Members list and by the Slate article which argued that “Practice doesn’t make perfect.” Macnamara et al did a meta-analysis of studies of expertise, and found that a relatively small percentage of variance in expertise can be explained through hours of practice. The Slate authors argue that this implies that genetics explains the rest of the variance.

  • In the first post (see here), I argued that the practice+genetics is too simple to explain expertise. First, practice can be deliberate, lazy, or teacher-led. Second, there is experience that leads to expertise which is between genetics and practice. The most significant flaw of both Macnamara et al. and Ericsson et al. is ignoring teaching.
  • In the second post (appearing yesterday in Blog@CACM), I addressed a claim in the SIGCSE-Members list that programmers are “wired” differently than others. Most CS teachers agree with the Slate authors, that students can NOT be more successful with more work. The evidence that better teaching leads to better learning is overwhelming. In fact, there is significant evidence that teaching can even overcome genetic/innate-ability differences.

Lots of CS teachers believe in the Geek Gene Hypothesis, and for good reason. It’s frustrating to have seemingly no impact on some, especially the lower-end, students. Even the award-winning Porter, Zingaro, and Lister paper points out that the earliest assessments in the class they studied correlate very highly with the final grade. Gas Station without Pumps voiced a similar sentiment in his blog post in response to the Slate article:

But the outcomes for individual students seem to depend more on the students coming in than on what I do.  Those students who come in better prepared or “innately” smarter progress faster than those who come in behind, so the end result of the teaching is that differences among the students are amplified, not reduced. Whether the differences in the students coming in are due to prior practice, prior teaching, or genetics is not really knowable, but also not really relevant.

I agree. It’s not really knowable where the difference comes from and it’s not really relevant. The point of my Blog@CACM post is: we can do better. If we can teach spatial ability and subitizing, two skills that have a much stronger claim to being innate than programming, then we can certainly teach people to program better.

If we follow common practice and it’s unsuccessful, it’s not surprising that we think, “I tried. I explained carefully. I gave interesting assignments. I gave good feedback. It’s got to be an innate trait. Some students are just born wired to program.

I watch my children taking CS classes, along with English, Chemistry, Physics, and Biology classes. In the CS classes, they code. In the other classes, they do on-line interactive exercises, they write papers, they use simulations, they solve problems by-hand. Back in CS, the only activity is coding with feedback. If we only have one technique for teaching, we shouldn’t be surprised if it doesn’t always work

Here’s a reasonable hypothesis: We get poor results because we use ineffective teaching methods. If we want to teach CS more effectively, we need to learn and develop better methods. If we don’t strive for better methods, we’re not going to get better results.

A first step is to be more methodical with how we choose methods. In a 2011 paper by Davide Fossati and me (see here), we found that CS teachers generally don’t use empirical evidence when making changes in how we teach. We act from our intuition, but our students aren’t like us, and our intuition is not a good indicator of what our students need.

Next, we need to experiment with more methods. We want to get to a place where we identify known problems in our students’ understanding, and then used well-supported methods that help students develop more robust understandings. We probably don’t have a wide range of different techniques for teaching assignment, iteration, recursion, and similar concepts? We should try well-supported techniques like pair programming, peer instruction, or Media Computation (see CACM article on these). We should try to expand our techniques repertoire beyond simply grinding at code. We could try techniques like worked examples, Problets, CodingBat, games with learning outcomes like Wu’s Castle, multiple choice questions like in Gidget, the Parson’s Problems in the Runestone Interactive ebooks, or even computing without computers as in CS Unplugged.

We do not make it easy for CS teachers to pick up new, better, more proven methods. Sure, there are the SIGCSE Symposium proceedings, but that’s not a systematic presentation of what to use when. This is on the CS education research community to do better. But it’s also on the CS teaching community to demand better, to seek out better methods and studies of techniques.

If we taught better, there are a lot of problems in CS that we might impact. We might bring in a more diverse group of students. We might make our current students more successful. We might change attitudes about computing. Perhaps most importantly, maybe we as teachers will come to believe that we can teach anyone to program.

Entry filed under: Uncategorized. Tags: , , .

The 10K Hour Rule: Deliberate Practice leads to Expertise, and Teaching can trump Genetics Is There a Crisis in Computer-Science Education? Decrease in graduation rates in CS

35 Comments Add your own

  • 1. Bonnie  |  October 15, 2014 at 9:02 am

    I think that many of us CS educators are trying lots of methods. Perhaps in the large universities with huge introductory courses, programming-with-feedback is the main teaching method (and I have heard anecdotally that the feedback is often not very extensive). I am fortunate to teach introductory CS to no more than 25 students at a time. So I make a regular practice of using peer instruction, in-class polling, and scaffolded labs.

    But I don’t think these techniques are helping students achieve the main outcome of the course, which is being able to write a program from scratch. My students generally do very well on the peer instruction exercises, the in-class polls, and the scaffolded labs. But they fall apart when asked to write a program on their own. There isn’t enough research into teaching methods that support THAT particular outcome. Many of these teaching methods come to us from the hard sciences, where the desired outcome is that students are able to successfully solve constrained problems on exams. That is a very different skill from writing a program from scratch. I think we need to look more to the ways that writing is taught. Watching my own kid progress through middle school honors English, I see a very methodical approach which starts early on with scaffolding, but then removes the scaffolding pretty quickly. The students are asked to write, write, write, with close feedback. I think it works, and we should be looking to that as a teaching method. Students need to program, program, program, and we need to be providing a LOT of detailed feedback.

    • 2. Mark Guzdial  |  October 15, 2014 at 9:10 am

      I have a daughter in a large university CS class, and another daughter in a high school AP CS class. In both, the only instructional technique is code-plus-feedback. Maybe it’s the colleges with small classes where most of the exploration of techniques is happening?

      Have you tried Parson’s Problems yet, Bonnie? We’re writing a paper on their use with 1,000+ students right now. Really interesting middle ground — you’re assembling real program code, but without dealing with syntax.

  • 3. dennisfrailey  |  October 15, 2014 at 9:10 am

    One concern I have about this discussion is the implicatuon that teaching CS is equivalent to teaching programming. This reminds me of a person I encountered once who was dropping out of CS because she wasn’t a good programmer. That young woman could have had a highky successful career in computing but was being told from several directions that poor programming skills/aptitude meant no career in computing. I have a CS PhD and am in the process of moving slowly into retirement mode after a 40+ year career in the field. I haven’t written a program in over 30 years. The skills that have mattered to my career are varied, including good written and spoken English, organizational skills, design skills, and many others. I did write programs for the first decade of my working career, but only rarely was programming skill the critical factor in my career. I wonder if we should rethink the whole approach to teaching computer science so as to de-emphasize programming skill. Just as mathematicians aren’t necessarily good at arithmetic, I’d argue that success in the field of computing doesn’t necessarily require strong skills in programming.

    That being said, I do agree that no matter what the subject being taught, some people just have the knack and some don’t.

    • 4. Bonnie  |  October 15, 2014 at 9:29 am

      The problem is, the jobs available to graduates of computing programs who cannot program are the classic IT jobs – helpdesk, purchasing, IT management, systems integration. These are all very good jobs, but I think the traditional computer science major is a poor preparation for these jobs. People who are going into IT do not need to know algorithms or data structures in depth, or the inner workings of an operating system. They do need to know about business uses of technology. I think students who want to go into these positions are better served by majoring in IT. I say this based on observing what happens to the many students from my program who graduate unable to program well enough to take development or even QA positions. I have come to the conclusion that they should have majored in IT.

      While programming is not the totality of computer science, it does form the language of conputer science. A classics major needs to know Greek and Latin, but knowing those languages is not enough to be a classics major. It is the same for computer science.

      • 5. Mark Guzdial  |  October 15, 2014 at 9:41 am

        I agree, Bonnie. The real challenge of teaching computer science is teaching programming. That’s the educational and research challenge.

        Dennis, I strongly disagree with “Some people just have the knack and some don’t.” I suggest: “Some people have determination and experience and can succeed without teaching. Some people need teaching. And then there are the ones that we don’t yet know how to teach, but we’re working on it.”

      • 6. dennisfrailey  |  October 15, 2014 at 1:32 pm

        Perhaps its a matter of evaluating cost vs benefit, Mark. I, for example, love music but don’t have the knack for singing or playing. Sure, I could learn and become a very mediocre musician (I spent many hours trying to do so as a child), but it would require an enormous amount of effort for a marginal outcome. I know a number of people who are my counterparts when it comes to programming, math, and various other things that I happen to be good at but they aren’t. For example, I’m thinking of a woman I know who was very good at music but simply could not do programming well at all. This is why some people become lawyers and some become engineers and some become musicians and so forth. Each of us has certain talents and each of us lacks certain talents. Yes, we might eventually learn to teach a talent-less person how to do something better, but is that the sensible thing to do when that person’s natural talent lies elsewhere?

        • 7. Mark Guzdial  |  October 15, 2014 at 1:49 pm

          That’s the point, Dennis. That is what this whole series of posts is about. There is no evidence for “natural ability” when it comes to programming. There are differences between programmers, maybe as high as 10x, though there are some serious questions about the accuracy of those estimates. But those studies did not control for years of experience or training.

          We use “natural ability” too often as an excuse. The woman you know who “simply could not do programming well at all” might be a matter of motivation, or context, or teaching method, but we have no reason to believe that there is anything innate or genetic that would allow us to say that she really “could not do programming well at all.”

          I know that your experience will tell you otherwise. Some students just come into class knowing what’s going on, and some students don’t seem to make progress no matter what we do. But you can’t use your experience to make generalizations down to genetic/innate explanations, and we have to avoid using our experiences as an excuse for not inventing more and better teaching methods. There is no Geek Gene. There is no natural or innate ability that some people have to program and others don’t.

      • 8. dennisfrailey  |  October 15, 2014 at 1:41 pm

        I agree that there are a lot of positions that expect programming skill and many of the other jobs require skills more typically addressed in IT and other academic programs. And I agree that knowledge of programming is fundamental to a computer scientist. My point is that many computer science careers do not require mastery of programming. When we give our students the message that if you aren’t a top notch programmer you’re doomed as a computer science major, that’s when I get concerned. In my years in industry I knew of a lot of whiz-bang programmers whose careers plateaued because they lacked other skills needed for advancement. By contrast, I knew a lot of people whose programming skills were pedestrian but who moved to high leadership positions because they had organizational and leadership skills.

        Another problem with programming skills is that they are often focused on specific languages or methods of design that become obsolete rather quickly. We must make sure our students are learning the principles and are preparing for a lot of continuing education in the future.

        • 9. Mark Guzdial  |  October 15, 2014 at 1:51 pm

          I don’t think we’re talking about mastery here, Dennis. But it’s absolutely the case that we can help all students develop some programming ability and to increase the programming ability that they have.

  • 10. Shuchi Grover  |  October 15, 2014 at 1:00 pm

    Great post, Mark! I thought deeply about these issues when I designed the curriculum and course for middle school CS for my dissertation. I argued for a “system of assessments” that looks much like that list you’ve shared in the post with a few additions (such as open-ended design projects in addition to directed exercises; solo work as well as collaborative; code reading in addition to code tracing, working with pseudo code in addition to Scratch, etc. ELL students, for example, did not do well in multiple choice tests and scenario-based questions, for example, or even questions that required code-tracing, but they managed alright on projects requiring them to design and build in pairs- their designs were more simplistic. “Systems of assessments for CT” is the subject of my AERA paper submission too).
    As for the curriculum, I quote from the chapter of my dissertation that outlines the course design philosophy (or PCK, in some sense)- “It appears then that a monocultural approach to pedagogy would not serve the needs of such a curriculum. Instead, a classroom that embodies a balanced set of curricular goals for deeper learning would benefit from espousing a balanced approach to curriculum, pedagogy and assessment design as well. This approach could be viewed as giving students a balanced diet where there is an appropriate complement of approaches that cater to diverse deeper learning goals and also student needs. The goal for this curriculum design and research, therefore, was to tackle this effort as a design balance problem and engineer a balanced curriculum with a balanced pedagogy and assessments drawn from many diverse influences to guide this effort.” [Full dissertation here- Foundations for Advancing Computational Thinking: balanced designs for deeper learning in an online computer science course for middle school students; http://purl.stanford.edu/cc869py7832

    • 11. Mark Guzdial  |  October 15, 2014 at 1:43 pm

      Thanks, Shuchi — I like the term “monocultural approach to pedagogy” as a way to think about these issues. Your dissertation is in my to-read list!

  • 12. Elizabeth Patitsas  |  October 15, 2014 at 2:07 pm

    > In the CS classes, they code. In the other classes, they do on-line interactive exercises, *they write papers*, they use simulations, they solve problems by-hand.

    A great deal of the learning I did as an undergraduate came through /writing papers/. Indeed, some of the best learning I had about coding came through writing lab reports on computational physics — which always happened in my physics classes (or rarely, in my math classes). I never wrote any reports about computer science concepts in my CS during my undergraduate.

    It still surprises me that we (as a community) don’t use writing exercises when teaching CS. It strikes me as such a useful pedagogical tool.

    • 13. KDecker  |  October 16, 2014 at 10:11 am

      My favorite non-programming assignment in our Intro course is to have students write a short essay reacting to an article entitled “The Data Model that Almost Killed Me” (about an electronic health record failure). I ask them to compare their reactions now, halfway through the course, to what they might have thought the summer before the course. I get some wonderfully thoughtful reactions, even from students who are not doing well on the programming part (they seem to be getting something about the difficulty of moving from “information” in the real world to computationally usable “data”). This course is using Program by Design (HtDP) pedagogy, so data design is hugely central from Day One (the design/shape of your function body is driven by the design/shape of the data it consumes). I really should look into expanding the (prose) writing component…

    • 14. dennisfrailey  |  October 16, 2014 at 12:34 pm

      I too give a lot of writing exercises in my classes, although I seldom teach introductory courses. I find that by putting students in a situation where they have to explain what they are doing, they often sort through the issues and develop a deeper understanding. (I recall a debate back in the 1960’s between two distinguished math professors over the following question: can you truly know something if you cannot explain it or at least articulate it clearly? Although I have no idea where education experts come down on this issue, my experience has been that as a practical matter ability to articulate things is important for career success.)

      I recall too an observation that we learn written language first by reading and then by writing but we tend to teach programming the other way around. Would we have better software developers if before writing code we had them read and possibly critique code written by others? It might not be as “exciting” for some but it might be less intimidating for others. They tried this “read first” approach once at Ohio State in an introductory course but I don’t know how that experiment ended up.

  • 15. Peter Donaldson  |  October 15, 2014 at 6:17 pm

    Hi Mark, thank you for another great article and for the recent ACM blog post on Geek Genes. I recently had a conversation with a colleague about how often comments relating to this crop up in various guises and what we could do to encourage other Computing teachers to become more aware of how limiting this mindset is.

    Having reviewed most of the research on predictors of success in 1st year undergraduate CS courses, I agree with your hypothesis that it’s much more likely that we suffer from ineffective teaching techniques rather than programming being too complex an activity for most people to engage in.

    When I was really young and learning to read and write I took part in a whole range of different activities designed to gradually build my confidence and skills. Comparing this experience with learning to program makes me feel we jump from the equivalent of briefly introducing the alphabet, learning words, constructing sentences and then in the blink of an eye expecting academic quality prose.

    There are so many different approaches we could use with learners at particular stages in their development. For example you’ve mentioned peer instruction, media computation and parsons problems but if we want learners to be exposed to more code we could also get them to

    -identify and label parts of lines of code such as variables, control structure keywords and expressions.
    -identify and classify different blocks of code in example programs.
    -close trace carefully constructed examples that illustrate what particular common patterns of code do.
    -answer code comprehension questions where the natural language used for variables and subprograms is deliberately misleading really forcing them to rely on applying the formal language rules.
    -conduct a series of experiments with provided code starting by varying initial conditions followed by changing particular parts of it to fully understand how it works.
    -conduct cooperative code reviews of provided programs.
    -transform a piece of code so that it works in the same way but uses a more sophisticated set of constructs. For example use a fixed loop to initialise values in an array instead of a sequence of assignments.
    -transform a piece of code so that it performs a different action. For example this code finds the maximum value in a sequence change it to find the minimum.
    -identify and describe the function of various parts of a program.
    -classify variables in an example program according to which role they perform.
    -investigate and explain why a syntactically correct program doesn’t meet the problem specification it was designed for. For example moving elements in an array to close a gap results in elements after the gap being overwritten with the same value.
    -debug and fix broken programs.

    Evidence pointing towards more effective practices is out there we just need to find better ways of sharing it and developing more effective ways of evaluating the changes we make.

  • 16. Mark Guzdial  |  October 16, 2014 at 8:13 am

    Highly recommended: A thoughtful and passionate follow-up to this series of posts from Crista Lopes at U. California at Irvine: http://tagide.com/blog/2014/10/the-null-professor/

  • 17. dennisfrailey  |  October 16, 2014 at 1:14 pm

    I’m all in favor of improving how we teach. Let’s assume for the sake of discussion that all difficulties students have in learning how to program are due to cultural and environmental and nurturing factors, not any failure of “natural ability”. To what extent is a teacher supposed to compensate for things like poor preparation, poor motivation, negative environmental influences, etc.? Our education system is based on a model that allows a certain amount of time and a certain amount of teacher involvement for a student to learn. This is especially true in higher education. Improving teaching methods within that framework makes a lot of sense to me. I’ve spent many hours improving the way I teach, for example, and am currently trying some new approaches that have been published in recent years. But if we have to spend extraordinary levels of cost and time, we are in a remedial effort and need to recognize that. The economics of education are under a lot of scrutiny. I’m not saying we shouldn’t try to help those who have greater needs, but we need to make decisions about what makes sense for the normal situation and what approaches are remedial and will have higher costs.

    Now let’s get back to the premise of the first paragraph. Mark wrote: “There is no evidence for ‘natural ability’ when it comes to programming.” To put this in context, would you say there is evidence of natural ability when it comes to other fields such as music? Art? Acting? Athletics? In other words, is programming different from other skills in this regard? Or is the statement intended to be more sweeping, implying that there is no evidence for “natural ability” in any endeavor? If the intent was not so sweeping and the claim is that programming is distinct from these others, I’d like to understand what kind of evidence there is for natural ability in other skills so that one can explore why programming is different. If, on the other hand, the statement was intended in the more sweeping sense, how does one explain Mozart?

    I’d also like to comment on the statement that “There are differences between programmers, maybe as high as 10x, though there are some serious questions about the accuracy of those estimates.” A fundamental problem with measuring programming skill is that it is not a well ordered concept. There are many dimensions of programming skill – for example, some are fast, some are accurate, some are very clear in their designs, etc. I don’t think there could be a single measure that adequately encompasses programming skill, especially since different application domains call for different skills (high reliability vs maintainability vs good user interfaces, for example). I was recently involved in the hiring process for a small company and the programming skills they wanted were very focused to their needs. They rejected some candidates who had 4.0 GPAs and ended up hiring (and being very happy with) two candidates who looked less attractive on paper. The accepted candidates might not have fared so well at companies producing a different kind of software. Perhaps our field as blossomed to the point that we need to consider different categories of programming rather than trying to fit all students into the same introductory sequence. (I’ve seen a lot of evidence that different students learn differently. That’s potentially another argument for having more than one way of teaching how to program.)

    • 18. Mark Guzdial  |  October 16, 2014 at 2:19 pm

      Totally agreed that the economics of education make it difficult to deal with inadequate preparation. However, as good engineers, let’s consider this a constraint in the design problem. What can we do within our economic constraints? How inventive can we be with our approaches, contexts, and techniques to improve learning without constraints? What can we do to improve preparation? But the fact that it’s expensive doesn’t mean (a) it’s impossible or (b) we should ignore the problem or (c) we should think it’s a matter of a “Geek Gene.”

      I’m not an expert on genetic/innate differences. My focus is on computing education, and I know that the studies that have explored the genetic/innate differences around programming — they have found no supportive evidence. From what I have read, there is little evidence for genetic/innate differences in cognitive skills. Certainly, there is evidence for genetic differences in athletics. I would not at all be surprised if there were genetic differences in music.

      Let’s see if we can come to a set of agreements:

      • Students come in to our classes with different abilities. I’m quite sure that they are not genetic, and given when we enter the picture (e.g. after our students have years of experience in the world), it’s impossible for us to say what’s innate and what’s learned. From our perspective as teachers, it doesn’t matter. There are differences.
      • By changing the way we teach, we can likely reduce or eliminate those differences. That’s what the the subitization and spatial ability stories are about. It might be expensive, we might have to work back further in the educational pathway/system, and we will likely have to be inventive and do things different than what we do now. But these differences are not fixed.
      • Therefore, it’s worthwhile developing new ways to teach CS, because programming ability is malleable and not fixed.

      Completely agreed that measuring programmer productivity is nearly impossible. Yet, you will still read stories where people like Allen Eustace, head of Google engineering, claiming that there is a 300x difference between his best and worst engineer. There is no empirical evidence for statements like those, and as you say, it’s not clear what data you’d collect to make that argument anyway. I have heard teachers cite those stories and say, “My job is to find those top performers and prepare them for those top jobs.” That’s teacher-as-sieve, as opposed to teacher-as-developer. How could you possibly tell who’s going to be the best? How do you know that someone you didn’t pick, with the right teaching, could be better than the one you did pick? How do you prevent picking the top performer who just had a privileged background — and now you’re going to give him more privilege? (I’m pretty sure that I got the gender of the pronoun right for who would likely be picked.) That’s why programmer productivity shows up in this debate, and why it’s a particularly dangerous one — yet you’ll hear it in Silicon Valley quite often.

      • 19. dennisfrailey  |  October 16, 2014 at 5:10 pm

        I certainly agree with you on “teacher as developer” rather than “teacher as sieve”. [The experts in engineering education are concerned with the same thing.] And developing better ways to teach that may help overcome some of our students’ issues is commendable. My beef is with the programming-centric aspect.

        “Students come in to our classes with different abilities. I’m quite sure that they are not genetic”. I’m not convinced either way. I think we lack sufficient evidence to know. I ask WHY they come in to our classes. What motivates them to take computer science – and by the way we introduce them to the subject are we presenting them with a series of obstacles that motivate them to drop out? I once put together a course on computer science for non-majors that had no programming at all. It taught them, in a non-mathematically-rigorous manner, about algorithms, computability, Turing machines, computational complexity, security, privacy, and other concepts that have exploded in prominence since the advent of computer science. I wanted them to see the beauty of the field and the interesting intellectual challenges that CS experts deal with rather than the detailed mechanics of programming or designing hardware.

        I return to the student who could have a successful career in the field but isn’t a particularly strong programmer and is, in essence, bullied out of the CS major by fellow students who are hot shot programmers and teachers who assume lack of strong programming skill equates to lack of a potential CS career. Introductory programming sometimes works like a filter that convinces many students not to continue on in CS. I argue that in addition to figuring out how to teach programming more effectively we ought to consider teaching computer science in a way that doesn’t present programming as the primary make-or-break skill for CS majors. (As a simple example, how many CS professors write programs – except when teaching programming? Sure, they know how to program. But they don’t have to be very good at it to have success as professors.)

    • 20. gasstationwithoutpumps  |  October 16, 2014 at 6:08 pm

      Dennis suggested “Perhaps our field as blossomed to the point that we need to consider different categories of programming rather than trying to fit all students into the same introductory sequence.”

      At UCSC, we have at least three different “intro to programming” course sequences:
      CMPS 12A (standard intro to Java, may include some pair programming and other modern teaching techniques)
      CMPE 12/L (intro to programming through assembly language and C, a bottom-up approach for computer engineers)
      CMPS 5J+11 (a half-speed version of CMPS 12A, for students with no prior exposure to programming)
      BME 160 (a rather high-speed intro to Python programming for biologists and bioengineers)

      And that’s not counting CMPS 10, which is a mostly non-programming intro to computer science, nor CMPS 20 Game Design Experience, nor CMPS 80K Foundations of Interactive Game Design, nor CMPS 5P, a low-speed intro to Python.

      At least here, there are many introductory sequences, with quite different flavors.

      • 21. Mark Guzdial  |  October 16, 2014 at 6:56 pm

        Taking that lead, here at Georgia Tech we have three different intro courses (described in CACM and our story how we got there):

        • CS 1301: Introduction to Computing: Taken by CS majors, Computational Media majors, and most of the College of Science. It’s the course where everyone buys a personal robot and learns to program it in Python.
        • CS 1315: Introduction to Media Computation. Taken by Business, Architecture, and Liberal Arts majors, it’s an intro using Python to manipulate pictures, sounds, HTML files, and video.
        • CS 1371: Introduction to Computing for Engineers. All of Engineering takes this, all in MATLAB.

        I agree — we’re past the days when it’s one, programming-intensive computing course that makes you decide what to do next. Our strategy (as UCSC’s) is like Harvey Mudd’s — provide a variety of pathways into computing.

        • 22. Michael S. Kirkpatrick  |  October 17, 2014 at 10:58 am

          While I like this approach, I wonder how generalizable it is. We currently offer two intro courses, both in Java. One is 4 hours for students with no background, while the other is 3 hours for an expedited version. But due to our faculty size, we can’t really offer anything else. We don’t teach service courses for business, liberal arts, engineering, etc., because we just can’t. Our normal teaching load is 3/3 (a couple of instructors are 4/4). But this semester, the person who is teaching our intro is doing 5 sections. (Thanks, 20% enrollment surge in one year!) So I wonder how many other schools are capable of the diversity of intro courses that you offer.

          My other concern/question would be how this affects your later courses. How interchangeable are they? Can someone take CS 1315 and go on to be a CS major without 1301? At UCSC, do students from CMPS 12A and CMPE 12/L take common classes later, and does the different intro sequence have an impact? I have a paper that I’m currently revising where I found an interesting (though not shocking) result: Prior experience with C programming (even just a moderate amount of small programs) was a significant predictor of success in an OS course, more so than grades in prerequisite courses (note that all students completed the same prerequisites…but some offerings required C and others didn’t). (Take these findings with a bit of a grain of salt because the analysis is far from perfect, and only mentioned to illustrate that programming language choice can matter.) My personal interpretation is that prior experience with C, where you must struggle with pointers and memory addresses, helps with concepts like virtual memory, processes vs. threads (again, address space concepts), etc.

          So my question would be if your schools have done any sort of analysis to determine whether the version of the intro course taken has an impact on later course success? If not, why? Does this indicate something about your faculty achieving common objectives in the intros? Or is this also an artifact of the caliber of students (I’m thinking more of preparation and motivation than geek genes) that your schools attract?

          • 23. Mark Guzdial  |  October 17, 2014 at 12:42 pm

            Yes, a student at Georgia Tech can from CS1315 into the CS major without taking CS1301, and we have studied how the version of the intro course has an impact on later course success. But I’m going to leave that for another blog post. I’d like to separate two sets of issues. In this post, I argued that we need to develop more kinds of teaching methods and approaches. You’re raising a critically important issue — how do we implement that, and how do we find the funding for it. Completely agreed that we need to figure out how to make it work, but first, let’s agree that we need to use a variety of approaches and methods and contexts. I don’t want us to lose the point about the need and the kind of solution we want, because it’s a challenge of figuring out how to afford it.

            • 24. Michael S. Kirkpatrick  |  October 17, 2014 at 9:56 pm

              “…but first, let’s agree that we need to use a variety of approaches and methods and contexts.”

              On that, I absolutely agree.

          • 25. gasstationwithoutpumps  |  October 17, 2014 at 10:05 pm

            At UCSC, several paths merge at CMPS 12B (data structures):

            CMPS 12A ➜ CMPS 12B
            CMPE 12 + 13 ➜ CMPS 12B
            CMPS 5J + 11 ➜ CMPS 12B

            (For students needing a slow path, I recommend CMPS 5P + 12A, rather than CMPS 5J + 11.)

  • […] is a post about CS education. It is prompted by a seriesofposts by Mark Guzdial in which he criticizes the pervasive belief among CS educators that when it comes […]

  • […] might decide that the student just “can’t” learn to program. Maybe the student doesn’t have the Geek Gene. Some students do succeed with this approach, because they know a lot from prior experience (or […]

  • 29. dupriestmath  |  November 9, 2014 at 11:53 am

    I read this post once and came back to read it again. All areas of education are going through this same struggle, this same conversation – the search for effective teaching. I love some of the comments here. I teach in a school that has adopted a “workshop model” of teaching, which includes a launch or hook, inquiry / work time, catch-and-release to address misconceptions, and a summary. It’s changed the way I teach in a really positive way. http://www.pebc.org/professional-learning/

  • […] evidence — we know what that’s worth) describing how CS faculty make decisions (see post here). In my experience, if the evidence is counter to their opinion, evidence is frequently ignored. […]

  • […] technology that we need to stay relevant on but the methods in which we teach with it. This blog here discusses why some teachers have ineffective pedagogical methods with computers in education. […]

  • 32. Sohail Mohammed  |  October 28, 2015 at 11:44 pm

    Collaborative-Constructive methodology has inherent good effect on developing programming skills. This method can be adopted while doing practical or projects whereby the peers are able to interact with each other and there is sharing of intellectual resources. Brainstorming helps students in solving many programming problems as they are thought from different angles by different student. There are few students who are good at programming logic but lack knowledge of syntactical structure of programming language. While few students at good at programming language syntax but lack programming logic. When two students from each of these types work together, they can do miracles.

    • 33. RS4567  |  January 9, 2018 at 3:33 am

      Thats good but some are not capable of collaboration especially those with a lack of programming foundation. First professors have to lay out a proper foundation but from what I seen most don’t especially in the introductory courses.

  • […] have talked about Dan’s work here before, such as his 2014 award-winning ICER paper and his Peer Instruction in CS website. I met with Dan at the last SIGCSE where he told me about […]

  • 35. RS4567  |  January 9, 2018 at 3:28 am

    Its actually the the CS instructors and professors themselves to be blamed for students not picking up programming. Most are more concerned about plagiarism than actually building up the foundation of programming for the students. They never walk you through an entire program for the students for them to get an idea how programming works because they are more concerned about plagiarism. They just do bits and pieces of the code expecting students to connect them on their own. Most students who enter college are completely raw in programming and are not capable of doing that without external help. This lack of foundation leads to students completely dropping CS or do whatever it takes to survive. The CS teachers main concern should be if the student learned.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Trackback this post  |  Subscribe to the comments via RSS Feed

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

Join 10,186 other subscribers


Recent Posts

Blog Stats

  • 2,060,647 hits
October 2014

CS Teaching Tips

%d bloggers like this: