Hacker News new | ask | show | jobs
by hacb 876 days ago
I agree with you, but in my case I'm teaching programming, so doing table-top assignments is a no-go for me. I wrote too many C programs with a paper in a pen to know how bad it is. :)

That's why those assessments are tailored to be done at home, and then they send me an archive or a Git repo link.

2 comments

Writing 'C' programs on paper with a pen is actually a good way of learning for a certain percentage of students. Writing with a pen is a different cognitive activity than typing, and can aid in reinforcing knowledge.

So, one way to approach it would be to set the students to solve a task, say, one of the sorting algorithms. They can do this however they like.

Then in class you get them to write the same algorithm for a slightly different application thus (a) re-inforcing the algorithm, (b) demonstrating more than one application, and (c) pinpointing people who copied and pasted code without understanding and internalising the code.

Our 'C' teacher used to do this all the time (even before the internet) and when we got into exams, we did extremely well on them because we were copying out algorithms we knew off by heart and applying them to the exam questions.

I think the best you can do here, is to grade based upon what is in front of you.

If the code doesn't work, it means they (as you said), didn't understand what they copy and pasted. And as the whole point is to demonstrate learning, understanding, it is valid to mark such things as failures of that.

And this matches real world expectations too.

If there is any way you can tilt assignments to better demonstrate understanding, that's a win.

Hmm.

You could try to break up responses. By that I mean, have a dozen short coding exercises, but then tie them all together.

EG In the end, one bit of code to call the api/functions of the rest?

It might help break AI responses a bit.

Having multiple exercises that in the end get tied together is a pretty good idea! This would also highlight inconsistencies between different pieces of code that may indicate that the code has been generated and/or students are not understanding what they are doing.