1. Notes

What follow are sample responses to the questionnaire issued at the end of the introductory programming module in the 2001/2002 academic year. The questionnaire contains 20 questions in total. The first 18 are in the form of statements for which a fixed response is invited. For example, given the statement "I had sufficient background to take this module" students are invited to respond with "strongly agree", "agree", "neutral", "disagree", or "strongly disagree". The last two questions invite a free text response. Question nineteen asks the students to complete the statement "The best thing about this module was..." and question 20 asks the students to complete the statement "The best way to improve this module would be..."

Our sample responses are for questions 19 and 20. We've offered a sample that aims characterise the range of student experience. Where more than one student appears to state the same thing the duplicates have been removed.

A key aspect illustrated by the responses is diversity. Some have prior experience while some do not. Some felt that the course moved too fast while others felt it was too slow. Some felt that too much was assumed about experience and ways of working. Our students are individuals.

Many students are positive that practical work is an effective way of learning. Other themes are that programming is interesting, challenging and rewarding, that making big things (meaningful programs in mini projects) is more interesting and fun than small exercises, that things need a meaningful context (such as examples that can be related to the real world), that good communication between staff and students is important as are support resources such as suitable books, sample programs and ready assistance with problems.

2. Responses to "The best thing about this module was..."

1. The practical work. There is no way that I would have understood most of the ideas from this module if I hadn't had the chance, during practicals, to implement them.
2. This module was challenging but did give a good sense of achievement when completing a piece of work successfully.
3. Learning a new language and gaining good programming skills.
4. The work was challenging but fun.
5. The staff were all very helpful if a problem should arise. In particular during the practicals.
6. The type of practical exercises. Towards the end of the module we were actually writing programs that we could use.
7. Learning how to program (to some degree) from scratch, having had no programming experience, and having something to show for it. This is very satisfying.
8. The course was on subject matter I had a particular interest in.
9. Learning to code at a decent pace, as well as the support staff being very helpful and understanding about problems had, with what is a totally new area to me.
10. I find programming very interesting so I have enjoyed this module, especially since the exercises that we have been doing hvae actually been quite interesting.
11. I have no idea... Honestly I was confused from day 1.
12. That Barry's book was very closely linked to the course so if I hadn't understood something in a lecture I could work at it at home.
13. Hard to think of anything - the biggest problem is that I've worked as a software engineer and so have covered most of the material in the module.
14. Learning OO programming in a language similar to C++ (makes future transition easier).
15. Doing small projects in the latter stages. Those were much more interesting and fun to have a go at rather than the individual pieces of work.

3. Responses to "The best way to improve this module would be..."

1. In the specifications for this module at the beginning of the year it stated that no previous computing experience was necessary. This is very misleading. Those of use without any experience have struggled all year to understand the terms used.
2. Maybe slow down the delivery speed of the lectures. Sometimes there was a lot of information given out very quickly.
3. The homework/practicals take too long.
4. Teaching staff able to teach beginners as well as the more capable students.
5. Lecturer X (lost me totally after a few weeks): used too much jargon, assumed too much prior knowledge at times, never explained a lot of concepts, just assumed we knew what they were.
6. The initial grading style assessment process was not very clear and there was a lot of assumptions made on the lecturers/demonstrators part that we knew what we had to do.
7. Lecturer X's Bin Packing example was stretched VERY thin to the extent. The example not only was meant to explain what I view as the most important thing to grasp in the entire course but the fact was that it was so dull and uninteresting and non applicable to real life that it bored people to tears. The Bank Manager and Fruit Pastilles examples were the best in the entire course for one reason and one reason only - they were applicable to REAL life situations. Everyone uses a bank and understands the concept of a transfer, deposit etc. The only people who pack bins are refuse collectors - and I don't really know a lot about that - except that if the bin is full you squish it down and then you can fit more in.
8. Go slower, and when OO is taught use a better example than bin packing.
9. Have more practical sessions. When I didn't understand something it was very difficult to catch up with it, or get help on it, since there was not enough time/demonstrators in the practicals to do so.
10. Make lectures more useful by having all the code for a program shown, not just fragments - this would give a better idea of how programs are to be structured. Make source code available over the intranet so that we can concentrate in lectures instead of copying out code.
11. Teach the core topics more carefully, especially for IP students who don't get as much practices as PDS students.
12. Fewer assumptions about the way we work. I don't use RealJ.
13. Have refresher classes, where you go over the practicals or something for the "weaker" members.
14. Do more - we seem to be constantly revising stuff!!!
15. Make Java easier to use to that even stupid people can use it! Make a good book on Java and don't go so fast, when you catch up it already sped a way like a runaway train.
16. Give the students a better opportunity to learn a brand new language and grasp the key features, so that a good knowledge of the language is known before the work becomes too difficult way too quickly...the way the practicals sped off in such increased difficulty it was very hard to be able to acquire a sound grounding in Java as I felt I was being rushed to get harder practical work in every week without having the time to fully understand and come to terms with a completely new language.
17. To speed up the earlier portions of the course to help people with programming experience.
18. More communication about the practicals that we have done and what they mean towards the year and everything. I currently have no idea if any of the work I have done means anything towards the year or if it has all been ignored with regard to the year.
19. Effective teaching methods need to be sought out! I found lecturer X extremely confusing and this gave me a bad start to the course. I am now better but only because I read Barry's book over Christmas, which made everything make sense.
20. Aim the letures to a slightly more technological end and don't assume that the students are moronic...
21. Not having to do Noddy practicals at the start of the year when some students, like myself could have improved their programming etc. by doing more complicated work.