Hacker News Reader

Comment by bobochan | Hacker News Reader

This is very timely. For the past few years I have been teaching a programming course to small groups of beginning students, generally no more than 15. The goal is teach them the basics over the course of a semester, and we usually get there. The only downside is that it takes me about 30 minutes to review each assignment (there are two a week) and write feedback to the student. With 15 hours of grading a week, it seems hard to imagine teaching much bigger sections.

I went to a small college, so my programming courses were typically about the same size, 10-20 students. How do larger sections work in terms of getting feedback from professors? It seems critical, especially early on, to be able to understand the way students are trying to solve problems and then give them guidance how to get there. That seems to require more than "yes/no your code passed the unit test."

View on HN

I'm a high school teacher, and I currently have 4 sections of an intro Java course with 28 students each. (And I also teach an additional 36 students in two sections of the follow-up course.)

Each student does 1-3 small programs per class day, and I grade them all by reading the code and making comments. (I'm grading in another tab as I write this; I have 91 files to mark before 2:15pm today which is the output of a single section for a single class day.)

I've written tools to help me evaluate and make comments on the files extremely quickly. So that's what I do.

I teach Java and Python intro courses at two different colleges (both < 30 per class), and the way I've developed my courses are very unit test driven. The reason is when I hand graded, it would take easily hours to finish grading everything. Likewise, students would submit code they copy/pasted from the internet and wouldn't compile. After 5 minutes of debugging their code, it begins eating into my overall grading time. Likewise, what percentage should I give them on code that doesn't compile? Now, I say a flat "if it doesn't compile, the best you get is 20% for proper formatting".

In the first few weeks, I use JUnit and System Rules (I am currently build Python unit tests) to let them only work via the main method. Once we introduce methods, I show them how I call them via my tests.

I have also started implementing typing exercises into my weekly work, so students can get a feel before getting thrown to the wolves on the week's assignments. If I head to PyCon next year, I hope to present on whether it was successful or not.

I am looking to automate grading ala Open edX style submissions, as the biggest problem I have is not being able to give students a grade/notes until around Friday when I grade.

One trick I do is lecture all of Monday (2 hour class) and then let them work on their assignment for the week on Wednesday (3 hours). Most students don't realize how much time outside of class needs to be spent in the initial semesters of programming. I use that lab time to let them work and act as a helpful tool if they have questions. For example, this week, we'd gone over building Objects, but the idea of constructors are still shaky to some people. Today, when they were working on their labs, I spent some time with the 1-2 students that needed a little extra help understanding the work to get everything.

Thanks to everyone for their excellent suggestions.

One of my reservations about going to an automated testing and grading approach is that the course evaluations consistently say that the personalized feedback is an important reason that they took the course. But the fact is that line by line analysis of every submission does not scale, and teaching X times as many sections means that compromises will have to be made.

I am not worried about the top and middle thirds of the students, they largely sail through on their own with pretty minimal guidance from me (it is an intro course and many of them have strong backgrounds). The bottom third of the class is new to programming though, so hopefully they will take more advantage of lab and office hour time to solicit help.

The bottom third is where I hope to see improvement with the introduction of typing exercises, lecture exercises (multiple choice/true-false/fill in the blank style questions) and also I include YouTube videos of that week's material. My logic is that like sports, you need to stretch and warmup before doing a physical activity, so the same should be applied to a new concept. If the student is still having trouble implementing the concepts on their own, by having a prebuilt, functional version can help them see how it works.

Here's the current exercises for my Java 1 class: http://imgur.com/a/boc6h

So far, the students are responding favorably to the exercises and the only fall out I've had are students that fail to show up or do any work. Grading wise, the typing exercises are 10%, lecture exercises are 10% and the actual programming assignments are 30%. Since the problems are a smaller chunk of their overall grade, it alleviates the pressures of the 'all or nothing' structure of the unit tests.

In my evaluations last semester, many loved the introduction of the YouTube videos and I plan to ask them about the typing exercises this December.

I definitely agree on the personalized feedback portion though, that's why I make the second class meeting only programming, no lecture. This way, they can get their hands dirty with an experienced person to help them.

Brilliant. About 75% of our class time is spent doing exercises in class with me roaming about, or at least it would be if I could remember to stop talking at certain points.

Smart! Before I let them loose during the 3 hour lab, I spend about 15 minutes talking about the overall plan of a specific problem. For example, during looping, they had to flip a coin 1,000,000 times and record the results. I explained how Math.random() worked and how if they did "Math.random() > 0.5" they could determine whether the coin was heads or tails.

Looking at my current scores: 9 have A's, 2 B's and sadly 1 F

I wish that I could give out those grades (except for the F, obviously). One of the drawbacks of our system is that we have to grade on a curve, particularly the number of top grades that we give. The deans can give some variation in that quota, but only in exceptional circumstances. It is hard when I am teaching an elective and these are students that are specifically choosing something very challenging when they could just as easily spend their last semester coasting through.

I have never had to fail a student, but I have had a few violations of academic integrity that had to be dealt with. One of the few upsides of intensive grading is that I tend to remember specific errors, and a flag always gets raised when I see the same error twice, regardless of how many variable names were changed, etc.

Well, in my university's intro programming class, there were a couple hundred people. Grade-wise, the unit tests said it all. You didn't get personal feedback unless you asked for it. The test framework would email you the test cases and what your output was versus the expected, so a lot of times you could figure out your mistake (or bad assumption) without asking the professor.

The professor would have the grading details on the whole class so if we missed a lot of points on a particular problem, they would concentrate on that for a bit.

If you needed personalized feedback, you could ask the professor questions after class, at office hours, at the discussions section to your TA, or at the TA's office hours. There just wasn't personalized feedback based on your assignments.

At Imperial, 3rd and 4th years are Undergraduate Teaching Assistants (get paid a little for it) and mark the exercises every week for two trimesters. It's a great system, both for the 1st years and for the older students "teaching" (had been on both sides).

Are you aware of softwarecarpentry.org ? Unlike OP, their curriculum is based on education research, and refined over more than a decade.

Reply on news.ycombinator.com