Advertisement
Guest User

Untitled

a guest
Mar 3rd, 2015
228
0
Never
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
text 1.59 KB | None | 0 0
  1. So far over break, I've been looking at several of the 482 project 2 solutions that we've been hand-grading, and from what I've seen, there are several points that some students don't seem to have picked up on. While *most* graduate 281 with knowledge of the proper way to get code to do what they want and the complexities in doing so, I've seen several groups of people, for example, putting into one .cpp file the implementation for a variety of .h files where it makes sense to use separate compilation. I've also had to teach several students during my office hours the basics of running code through GDB.
  2.  
  3. In setting up the curriculum, were there any lists of the skills that should be learned during our intro courses (101/183, 280, 281) beyond just what is needed to 'pass' the projects? I remember that creating functional abstractions over repeating code was heavily emphasized when I took 280 (I had Professor Noble​), and that makefile construction and separate compilation were definitely covered and emphasized during my section of 281 discussion, but at what point should we be able to look at a student and say "she has passed course N, so she should be able to step through a test case in GDB" or something similar for many topics?
  4.  
  5. I feel like the only point where students are truly required to internalize most good practices is in EECS 381, but that course is neither required nor taken by most of our graduates. What are the skills that students should have by the time they pass through the gateways to the 400 level courses, and in what ways are we ensuring that students are learning those skills?
Advertisement
Add Comment
Please, Sign In to add comment
Advertisement