A Collaborative Project to Improve Teaching
and Learning in First Year Programming
Faculty of Information Technology
Faculty of Education,
In 1995, at Monash University, first year computer programming students
in the Faculty of Computing and Information Technology were perceived as
having an unacceptably high failure rate and a comparatively low retention
rate. A collaborative project between the faculties of computing and education,
beginning with a study to identify the problems experienced by students
and staff, has resulted in a series of modifications to the structure and
delivery of the subjects, and the development of a tutor training course.
Responses of staff members and students have been mostly positive, and the
subjects are still being improved each year. The transition from high school
to university life, in which students were expected to adjust immediately
to a different style of teaching and learning, was part of the problem.
This paper describes the approach that has been adopted and which has resulted
in improved learning behaviours. It also demonstrates the way in which a
collaborative, cross-discipline approach to educational change can affect
the teaching and learning process.
In 1995, concerned at the percentage of first year students who were failing
or discontinuing their computing studies, the Dean of the Faculty of Computing
and Information Technology at Monash University asked the Faculty of Education
for help in improving the level of teaching expertise within the Computing
faculty. Most of the Computing staff have no formal teaching qualifications
or training, having been employed for their computing expertise. They tend
to base their teaching style on memories of lecturers or tutors that they
considered effective during their own undergraduate years. Their teaching
methods are therefore those that worked well for them, but that may not
work well for most of their students. Many environmental changes have taken
place in the last ten years or so, giving rise to a need for new techniques.
These changes include increases in class sizes, number of students per staff
member, and number of international students. Staff have had to develop
expertise in producing high-quality computer presentations, maintaining
subject websites and mastering other technological tools, all of which add
to the workload of running a subject.
The initial request by the Dean of Computing was for a series of seminars
on the latest teaching research and techniques. However, the Education faculty
declined to provide these, recognising that they alone were unlikely to
produce any real or lasting change in teaching behaviour. Faculty were also
concerned that the high failure rates may be part of a more complex, integrated
problem that was influenced by more than the teaching knowledge of academic
The Education faculty suggested instead a research project to determine
the source and nature of the problems in learning computing before any solutions
could be applied. Introductory programming was chosen as the focus of the
initial effort, as it is a subject taught in every course offered by the
computing faculty, although in very different ways for different courses,
and using different programming languages. Two Departments volunteered to
take part in the project: Software Development and Computer Science. The
Education faculty members were very unwilling to perform this research as
"outside experts", and so a collaborative team (the "Edproj")
was established to study the existing first year programming subjects in
the two Departments and to suggest improvements that could be made.
The Edproj team consisted of the Associate Dean (Teaching) of the Computing
faculty, two academics from the Education faculty, two lecturers in first
year programming from the Software Development department, and the assistant
lecturer in charge of coordinating and supporting the first year programming
subjects in the Computer Science department. A few other computing faculty
staff were also involved from time to time.
The two computing departments involved were on different campuses and had
different philosophies: Computer Science was part of the traditional university
with a primary interest in research, and Software Development was part of
a former College of Advanced Education which had been merged into Monash
University in 1990, and thus had many more staff members whose primary interest
was teaching. The focus of the Computer Science course was leading-edge
computing research, whereas the focus of the course taught by the Software
Development Department was best-practice in commercial applications of computing.
The responses of the two departments to the research project were different.
This paper focuses on the response of the Software Development department.
The Computer Science experience has been well documented in conference papers
such as Macdonald, Mitchell, Gunn & Carbone , and Carbone, Mitchell
& Macdonald .
The composition of the student body has changed since most academics completed
their undergraduate degrees, consisting now of many more students than before,
a large number of whom are international students with their own cultural
backgrounds and learning approaches. As more local students are also accepted
now, a wider range of abilities is found among them. There are full-time
and part-time students, day and evening classes, and large variations in
age, prior knowledge and experience, motivation, and expectations.
In the subjects run by the Software Development department, the number
of students enrolled at the beginning of a year was typically about 400.
In 1995, about a third of these would have had no experience of computing
at all, and almost all would have had no experience of programming. These
proportions have become lower each year since then.
In all computing courses in the Faculty of Information Technology, first
year programming is compulsory and is seen by most students as the most
difficult, least interesting and most time-consuming of their subjects.
This is partly because the kinds of programs now required, and the programming
languages in which they are written, are more complicated than those used
ten or twenty years ago. It is also because learning to program involves
research, experimentation, and problem solving, and many students lack these
skills and must learn them as well as the programming language itself.
Typically, students find the subject interesting at the beginning, but
by about week 5 find it becoming very challenging and requiring a great
deal of time. Some students begin to lose motivation and interest. Programming
is a particularly cumulative subject, as each concept and technique builds
on all the previous ones, and students cannot related it to anything they
have done before. It is not possible to ignore one topic if it proves difficult,
as that will block understanding of later concepts. Learning programming
requires great attention to detail, perseverance and a willingness to ask
for help when necessary: attributes not characteristic of first year students
grappling with a much broader transition to university.
The Teaching Staff
At the time of Edproj academics were promoted exclusively on the basis
of research, not on teaching performance. Teaching was therefore seen by
some as comparatively unimportant and some lecturers devoted as little time
as possible to it, concentrating their efforts on their research. Research
related to computing education was not considered worthwhile in the Computing
faculty. Staff who were interested in improving their teaching were not
rewarded for doing so, and were given very little support. Never-the-less
there were some staff who enjoyed the teaching role, and deliberately chose
to take on high load first year subjects. There were also a large number
of post graduate students, who depended on money earned by tutoring or demonstrating
in laboratories, who had an interest (albeit sometimes only pecuniary) in
In the Software Development department, there was a tradition that the
lecturer taught at least two tutorials in his or her own subject, to keep
in touch with how the students were coping with the material. All administrative
work related to the subject (e.g. handling tutorial timetabling and changes
to enrolments, liaising with the computer centre about computer laboratories,
writing and marking tests and examination papers, recording and collating
results, organising and coordinating tutors) was also done by the academic
staff. Many academic staff took tutorials in other subjects, to keep in
touch with what was happening in the rest of the degree program. Financial
constraints within the Department over the last 5 years had resulted in
reduced numbers of academics, an increased number of students, a consequential
increase in workload for staff, and hence increased pressure on them to
perform better with less support. Staff were also required to demonstrate
research productivity and perform administrative tasks not directly related
to their teaching (e.g. committee memberships).
Most of the tutors in the undergraduate subjects were postgraduate students.
In the Software Development Department, they were paid at a comparatively
high hourly rate for the two hours per class per week, but were expected
to contribute generously of their time to provide individual consultation
for their students outside class time, a minimum of one hour per week for
each scheduled hour of class time. They were also expected to help with
the administration of the subject as requested. Most were keen on teaching
and very willing to do all that was asked of them.
In the Department, the number of tutors engaged in teaching first year
programming was typically about 18, with some permanent lecturing staff
also tutoring - including the lecturers for the subject.
The Initial Study
The initial stage of the Edproj involved extensive observations by Education
staff of first year programming lectures and tutorials, interviews of all
lecturers and many tutors, and some interviews with students. A random selection
of students were invited to be case studies, and were interviewed each month
during the second half of 1995, to obtain in-depth qualitative data about
the students experience and perceptions. All members of the research
team were assigned students from a different campus to interview, so that
their interviews were not affected by the students' fears of possible repercussions.
Edproj guaranteed that staff members would not be disadvantaged by participating
in the surveys, observations and interviews, whatever results emerged. The
internal Edproj team members were also assured by the Computing faculty
that this research would be considered legitimate research activity, and
therefore worth the amount of time they needed to devote to it. An attempt
was made to collect data from larger numbers of students by surveying them
via email during the semester, but this was not very effective.
At the end of the semester, a report was presented to the Dean. This report
covered both departments that had been investigated and, although written
in a non-specific way, contained some observations that could have been
damaging to certain members of staff, so it was not made available to the
rest of the faculty. This engendered some resentment among tutors who had
participated in the interviews on the understanding that they would see
the final report, even though a summary of the recommendations was prepared
for them. It did, however, reflect the great sensitivity that exists in
any faculty area when academics feel that their teaching is under any sort
of review, and the conflict between transparency and confidentiality in
any research on teaching.
The primary finding reported was that the students were struggling to learn
well, and that the major learning vehicle for students was not the lectures
but the small group situations such as the tutorials in Computer Science
and the laboratories in both departments. Teaching quality varied widely
in that context, exacerbating some general problems students had in adjusting
to university both academically and socially. As the small group sessions
were important opportunities to meet other students and forge vital friendships
and study partnerships, the students experiencing didactic monologues that
discouraged or entirely prevented any student-to-student interaction were
being significantly disadvantaged in ways beyond the academic.
There were also recommendations about restructuring and redesigning the
content of the lectures, and providing discussion classes for students to
complement the existing closed laboratories. As the payment schemes for
tutors in the two departments were quite different, a recommendation was
made regarding this, too.
At this early stage the problems were seen as primarily teaching and learning
related, and the recommendations were made in that light. Subsequently,
as the recommendations were implemented and data recorded, it became apparent
that this issue was only a subset of the broader transition problem first
year students faced, and changes to the teaching and learning environment
could have far broader reaching affects than simply improving academic grades.
The data collected in the context of programming was remarkably consistent
to the Australia wide data of McInnes and James  when they looked at
the experiences of first year students, and a follow up DEETYA funded investigation
of the problem , suggesting that the problem was more than simply a difficulty
with teaching the challenging subject of programming.
Implementation of the recommendations
It was left up to the two departments to decide how they would respond
to the recommendations. As stated earlier, this paper is concerned with
the Department of Software Development response.
Students in a first year programming subject attended one two-hour lecture
and one two hour tutorial/laboratory per week. One recommendation was that
an additional type of class be provided for students, i.e. a one-hour discussion
class to be held in a room without computers. This class was to allow students
to talk about their understanding of programming concepts, as this is seen
as crucial to their learning. Small group activities would be used to stimulate
discussion and to encourage shy students to participate. Another reason
for introducing this type of class was that students would very quickly
get to know each other and begin to feel part of a group. One of the major
reasons for students dropping out of university in their first year is that
they feel isolated and not part of a community based around the institutions
. The entire class of about 400 was broken into tutorial groups with
a maximum size of 16, and the same tutor took each tutorial group for both
discussion class and lab session to assist in building a "learning
The two-hour lecture was changed to two one-hour lectures, with the discussion
class between them and a lab session after the second lecture. Observations
had shown that students tended to disengage with the lecture in less than
one hour, and two hour lectures were likely to be ineffective. At the lectures,
copies of all the PowerPoint slides were handed out to the students, so
that they did not have to worry about copying down what is being displayed,
and can instead think about what the lecturer is saying. This was considered
more effective than just making the slides available on the World Wide Web,
as students need to have the notes during the lecture, and it is much easier,
and ultimately cheaper, to print them en masse than to have 400 students
trying to find available computers in the labs to download and print the
notes before the lecture.
A three-day tutor training program, focused on teaching introductory programming,
was developed by the Edproj team. The program was to be run separately for
the two departments because of the numbers of tutors involved, and was to
be presented jointly by staff members from Education and the appropriate
Computing department. The structure and content of this tutor training scheme
are described in detail in Gunn & Macdonald . It focused largely
on how to run the discussion classes in ways that would promote quality
learning. Emphasis was placed on how to get students to talk and help each
other to solve their own problems with some guidance from the tutor, rather
than tutors supplying answers and solutions. Training was targetted to specific
needs of the tutors in the subject of programming, rather than giving "generic"
teaching tips that have are hard to translate into daily practice.
The Software Development Department took the initial report to the Dean
very seriously, and decided that not only would all first year tutors be
required to do the tutor training course, but also that all permanent staff
members should be involved in tutoring these subjects, in order to upgrade
their teaching skills. An advantage of this was seen to be that the most
experienced academic staff would be teaching the first year students, and
would provide the highest quality teaching experience. In fact, it became
evident that it was much easier to train a new tutor to use the modern,
student-focussed techniques espoused by the training course than to change
the ingrained habits of a staff member who had been tutoring for a long
time in a different way .
The tutor training program was followed up by a weekly staff meeting of
the tutors in the first year programming subject. The purpose of this meeting
was to reinforce the training program by reminding tutors of the techniques
taught in the training course, discussing attempts that had been made to
use them in the previous week with any successes, failures and possible
improvements, and ways that they might be implemented in the following week's
classes. At the beginning of semester, the lecturer asked for two student
volunteers (one male, one female) to attend these staff meetings and represent
the students point of view. These students were asked to talk to as
many other students as possible to learn of any problems. Their input to
the meetings was very valuable. If there was a problem with the workload
or understanding a particular concept, action would be taken to rectify
A "Teaching Community"  approach to the subject was adopted,
whereby the Lecturers in Charge were seen as being just part of the team
teaching a subject rather than as authorities handing down the work to be
done to subordinates. Tutors were expected to attend all meetings and contribute
ideas, suggestions, anecdotes, teaching materials, examination questions,
etc. Discussions took place each week about the "Big Ideas" to be taught
in the following week, and how they could best be taught in lectures, discussion
classes and lab sessions. The "Big Ideas" are the concepts and underlying
principles that students were intended to learn, rather than the implementation
details. For example, the lecture might be about functions and parameter
passing with examples using the syntax of a particular programming language,
but the Big Ideas might be abstraction and modularisation. Often there was
animated discussion in the tutors meetings about the meaning of a
particular concept in computing, as different tutors would have different
understandings of its meaning. Computing is a comparatively young discipline,
and many of its terms and concepts are still new. It is also changing constantly.
It is important that the view presented by the tutors matches the view of
the lecturers, otherwise students become confused. Tutors were also encouraged
to attend the lectures so that they were familiar with the approach that
the lecturer was taking.
The most important part of the Teaching Community meetings was the opportunity
for the tutors to discuss likely student misconceptions and to develop specific
teaching strategies that would give opportunities for the students to interact
with each other, build relationships, and construct meaningful understanding
of the key concepts. With so many committed individuals contributing, the
range of ideas and innovations generated each week was remarkable.
For the first two years, the tutor training course was presented jointly
by Computing and Education staff, and an Education staff member attended
the weekly tutors meetings. This lent a voice of authority to discussions
about teaching and learning, and assisted the process of interpreting the
experiences of the tutors in terms of the training course concepts. Since
then, the Education involvement has ceased, and Computing staff are running
the training program and the tutors meetings alone. This has made
it more difficult to convince some new tutors of the validity of the teaching
philosophy, but also reflects the development of educational expertise in
the ongoing staff.
Helping students with programming problems
As it is at about week 5 of the first semester that many students start
to fall behind and lose interest in the subject, at this point a test worth
about 10% of the total marks is given. It is intended to be reasonably easy,
so that it builds up students confidence, however, anyone who fails
it sees that he or she has serious problems and needs to address them immediately.
Tutors advise anyone who has failed the test to seek individual help, but
most such students do not do so.
To make it easy for students to get help almost immediately with programming
problems, several kinds of assistance are provided. Tutors are rostered
onto a helpdesk for one hour per week for each tutorial they take. The helpdesk
is a well advertised room, that is open for much of the week, equipped with
computers and other resources where students can seek help about any aspect
of the programming subject. This helpdesk replaced the system of each tutor
being required to specify consultation times for his or her own students.
Because there are about 24 tutorials in the subject, there are about 24
hours scattered throughout the week that this service is available, including
some convenient for evening students. Students can bring their programs
along and ask for help. Tutors will not simply correct the code, but will
prompt the student with questions to help them to find the solution to the
problem themselves. Some students find this very frustrating, become angry
and resentful, and give up using the helpdesk, but most understand that
it is necessary to learn to solve their own problems, and that this is the
way to do it.
There is also a website that contains all the documentation for the subject,
including the subject handbook, PowerPoint lecture presentations, weekly
exercises, assignment specifications, etc. It also has examples of how to
do some things that students traditionally find difficult, and a frequently
asked question file. Perhaps the most important element is an anonymous
feedback page in which students can ask questions or make comments about
the subject. The feedback postings are automatically emailed to the lecturers
and a few of the tutors, so that someone usually responds to a posting within
a couple of hours. This facility is described in detail in Hagan , and
has become more popular each year since it was introduced, with over 800
postings during semester 1, 1999. It also gives students some sense of ownership
of the subject, as they can see that their concerns elicit an immediate
response and can produce changes in the way the subject is run. Anonymous
feedback has been much more effective than a newsgroup, as many first year
students are very reluctant to identify themselves when asking questions
or making comments, although this reluctance diminishes as they progress
through the course and become more confident .
Students are also able to email the lecturer or their tutors directly to
ask for help. They are encouraged to read the lecture notes and the textbook
first, and to try other sources such as online help and their peers, before
turning to staff for help.
Preparing students for the subject
One of the problems with transition seems to be that students have unrealistic
expectations of university life. They imagine either that it will be just
like school, or that it will be a harsh, uncaring place where they will
be left to sink or swim on their own.
Students in the Bachelor of Computing degree attend a presentation by the
course leader during enrolment time, where she explains that they are expected
to spend on average 48 hours per week on their studies, and that undertaking
too much outside work is very risky. She also explains that there are many
people in the university who are willing and able to help them, and that
asking for help when it is needed is a smart thing to do, and not a last
resort when they have already failed subjects. Most students either ignore
this advice, or are in such cognitive overload, due to the barrage of new
information to which they are exposed, that they do not register it.
At the first programming lecture, the lecturer warns the students that
this subject will probably require more time and effort than the others,
and that 12 hours per week of study is a reasonable estimate for it, not
an exaggeration. They are also shown all the avenues of help available to
them, and the advantages of getting to know other students and helping each
other with work are discussed.
At the first discussion class, an icebreaker activity helps students to
get to know one another. Students are then put into small groups to discuss
what they see as the role of the tutor and the role of the student. The
small groups then report to the entire group. The tutor makes sure that
he/she uses the names of the students at all times so that, within a couple
of weeks, everyone knows everyone elses name. If necessary, for the
first couple of weeks students have their names printed on cards in front
of them. Furniture is rearranged so that students are not sitting in rows,
with their backs to other students, facing the tutor at the front of the
class. Horseshoe or table groups put emphasis on fellow students as a learning
resource, and de-emphasise the centrality of the tutor as a source of all
In the laboratory session each week, students implement some of the techniques
they have been shown in the lecture and have considered in the discussion
class. A tutor takes the same group of students for both the discussion
class and the lab session, both to ensure continuity of concepts, and to
foster a sense of belonging among the students and to help them to get to
know each other and form a learning community. They are encouraged to work
collaboratively on the exercises during the lab sessions. Students are discouraged
from changing tutorial groups, although this is impossible to prevent entirely.
Depending on how much change has taken place in the membership of the group
since the last class, it may be necessary to run more (and different) icebreaker
activities in weeks after the first. This progressive engagement of the
students in the subject and its requirements has proved the most effective
way to induct students to the university.
Monitoring the effect of the changes to the subject
As mentioned earlier, an attempt was made to interview students via email
from time to time, but this was not very successful. A far better method
was to use the subject website, and ask all students at the beginning of
a tutorial in each of several weeks to respond to a radio-button survey.
This survey asked questions about how well the students were coping with
the subject, which types of classes they found most useful, how useful they
found the textbook, the website and handouts given in lectures, etc. The
results of the surveys were mostly positive, and were used to progressively
"fine tune" the resources.
A survey of tutors after the subject was finished indicated that most enjoyed
teaching the subject more after the training course, felt more confidence
in their teaching ability, and found the tutors meetings of great
benefit. For many the sense of belonging within the faculty that was generated
by their integration into the teaching community was a significant factor
in their enjoyment of their own research agenda, as well as their teaching.
Measuring improvements in performance of students is not a simple matter
of comparison of marks from one year to the next. Exam marks are probably
one of the least reliable and valid measures of learning, but retain their
premier position due to the lack of a universally accepted alternative.
Exams are set to be similar each year, but inevitably vary in difficulty
and in the weighting of content topics. Particularly in computing the nominated
content changes from year to year as the subject evolves or new programming
languages assume dominance. Teaching staff change. Cohorts of students vary
as fashions in degrees wax and wane.
So many variables were changed by the intervention in all its manifestations
that it is difficult to ascribe any particular cause and effect between
a variable and exam marks with any mathematical significance, even if the
variable could be quantified. Academic performance may have been the driving
force of the original Edproj collaboration, but as previously mentioned,
the many issues that affect student performance in first year particularly
are influenced in many subtle ways by changes to the learning environment
that may not be directly driven by teaching. The ability to make friends
and build a social and learning community may result in a student being
better integrated into the life of the university, with a greater resistance
to discouragement and withdrawal. Such a student is likely to do better
in formal assessment, but this is hard to directly attribute to icebreakers
and group work in tutorials, though they may have played a very important
part in initiating the social interactions.
All the above qualifiers may seem like the "softening up" for
poor results, but in fact comparisons of tests, exams and assignments before
and after the intervention showed strong improvements, improvements that
have been sustained for several years. Overall results for the subject have
shown a sustained one grade improvement for those students who pass the
subject, compared to the performance prior to the intervention. In 1994
28% of students gained a High Distinction, in 1995 31% gained HD, and in
1996 40% gained HD. Performance on the exam was judged by the lecturers
in charge to show much greater understanding of the main concepts of the
subject, with less dependence on recall of information. However the exam
was more weighted for this type of knowledge and it is impossible to generate
comparison statistics. The proportion who fail the subject remain at similar
levels, however, suggesting that the academic difficulty of the subject
is not as important in the overall transition experience of the students
as had been assumed.
The increase in grades could be dismissed as a "lowering of standards",
but other data suggests that this actually represents an increase in students
The students sat two unit tests during the semester, which contributed
to the overall mark. During the second semester of 1996 the average score
on the first test rose from 61.21% in 1995 to 70.46% in 1996, while the
second unit test showed a less impressive rise of 62.87% to 67.06% average.
With around 300 students included in the analysis these results are statistically
significant, but for the reasons described above we hesitate to claim them
as definitive proof of better learning.
The most compelling data for the Edproj team was the observational data
collected by a team of trained research assistants from the education faculty.
Two measures were taken, the "good teaching behaviours" or GTBs,
and the "good learning behaviours" or GLBs. Ongoing research in
education, particularly in secondary schools, has related particular overt
behaviours of students to be closely associated with learning outcomes of
a "deep" kind [10, 11, 12; also 13 for "deep" learning].
When these are observed to be occurring in the classroom it is a strong
indication that quality learning is in progress. Similarly there are teaching
behaviours that are closely associated with these GLBs incidence in students.
Some of the more fundamental measures were the number of open questions
being asked by the teacher, and the time spent by the class in discussion
that did not directly focus on the teacher, but involved student-to-student
Prior to the intervention the GTBs were rarely seen, but after the training
course, and with the support of the teaching community, the average number
of questions asked in tutorial classes rose from 26 per class in semester
one to 49 per class in semester two. Similarly the amount of time spent
in class discussion (out of a nominally 60 minute class) rose from 20 minutes
in semester one to 27 minutes in semester two.
The GLBs also showed remarkable increases: Student generated questions
rose from an average 8.6 per class in semester one to 11.2 per class in
semester two; while extended responses to questions (which involved the
student explaining a point of view not simply giving an answer) increased
from 4.6 per class in semester one to 12.6 per class in semester two
a 174% increase over the interventions first year, and a total transformation
from the previous year.
Student interviews also gave anecdotal data suggesting an approach to learning
that valued understanding as an outcome, and regarded peer learning as a
significant contributor, was far more common that prior to the intervention.
Students also appeared to be more interested in the subject, better adapted
to the university, and more positive about their university experience than
the students interviewed during the research phase, though the number involved
was too small to be definitive. Similarly, the feedback gained from the
anonymous feedback page was also generally positive, though there was no
comparison data available from prior to the intervention.
Although each of the data sources taken alone are hard to defend as conclusive,
the triangulation of the various data collected suggests that there has
been major shift in the learning approach and learning outcomes of the students
in first year programming.
The changes made to the structure and delivery of the first year programming
subjects have resulted in better learning behaviours in students and an
improvement in teaching on the part of lecturers and tutors. There is more
of a community approach to the subject among the tutoring staff, rather
than an attitude of doing what the lecturer says. Students appreciate the
amount of help given to them in this subject, as compared with their other
subjects. In general, student results in the first year of the changes showed
an upward shift of about one grade in the students who were passing the
subject. There are still a number of students who fail or drop out, and
more research is being undertaken to address this problem. There are more
students taking programming electives in later years of the course, and
more choosing to specialize in software development rather than some other
aspect of computing. This indicates that the changes made to the subject
have had some success, and there is ongoing research to try to improve the
subjects still more, and to help students with the transition into university
The authors gratefully acknowledge the financial support for the Edproj
project of the Faculty of Computing and Information Technology and the Department
of Software Development of Monash University.
The authors acknowledge the work of the rest of the Edproj team, especially
Anne MacMillan, Ian Mitchell, Judy Sheard and Angela Carbone; webmaster
Jason Lowder; research assistants Freya Gunn and Meaghan Walsh; all the
lecturing and tutoring staff of the first year programming subjects in the
Bachelor of Computing degree; and the student representatives in those subjects.