The structure of my classes...

10 Dec 2009

I've had a lot of complaints about the volume of work given. I've even taken criticism from other instructors that I "attempt to do too much during the semester." There is a reason for that. It is simple. It's what I do in my day job. I write software, not every single day, but most of my time is spent writing software. So the class is structured to cover both the academics and the real life. From the book assignments every class - to get you programming more often and to give you, the student, a brace as you learn the language. The semester long group project that is by no means meant to be easy. The coding we do in class on the projector are essentially code reviews. The tests are geared for both the school needs and yours, some of you are book learners other are not thus the 50% multiple guess and 50% coding. The coding section of the tests, if you think about it are like bug patching. Very little time to start and finish a problem from the beginning. Finally, everything is due the last day of 'class' model is designed to get you thinking about your own time management practices. Those that turn in what they complete as they finish it (think SVN commits) get their results faster and know their grade in the class as they go along. Those that don't and wait well the code, and for the most part the grade, reflects the rush they needed to turn everything in. Interestingly enough this article from Joel on Software titled Capstone projects and time management just confirmed why I've structured the classes the way I have.

{"display_name"=>"chris", "login"=>"chris", "email"=>"", "url"=>""}