|Teaching and Learning Forum 2000 [ Proceedings Contents ]
Giving control to students: But will they pick up the ball and run?
School of Information Technology
One of the keys to enabling students to learn more effectively is to give them opportunities to be responsible for their own learning. This is not always easy to do in the university environment and is not always welcomed by students. Students may be apathetic or unwilling, for various reasons, to participate in activities created by the unit coordinator. In this paper I will describe an experimental lesson in COBOL, in which I attempted to give more control to the students for a specific learning task. I will describe the results of this experiment, from my observations, and also the students' reactions to this attempt.
Bickmore-Brand believes that an important facet of learning is "developing in learners the capacity to accept increasingly more responsibility for their learning". (Bickmore-Brand, 1996) At the same time she stresses the need to support learners in this process, so that they are able to take risks and learn from their mistakes. This paper explores an attempt to encourage students to take more responsibility for their learning in a class teaching a programming language, COBOL, which is traditionally taught in the 'chalk and talk' mode.
The unit and the students
Data Processing Using COBOL is an optional second year unit in the Information Systems Bachelor Degree Programme, which aims to teach the students the basics of the COBOL language, with particular emphasis on its place in the mainframe environment. The unit emphasises good practices, such as designing applications using pseudocode and structure charts before coding, and using structured coding techniques. The benefits of COBOL as a record-based language and the importance of rigorous testing are also major themes of the unit.
The structure of the course takes a problem solving approach, with new concepts being explained and then various programming problems, using these concepts, being completed in class, then by the students and finally implemented in tutorial classes on personal computers. From my own experience and that of others, this problem solving approach is the most effective for student learning of COBOL (Citron, 1984). The small size of the class (approximately twenty students) enables a large amount of student-teacher and student-student interaction within the lecture times.
I had tried, unsuccessfully, to get the students to participate more in class. In a typical class I would have pre-set exercises (in the Study Guide) which I would allow the students time to complete in class, whilst wandering among students to help those with problems. At this point in the lecture I would try to encourage students to write their solutions to the exercises on the whiteboard. This was never successful and since I had only had the class for a short period of time, I did not feel comfortable with 'picking on' someone. My only experience of this was discouraging. The next best strategy was for me to write on the whiteboard and them to call out what they had written. This had a number of problems:
In order to counteract these problems I devised the lesson as described below.
- The same people did all the work
- Many people just copied down what I said and did not attempt the exercises
- Different people had different ways of completing the exercise (often all equally valid) and this was difficult to rationalise on the board and difficult for students to follow, especially when they are just coming to terms with the language.
The experimental lesson
Prior to the lesson students had been introduced to the basic concepts of the language required to construct their initial program. These included opening and closing a file, reading a record, testing for end of file and writing a record. Each of these constructs had been explained in terms of the syntax of the command, how it is used and what it does. Simple exercises had been completed by the students on each of these commands. Further, the students had been involved in using simple, complete programs in a tutorial session. These exercises involved making minor changes to programs to become familiar with the language and the software used to develop the programs.
I introduced the specification for the program to the students and together we defined the variables required for the program. This gave the whole class time to 'digest' the problem and ensured that we all started from the same point. I then allowed the students to form into groups of three or four. I allowed them to form their own groups to give them a sense of security, as this was the first group activity that I had attempted with them. There were four groups formed. Each group was given several sheets of overhead transparencies and an overhead pen, and given the task of writing the commands required to complete the program using the commands that they had been taught in the previous lessons. I walked around looking to help students.
My observations of the lesson
My first observation was that I had many more questions from the students than was normally the case. Many of them did not seem to know how to get started and one group in particular was very antagonist about completing the exercise.... it was clearly 'outside' their comfort area. The level and content of the questions asked gave me a great insight into how much of the material covered in the previous lessons the students had understood. This was very useful for me in future lessons.
Each of the groups appeared to complete the task in a different manner. Some worked together well and some worked separately for a while and then shared their answers. The antagonistic group spent most of the time telling me that they did not know what it was they were supposed to do and yet in the end completed the task at least as well as the other groups. A further note - each of the members of that group received a grade of HD for all the assignment work they completed. My assessment is that the learning style being used did not suit these students.
This exercise took a long while and it was fortunate that I had the students for a two hour lesson. If I had had to break the exercise because of time restrictions I think it would not have been as successful.
When the students had completed their programs I gave them a short break and talked to them, informally, about what they had done. I also quickly looked at the four programs to discover what they had created. I was pleased to see that they had all done a reasonable job. Each program did have at least one error and each group had a different type of error. One group had syntax errors, one had misunderstood how a particular command worked, one had left out a considerable amount of the processing required and the final group had a logic error that meant that the program would have an infinite loop.
Reflection and peer review of student work
Boud, Keogh and Walker emphasise the importance of reflection to the learning process and state that "we believe that the more teachers and learners understand this reflective aspect of learning and organize learning activities which are consistent with it, the more effective learning can be." (Boud, Keogh and Walker, 1985) I wanted to give the students an opportunity to reflect on their work and to assess the work of their peers. I reconvened the students and told them that they had all done quite a good job. I then explained that we would look at each of their attempts and try to discover what was wrong with them. I emphasised that they should be nice to each other as they had all made mistakes and this was their first attempt. I placed each of the programs, in turn, on the overhead projector and asked the students to explain any errors they could find in the program. In general, the students were very quick to see the errors in the programs and we discussed ways that these errors could be remedied.
The learning experience
My intent was to make the students really engage with the language, as I was not convinced that students had done this in previous lessons. Laurillard recognises this problem when she states "while the teacher does all the planning, hands out precepts, and asks the questions, the students can easily fail to engage actively with her way of thinking. We have to address how learners are to engage with knowledge derived from someone else's experience." (Laurillard, 1993) I tried to make the lesson so that it would appeal to all the different learning styles as outlined by Kolb. (Kolb, 1984). The students had to conceptualise the program as a whole by using the various components of the language to make a whole program (abstract conceptualisation). The development of the program was a cyclic process with all groups making several attempts before completing the task (active experimentation). The students had to write the drafts and the final product on overhead sheets and had had prior experience of similar and completed programs in tutorials (concrete experience). The students analysed and debugged their own code and other group's code (reflective observation).
The student's reactions
Anecdotal evidence led me to believe that in general the students found this class very beneficial in their learning of the COBOL language. I interviewed three of the students to get a better idea of their reactions. When asked if this lesson was better than the usual method of conducting classes, the different students had different ideas. For example two replies follow:
"I think it works the same way, because you make us do it ourselves before you do it on the board"
One student reflecting on the two types of lessons offered the following, which I trust was useful to his discovery of how he learns best:
"Yes, definitely - we were thrown into the deep end and that is when we do the work, whereas on the board we were dependent on you. I know you were not spoon feeding, but we thought that if we didn't do them, we knew that you would do them for us, sort of thing - why not wait for the right answer? The new way you could pinpoint the people who could not do it."
"After you had done the work on the board, then it was up to me and what I should have done was take the code and enter it into the computer so that I could see it would run. If I had done that, that would have helped me to learn. So maybe you could formalise that, so after a lecture you have to enter the program into the computer and see what it does... actually see what it does... so you get the practical application. When I did do that I understood that part of the code."
I asked the students if reviewing the programs on the overhead was helpful. Two of the replies were:
"The overhead helped us to visualise what the program should look like. We all had different errors, I didn't think about the logic errors."
Further, 100% of students surveyed in a subsequent teaching survey, said that they agreed or strongly agreed with the statement:
"The overheads were helpful, because I learnt what I had done wrong from the critique of the group and it wasn't embarrassing. There was a third year student and he was very helpful. I think we all learned from our mistakes. We made one or two mistakes, but everyone made some mistakes and so it was good... we got to see all the different types of mistakes that people made."
"This teacher encourages me to be responsible for my own learning"
My conclusion from this experience is that it is possible to move away from the 'chalk and talk' method, when teaching a programming language and that students can benefit from this practice. The fact that the work was completed as a group gave most of them a sense of security and enabled them to complete the work. However the fact that one group strongly resisted the exercise shows clearly that not all students will feel comfortable with this method of learning.
Further, I, as the teacher gained many insights into the students and their abilities. I was especially interested in the questions that they asked during the group work and their critique of each other's work.
Within the time frame of an undergraduate unit this time consuming method cannot be employed without considerable reduction of curriculum content, which is not generally acceptable. However, for one or two critical lessons, it could be of great value to the students and unit coordinator alike.
Bickmore-Brand, J. (1996). Bickmore-Brand's literacy and learning principles. In Stepping Out: Literacy and Learning Strategies, EDWA.
Boud, D., Keogh, R., and Walker, D. (1985). Reflection: Turning experience into learning. London, Kogan Page.
Kolb, D. (1984). Experiential learning. New Jersey, Prentice-Hall.
Laurillard, D. (1993). Rethinking university teaching. London, Routledge.
Ramsden, P. (1992). Learning to teach in higher education. London, Routledge.
|Please cite as: Downes, S. (2000). Giving control to students: But will they pick up the ball and run? In A. Herrmann and M.M. Kulski (Eds), Flexible Futures in Tertiary Teaching. Proceedings of the 9th Annual Teaching Learning Forum, 2-4 February 2000. Perth: Curtin University of Technology.
[ TL Forum 2000 Proceedings Contents ]
[ TL Forums Index ]
HTML: Roger Atkinson, Teaching and Learning Centre, Murdoch University [email@example.com]
This URL: http://lsn.curtin.edu.au/tlf/tlf2000/downes.html
Last revision: 19 Feb 2002. © Curtin University of Technology
Previous URL 27 Jan 2000 to 19 Feb 2002 http://cleo.murdoch.edu.au/confs/tlf/tlf2000/downes.html