How not to teach people to debug
entertainingcode.com
entertainingcode.com
Basically, they force the student to think about the whole problem at once, design a complete solution, and implement it without making mistakes. If you screw up, you'll have a very tough time finding the mistakes, since the system doesn't tell you where the mistake might be. It prevents you from repeatedly patching your system rather than redesigning it, which is a big problem I see in a lot of programmers.
It's not good for the absolute beginners, but for people who know a little bit how to think about algorithms and data structures, and are trying to improve their code quality, it seems like a good exercise. I know I've had some rewarding experiences debugging code by thinking about it; using a debugger, while easier, seems generally less satisfying.
Uh, this is the norm in the industry. There is rarely ever a chance to do a complete redesign. From the micro to the macro, there's always some hacky solution hanging around.
You could do as much testing on your machine as you'd like, with your debugger of choice. And when you are sure you understood the algorithm and implemented it correctly, you can submit.
In the real world, if your own testing misses a bug, you don't find out until it's live and causes a problem. In most grading systems, if your own testing misses a bug, you don't find out until the grader's (hopefully more comprehensive) testing catches it and you lose points.
In this system, if your testing misses a bug, you're immediately told that a bug exists, and given no other information -- but there's no actual penalty for doing this. In the real world, you're told what the incorrect behavior is, but there's a penalty in that this incorrect behavior has at least inconvenienced someone.
You can only submit your code for a given assignment a maximum of N times, where N is appropriate to the assignment difficulty and the level of the class. Then you can't pursue a haphazard "try this? nope, didn't work" strategy, and you have to reason out your program correctly on your own without appealing to the black box.
Alternately, if you wish to be less draconian, simply deduct points for every incorrect submission.
And IMHO these are good tools. But they don't teach you debugging (at least not directly). They teach that you need to test and debug your code before you submit it, which imho is good practice anywhere, ie you should test and debug your code before committing to SVN (or push your changes to main tree in DVCS-talk).
Of course that should be told to students, and they should be taught proper debugging/testing-methods. I mean these kind systems do not prohibit doing your own tests and debugging those before submitting, now do they?
What Facebook puzzlers end up doing is creating their own testcases and validating that those testcases encompass all the interesting corner cases and are complex enough to prove the efficiency of the algorithm in use.
Perhaps the hidden bit of learning from "The System" is that it forces students to think through the entire scope of possible inputs for their program and ensure they test against a representative set of cases.
We were told that the teachers would run hundreds of test cases more on out code, so we'd better think about it.
A very important thing to remember is that this course was a programming course (concurrent, I think), NOT a software development course. Many of these "I had to do this stupid thing in school that I'll never need in the real world"-rants miss those differences.