Additional profile information on Alfred Thompson at Google+
Have you ever been asked a question that you have been asked time and again but suddenly decided you have a different answer for? One of the questions I hear a lot is what programming language should be taught first and this question was asked of a panel I say on last week. Except for me it was an impressive panel. Don Slater of Carnegie Mellon and the Alice Project, Michael Kolling, University of Kent and creator of Greenfoot for teaching Java, and David Klappholz from Stevens Institute of Technology who got his PhD while I was still picking a major in college. So of course I asked to answer first because that was the only way I had a chance of adding value. Plus I had suddenly realized that I had a new answer – one that I had not tried out in public before. And I wanted to give it a go.
Normally of course I would have launched into a great explanation of why Visual Basic was the best and language wars would likely have erupted. But that just did not feel right. So I answered that it depended on a number of things such as the goals of the course, the type of student but most importantly it depended on what language the teacher was most comfortable with and had the most passion for. The first programming course is hugely important. It is during this course that many students will either be turned on to computer science or turned away from it. This is the first impression and it needs to be a good one. If the teacher knows the language, is comfortable with the language, can have fun with the language and really enjoys the language the students will have a better experience. Everyone wins
I remember teaching Java for the first time. It was not a good experience for me (I was not ready for it) and I am sure it was not a good experience for many of the students. I did then a disservice. In hind sight I should not have agreed to teach the course. But I did and I tried my best but it was not ideal. Teachers easily, and without thinking about it, transfer their feelings about material to their students. Recent reports say this is true of math for example. (Study finds female teachers' fear of math can be catching) I doubt the same is any less true for computer science education. This is why we need well trained and confident computer science teachers in our schools.
There are other considerations BTW. Michael Kolling pointed out that supporting tools are very important. Greenfoot and/or Alice for Java for example. I personally think the Visual Studio IDE makes learning Visual Basic and C# much easier than they would be using a command line and text editor. Plus the drag and drop editing of graphical user interfaces make creating real looking Windows program easy and fun. There are also curriculum materials available for some of the better tools. The Greenfoot site has some for that tool. Alice.org has some for Alice. The Scratch web site has many resources as well. The Microsoft Faculty Connection has curriculum resources for VB and C#. And there is the newly revamped beginning developer learning center. Python which is a language that has a lot of proponents (I like that it is dynamic) but not as much in the way of a support environment for teaching. Yet.
I know that a lot of curriculum is slaved to the AP CS curriculum these days but I really strongly believe that APCS is too much for a first course. Students need a gate way course that will introduce them to programming in a fun, exciting, dynamic and enthusiastic way. For that course it is best if the teacher uses a language and a platform that they love. Communicate the love not fear, the enthusiasm not the necessity of a specific language, and share passion not pain.
In various contexts the subject of programming contests has come up in conversations I have been having with both teachers and friends in industry. There are, to my way of thinking, two sorts of programming contests. I call them the sprint and the distance race. They both have pros and cons and I’d like to use this post to express some thoughts on them and hopefully get some opinions from others.
The sprint is what most of us think of when we think of a programming contest. You lock teams into rooms with a computer, limited documentation and a list of programming puzzles to code solutions. The solutions are submitted, often to a computerized testing process, and get either a pass or fail. The team that completes the most problems with a pass grade in the shortest period of time wins. The pros of this are that it is easy to run, takes a limited and specific amount of time, winners are easy to pick, and it makes for quite a social day if done well. Colleges love to run these because it gets good students on campus. Teachers like them because they don’t have to spend a lot of time mentoring teams as they work through a long process.
The down side is that they contests really promote a quick and dirty style of programming – one that may not serve them well in their education or in careers in industry. One teacher said to me “they are not real computer science. they are just hacking.” I admit that I worry about that myself. But these contests do interest, excite, and often motivate students to study so they do have value.
The second sort of contest – the distance race – involves a single more complex project. An application of sorts that must be developed, tested and in the best contests “sold” via a presentation. The pros of this style include requiring well-thought out and engineered solutions because the testing will be more complex. They also require more involved coding, more team work, and the development of a clear and presentable explanation of what the program does and why it does it the way it does. You have to put some thought into it. In many ways it much more closely resembles industry or formal research tool development.
The down sides start with these projects being much more difficult and subjective to grade. They are also more difficult for students to finish because they required more work over a longer period of time. Students often have short attention spans or need more immediate gratification. This is especially true at the high school level. In many ways I think the benefits to the student and their education of this type of contest is well worth the effort. On the other hand the cons make it much harder for sponsoring organizations.
So I lean towards preferring the distance race over the sprint contests. That is the sort of contest that the Imagine Cup Design Invitational and Game Development contests are and part of the reason I like them. On the other hand practicality requires that more sprint contests are going to be run. And that is probably better than no contests at all.
So what do you think? Is there a third or fourth kind? Have I got the pros and cons fairly described? Or am I missing things?
This story on cheating in Computer Science classes is one of those things that really makes you think. Years ago one of my students was so tired of students looking over his shoulder and stealing his code that he started using variable names that made absolutely no sense at all. He figured that if they were too obviously his no one would dare steal his code. This was my first awareness of student cheating in my own classroom and was a real eye opener. I kept a close eye on things but honestly I am sure I missed as much cheating as I caught. Hopefully not more but who knows?
Defining cheating in computer science / programming courses is difficult though. After all code reuse is a goal for professional developers and team work is essential. The article above listed HONOR CODE RULES FOR STANFORD'S COMPUTER SCIENCE CLASSES and they are a lot like I tried to run things in my classroom
The last line became a critical part of my final project grading in my courses. I would do a one on one interview and mini code review with each student and we would go over their project together. I would prepare questions about code that seemed tricky or overly familiar to me. I would ask for explanations of names and program organization. All this to make sure that students understood what they had done. This doesn’t scale well of course. You can’t realistically do it for a 180 students. I wish we could but there is a limit to time in the day. On smaller projects during the year I would do spot interviews when I suspected something was “different” about a project. This requires knowing what each student is like and also doesn’t always scale. But you know English teachers do it with writing projects so we should be able to do it in computer science classes as well. Style is unique.
But the article also says that cheating is much more common in computer science courses than in other courses. Why is that? Stanford’s Eric Roberts has some ideas based on his research.
These resonate with me. Take the second item. How do we handle it when students fall behind? Can we do things more self-paced, especially in the early courses, to make this sort of cheating less necessary? Perhaps not at college/university but perhaps we can in high school. Helping students get a solid base for later seems like it should be a huge goal for HS CS.
And the third item. Do we have to make projects binary – pass or fail? Or can we review code and give some partial credit for it? That is done in grading the free response questions on the APCS exam. This is a larger problem with projects/homework of course. But I tried to review even code that would not correctly compile to at least understand what the student was not understanding. If we can review projects while they are being worked on we can help with those sorts of things. Again, not easy to scale but doable in smaller courses. And lets face it, small classes are what many HS CS teachers are facing. Perhaps we can turn that into an advantage for our students.
Clearly this is going to be an issue going forward. It means we need to talk about the ethics of “helping”, “borrowing” and other cheating methods. But we also need to emphasize that students really need to and should want to learn these things for themselves. Success in later their life will depend on what they know and not on what the student in the next chair knows.
BTW see Mark Guzdial’s take on this at Stanford finds cheating increasing, especially among CS students and how cheating influenced Georgia Tech in how they rewrote the curriculum. Useful information and ideas.