Tuesday, January 4, 2011

There Are No Wins At BYU

After reviewing the outcome of my fifth straight semester taking CS/Animation classes I feel justified in making overarching statements of defeat.  I've not managed to get a grade higher than a C+ in a CS class in so long I'm beginning to doubt it's possibility.

This last semester I poured my soul into CS 240.  The result was 100% on the first three major projects, 77% on the fourth and fifth major projects (which I still feel cheated on), and 100% on the first two midterms.  Curious as to how the result is C+?  I'll tell you how.  For the fourth and fifth major projects there were code evaluations and design documents associated with them, the results for each:

Design Doc Project 4: 20% (Uh.... what?  That's pretty bold for a project whose requirement was to layout out the header files and pick data structures).
Design Doc Project 5: 77% (Again... Uh... what?  I did a half page more work than the design doc for project 4 (out of like 15 pages))

The code evaluations actually went okay.  The major problem I had was that extenuating circumstances (mostly with CS servers being down) made the project late, which made the code rushed, thus decreased in quality.  IF YOU ARE GOING TO FORCE US TO USE YOUR LABS, MAINTAIN THEM!!!!  IF YOU WON'T MAINTAIN THEM, THEN GIVE US OUR CREDIT BACK!  Seriously though, I lost a solid 20% on project 4 overall because of CS server problems.

Seriously, CS240 needs more work.  I realize it's better than it was, but it needs more.  It needs more focus than what it currently has.  Both Chess and Web Crawler are obscenely long.  Cut the extra crap.  We don't have time to learn makefiles.  Honestly, I think ever student will report at least an extra half day of work trying to figure out makefiles and another half day spent fighting them throughout the project.  Also, clean up the project documentation.  Scratch that last sentence.  THROW OUT the current documentation.  It's garbage, it really is.  Rather than trying to teach with the documentation, list the requirements for the project.  Teaching is what class time and TA's are for, not project specification sheets.  I know this is another sweeping statement but I feel like most students lost at least a full day of productivity because of misunderstanding in the project documentation.  I could say A LOT more on what could be improved in the course, but I need to move on to my final point.

WHY HAVE WE NOT BEEN TAUGHT AN IDE OR DEBUGGING?!?!?!?!?!?!?!??!?!?!!??!?!?!?
Seriously... linux command line?  Debugging with print statements?  Oh... and a TA whose exact statement was "I finished this class using gvim and the command line."  Thanks TA, that really helped me find my bug.

CONSTRUCTIVE CRITICISM:
     The CS department needs to determine a learning outcome for each class (and for the program) and stick to it.  There's a lot of nice stuff they can teach, but there's no time for the "nice" things, only the essentials.  An example of something useful to learn is an IDE.  Pick an IDE to teach and offer support with.  Use the same language and IDE in all the classes that use that language.  Teaching an IDE will not only make projects faster, but will encourage the learning of debugging (which honestly isn't being taught very well/at all right now).  Also, either offer outstanding support for the labs, or make the projects so they can be done from our personal computers and on the major OS's.  I realize the benefit of learning new OS's, I really do.  The problem is you can't just decide to add new requirements (like learning a new OS) to already difficult classes.

     IF YOU ADD NEW LEARNING OUTCOMES, YOU HAVE TO DROP OLD ONES.  If you can't drop old outcomes, you need to add a new class.  It's that simple.  You can't have your cake and eat it too.  If you try, the students are the ones to suffer.

     Briefly using the makefiles as an example, we were required to right makefiles that functioned a specific way.  This made using an IDE to it's full potential impossible (most of them use their own makefiles to build/run/debug).  The simple solution would be to have taught an IDE already (because if you can figure it out, which we didn't have extra time to, the IDE's will let you use custom makefiles).  The other simple solution is to not require a makefile.  If you HAVE to teach makefiles, require them for the early projects and let us use non-caveman tools for the later projects.  I know this may sound crazy to some, but in my opinion banning power tools from carpentry students hurts a LOT more than it helps.

     A program like this requires focus in curriculum (which requires sacrifice by the department), quality lectures and TA's (which requires sacrifice by the teachers), and hard work (not obscene amounts of work) from the students (which should be a sacrifice for them).  I really think that's the point here.

     I will say that there have been good things in my CS classes, but all in all I feel like I poured my soul into them and got a blemish on my transcript in return.  I'm not stupid.  I taught myself Houdini because of the short comings of Maya.  I taught myself Flash while feeling like my time and money was being wasted in Anthropology.  I was bored during the reading days this past semester so I taught myself Cocoa, Objective-C, and IOS.  I'm not stupid, but BYU sure makes me feel like I am.

2 comments:

Will Strong said...

No one likes to talk about it, but it the end grades (and degrees) mean jack squat for an art program. Your portfolio is what is going to get you work.

joe said...

I know that about the art side... the problem is that they don't necessarily feel the same way about Computer Science...