Brief notes from first year “wrap-up” session, June 2001

 

Points raised (N.B. is was not clear whether there was a student consensus on the points below but certainly there was little dispute between students in the meeting):

 

  1. Assessment of programming courses

 

Exams were not appropriate - did not test realistic programming skills. Could the assessment be coursework only?

 

Response: Exams were effective in testing important aspects and were the only way of ensuring students understood programming. Exams were essential given plagiarism problems.

 

Mini-projects should have more weight

 

Response: Extra weight would increase temptation to plagiarise.

 

  1. Past papers, model answers

 

Why were model answers not published?

 

Response: We want to avoid giving the impression there was only one correct answer.

 

Sometimes (definitions etc.) there really was just one answer. Lots of questions just required rote learning

 

Response: Usually the rote learning part was just at the start of the question in order to provide a gentle introduction. Model answers would encourage students to rote-learn answers and regurgitate these even if they did not quite fit the question. "Definitions" were often through example - students should beware of looking for facts rather than cultivating understanding.

 

  1. The year's programme

 

SE comes too soon. You can't do SE until you have begun to program. Students were confused with the sense of the subject.

 

Response: Confusion partly due to people not understanding "systems" in the real world. Next year there would be more emphasis on small systems - this would be more clearly relevant

 

Why not swap Theory and SE? The SE techniques were not required for first term programming but an understanding of algorithms from the Theory course would be useful.

 

Response: Plans were in hand to make the SE course more relevant to first year programming. AF comments: "I absolutely agree ... SE should be moved to year 2!"

 

  1. Notations

 

There were some inconsistencies between notations used in SE and programming. Not fair that students should lose marks for using a different notation.

 

Response: In general students must accept variations in notation in different courses/texts. Sympathy for them losing marks however

 

  1. Deadlines

 

Deadline for final theory c/w was too late - too near exams. End of term 2 would have been better.

 

Students need more structure with staggered deadlines for different coursework. They needed help with time management which was not something they had had to cope with prior to university.

 

Programming mini-projects should have been available earlier

 

Response: Timescales were always squeezed due to there being only 20 weeks of teaching. We could look at earlier setting of c/w but past experience suggests this does not help - students always leave work until the last minute. We have tried in the past to coordinate deadlines but this does not seem to have made much difference in practice. CS courses were always changing so it was impossible to establish a consistent pattern from year to year.

 

  1. Information

 

It was not clear what the rules were for progression and calculating degrees.

 

Response: This was on the web but if not satisfactory then let us know. URL would be publicised.

 

  1. Facilities

 

There seems to be general contentment with computing facilities.

 

  1. Was the course what students had expected?

 

Expected more on hardware

Would have liked C++ in year 2

Course could be more academic - more emphasis on real computer science rather than skills acquisition

 

Response: There was some scope for hardware courses through options. C++ should be easy to learn - do it in a final year project for example. Would make more sense to learn a structured or stack-based language.

 

  1. Comments from a student via email

 

Request for a lecture/seminar on time management

Dislike the way OS and parsing lectures were "thrown in" to 1B11

Some overlap could be removed - e.g. Boolean algebra covered in 1B10 and 1B12 and in E655.

 

Response: Parsing is not 'thrown in' to 1B11. Parsing is included in 1B11 because an understanding of parsing leads to a better understanding of programming languages, and to a better understanding of the error messages which parsers (as part of compilers) produce. OS is another issue - but feedback from the second-year students suggests that ensemble courses are appreciated.