-
Notifications
You must be signed in to change notification settings - Fork 48
Fixed #270 #284
base: master
Are you sure you want to change the base?
Fixed #270 #284
Conversation
| }, { | ||
| buggyFunctionName: 'AuxiliaryCode.reverseString', | ||
| messages: [ | ||
| "Read the instructions closely. Did you overlook something important?", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The tone here's a bit off -- try to mirror other questions' first buggy output message. This tells the learner that they have a bug, but comes across slightly condescending.
| }, { | ||
| buggyFunctionName: 'AuxiliaryCode.reverseWordOrder', | ||
| messages: [ | ||
| "Are you sure you're interpreting the instructions correctly?", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same with this one. Generally it's best to provide an example that their code will fail on, in the hopes that they proactively fix their code after being presented with it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The problem with that is it only works when the student understands the question. The first buggy error occurs because the student is attempting to solve the correct problem but is failing to implement the solution correctly.
Both these errors can be caused by the student is attempting to solve the wrong problem.
When this is the case, giving the student an example to work out on paper won't work. An example-solution pair works, but is already presented in the instructions.
While I agree that my tone isn't quite right, I'm struggling to find a good way to get the student to go back and look at the instructions more closely without directly stating that's what they should do, and without presenting the student with redundant information.
I think the ideal solution might actually be "flashing" the instruction box in some way rather than presenting a message, but we don't currently have the infrastructure. Adding callbacks for specific buggy answers might be a good thing overall.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Mmm, that's a fair point, I agree. Getting the student to understand the question (if they don't already) requires some nuance. I think, though, that it might be worth doing -- "Check the instructions again. If you run your code on {{SAMPLE_INPUT}}, you return {{BUGGY_OUTPUT}}, not {{SAMPLE_OUTPUT}}.", in that case.
| "Are you sure you're interpreting the instructions correctly?", | ||
| [ | ||
| "It looks like you're reversing the order of the words instead of their ", | ||
| "contents. Is this what you were asked to do?" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd drop the final question of that sentence. It's usually enough to explain what the bug is to the learner.
No description provided.