Also, many students fail to connect what they learn in one class to what they learn in another. Thus, we often see students with high grades in algorithms, data structures, and software engineering who nevertheless hack solutions in an operating systems class with total disregard for data structures, algorithms, and the structure of the software.
That is to say pass fail grading of programs, grading should be similar to an English class how you express it is just as important as what you express.
I wholeheartedly agree with you on the grading aspect. Even in classes where professors or TAs effectively grade and comment the code, I think most students have a tendency to see the grade they received and ignore the professor's feedback. The program worked, they got the grade, onto the next assignment.
I had two classes this past quarter taught by a professor with a very different grading system. He used a program he wrote called the "code critic" to have us submit exercises into his grading queue. Only working code could be submitted and we could only have three assignments in the queue at once. He would then use his program to return the code with criticism added on any lines not to his liking and mark the assignment as "Not done," "Almost done," or "Done." If he didn't mark it done, we had to fix the code in response to criticism. These criticisms were very picky, even sometimes dealing with the naming of functions and variables.
At the end of the quarter we were graded on how many assignments we were completed, and how much we grew as programmers. If our assignments at the end of the quarter did not require any resubmissions, this was reflected in our grade.
I think this method was an extremely effective alternative to traditional grading. I learned more about programming and style in both C++ and Lisp in these two classes than I have in any other classes to date.
Your analogy does not make sense to me. The professor clearly wanted his students to become not just better at hacking together solutions, but presenting readable, consistent code. This is a noble goal, and you're correct it has little to do with computing. It has to do with communicating to other people what you have done.
Good point the analogy definitely doesn't completely account for the adjacent field of software engineering, where coding styles are certainly important. I guess that's mostly because artists rarely work in large groups, and when they do, I'd imagine the work is mostly parallelize-able: several people don't need to go through the details of any single piece of work.
Animation. Easy to work in parallel but output is very constrained stylistically. Multiple author books tend to have stylistic constraints as well otherwise the book suffers from an uneven feeling.
Comments
The only problem that he actually mentions is:
Also, many students fail to connect what they learn in one class to what they learn in another. Thus, we often see students with high grades in algorithms, data structures, and software engineering who nevertheless hack solutions in an operating systems class with total disregard for data structures, algorithms, and the structure of the software.
That is to say pass fail grading of programs, grading should be similar to an English class how you express it is just as important as what you express.
I wholeheartedly agree with you on the grading aspect. Even in classes where professors or TAs effectively grade and comment the code, I think most students have a tendency to see the grade they received and ignore the professor's feedback. The program worked, they got the grade, onto the next assignment.
I had two classes this past quarter taught by a professor with a very different grading system. He used a program he wrote called the "code critic" to have us submit exercises into his grading queue. Only working code could be submitted and we could only have three assignments in the queue at once. He would then use his program to return the code with criticism added on any lines not to his liking and mark the assignment as "Not done," "Almost done," or "Done." If he didn't mark it done, we had to fix the code in response to criticism. These criticisms were very picky, even sometimes dealing with the naming of functions and variables.
At the end of the quarter we were graded on how many assignments we were completed, and how much we grew as programmers. If our assignments at the end of the quarter did not require any resubmissions, this was reflected in our grade.
I think this method was an extremely effective alternative to traditional grading. I learned more about programming and style in both C++ and Lisp in these two classes than I have in any other classes to date.
even sometimes dealing with the naming of functions and variables
Ugh. Asking a CS major to adhere to naming conventions is like asking an art major to color within the lines. It has very little to do with computing.
Your analogy does not make sense to me. The professor clearly wanted his students to become not just better at hacking together solutions, but presenting readable, consistent code. This is a noble goal, and you're correct it has little to do with computing. It has to do with communicating to other people what you have done.
Good point the analogy definitely doesn't completely account for the adjacent field of software engineering, where coding styles are certainly important. I guess that's mostly because artists rarely work in large groups, and when they do, I'd imagine the work is mostly parallelize-able: several people don't need to go through the details of any single piece of work.
Animation. Easy to work in parallel but output is very constrained stylistically. Multiple author books tend to have stylistic constraints as well otherwise the book suffers from an uneven feeling.