> But some are an assault on reason, with every word of the assignment creatively misinterpreted. It was never stated which temperature circuit to build or how to prove it works or what level of explanation was necessary. And who’s to say what “build” means?
You have to think like a software engineer. Test first: write the requirements fro the perspective of a test which fails if the requirements are not met.
Rather than dictating irrelevant details of the apparatus that is to be made during the assignment, describe a procedure by which it can be verified to meet the requirements.
"Build a temperature monitor circuit.": what is it monitoring: the temperature of what? Where is that taken? What is the output? Decimal temperature in Celsius to the tenth of a degree? In what range? Or else is there just a control output: is there a hysteresis to turn something on and off like a thermostat? Etc.
"Test it to prove it works." That's a poor way of giving requirements. You need specific test cases. You may have to have specialized equipment on hand that the students can use, like a controlled source of reference temperature.
Absolutely. In my experience teaching in college, this is the correct approach.
A very useful thing to have, both for teachers and students, is a "rubric": a succinct description of how the work will be evaluated, and the importance (weight) of each feature.
Yes! And then the rubric should actually define the pieces of the assignment you care about them getting right. I have this debate a lot when we’re designing assignments for an intro to Python class (which, sadly, we have to do very regularly because of sites like Chegg…). Figure out what it is you want the student to get out of the assignment (e.g., manipulating dictionaries or sorting values) and evaluate their results based on whether they did that thing. If they did the thing but missed some nitinoid details they don’t get a perfect grade, but they should get a solid, passing grade for it.
It's a silly exaggerated example. Point still stands, at least from my experience. Even with a rubric, people still (intentionally or unintentionally) find ways to do things that circumvent the learning goals/outcomes of the assignment
If the real objective is learning goals/outcome rather than (or in addition to) a working temperature circuit, then that objective has to be somehow encoded into the requirements. Or else, sometimes all the stated requirements will be met without that unstated one being hit.
This is difficult because, for instance, the possibility of cheating means that the person who says they performed the assignment might have contracted it off to someone else and learned nothing.
Someone who already has all the required knowledge can also just spin out the assignment without learning anything.
Basically, learning is a state change in the pupil; if you want to validate that some state change occurred, you have to have a way of measuring the state before and after and calculating a difference.
You have to think like a software engineer. Test first: write the requirements fro the perspective of a test which fails if the requirements are not met.
Rather than dictating irrelevant details of the apparatus that is to be made during the assignment, describe a procedure by which it can be verified to meet the requirements.
"Build a temperature monitor circuit.": what is it monitoring: the temperature of what? Where is that taken? What is the output? Decimal temperature in Celsius to the tenth of a degree? In what range? Or else is there just a control output: is there a hysteresis to turn something on and off like a thermostat? Etc.
"Test it to prove it works." That's a poor way of giving requirements. You need specific test cases. You may have to have specialized equipment on hand that the students can use, like a controlled source of reference temperature.