And so ends the 2nd part in the CS 371p trilogy...
This Friday we had the second test in the course and it was in the same format as the previous one - 100 marks worth of multiple choice questions and then 50 marks worth of coding problems. Since some students may still be taking make-up exams, I won't discuss the actual content of the test; however I will remark on its structure. The multiple choice questions were anything but "statistically independent" (I'm a machine learning sorta guy). Based on bits of C++ trivia, entire series of questions (ranging from 25-40 marks) had the same options hinging on the very same concept. In other words, if you had the misfortune of forgetting that concept, you were going to lose out big time! The test felt a lot like gambling in Vegas - when you hit it, you hit it big or you simply lost everything! Rather unfair....and it has also left me a bit averse to the letter "A".
This is also a good time to reflect on why I took the course and what I feel I'm getting out of it. When I registered for this course, I did it for 2 reasons - I had heard that Prof. Downing ran an excellent albeit tight class and I also wanted to hone my C++ skills. Looking objectively at the course so far - it has been run well, quizzes keeping you on your toes, projects that help you grow comfortable with good software development practices and a lot of information. But when I step back and look at the bigger picture - I feel like the course lacks substance. We're getting tons of information, no doubt about that, but a lot of it simply seems to be C++/ Java trivia that you would perhaps learn for a coding certification test. Honestly, the only "object-oriented" parts of the course - a couple of papers and the textbook, have been completely self-study. The one object-oriented project so far seemed to have more of an emphasis on formatting the output than anything else. I feel that the course could be so much more enriching if the contents of the textbook weren't simply dismissed by a 5 point quiz; rather actively discussed and debated in class. How about giving a software design scenario and then discussing how to engineer a good design using object-oriented programming. Talking about designing well-thought out interfaces to make more pluggable code. Discussing code reuse and inheritance hierarchies, discussing how to layer abstractions into your design. These are very important skills to learn and we would benefit a lot from the experience of Prof. Downing as well as the collective knowledge of the class. Yet week after week we end up poring over minutiae like "Java caches String literals" (and this is a senior level course) or the many little code snippets like "Filling out an array with values" or "Checking if 2 arrays are equal" that are simply not intellectually stimulating after you've gone through the first example and understood different iterators.
I know that a good programmer has all these tips and tricks under his belt. However, it would be so much better if these were an addendum to the course rather than its entirety. In fact, simply flipping what is assigned reading and what is actually covered in class would benefit students greatly in my opinion.
No comments:
Post a Comment