Design principles for programming tasks to elicit metacognitive behaviours in first year students
Angela Carbone, Ian Mitchell, Dick Gunstone, John Hurst
Abstract
In most introductory programming courses, tasks are given to students to complete as a crucial part of their study. However, often the tasks have not been considered by academics as a vehicle that can guide the ways in which students approach learning. In this paper, a set of guiding principles is presented for designing programming tasks aimed to elicit metacognitive behaviours in first year students. Researchers who have contributed to the study of metacognition believe that the instruction of metacognition can facilitate learning. The main source of data gathered for this study is provided by first year programming students that studied in two different Information Technology degrees. The students provided written descriptions of their engagement in various programming tasks that led to either successful or unsuccessful learning. Passages from their stories were coded under two aspects of metacognitive behaviours: self-appraisal and self-management. The results highlight features of programming tasks that can influence the students' use of metacognitive behaviours. Based on these findings, the paper concludes with a list of design principles to be considered when formulating programming exercises to improve student learning.
This research stems from a study that commenced in 1995 at Monash University. The study aimed to tackle perceived problems in the teaching and learning of first year programming . The main concerns were high failure rates, a low flow of students into higher degrees, and a perception of a wide variation of teaching skills amongst the academic staff. A research team, comprising academics within the Faculty of Information Technology (FIT) and academics within the Faculty of Education, focussed a study on the nature of learning and teaching in some departments of FIT. The research project team was known as Edproj.
Edproj gathered data via student interviews, tutor and lecturer discussions, and classroom observations. Comments from a number of tutors and lecturers suggested that they felt "metacognitive actions" (defined below) are behaviours needed in a university environment. Yet, the data gathered indicated that most students rarely engaged in metacognitive behaviours, in that they did not reflect on what they did and did not understand, and they lacked strategies for improving their learning. The nature of the programming tasks seemed to accentuate this. For example, a number of tasks were reported by tutors to have been solved and completed by copying "slabs" of code directly from the textbook. Tutors' comments include:
Concepts were lost because students weren't expected to write any of the sorting procedures themselves, most copied the code straight from the lecture notes
Students copied straight out of the lecturer notes without getting the stack concept
A number of students reported difficulty in transferring the ways they learnt in other subjects to their programming subject. It was "different" and they did not know what to do about it. Findings from the Edproj investigation revealed domain-based reasons for some of the difficulties that students experienced. For example, the cumulative nature of programming, the "big ideas" were often obscured from the students by the high demands of coding, and the laboratory situation often generates cognitive overload in novices .
The Edproj investigation revealed that most of the lecturers, demonstrators and tutors preferred students to take a thoughtful approach to their work, yet often students did not do this. This research raises the following questions that are of interest and discussed in this paper:
This paper provides a brief review of the research literature in an attempt to answer the first question. It then details the research methodology and reports on themes that emerged from the data collected. These themes, described in the results section of the paper, provide a useful starting point for focusing on the second question; namely the characteristics of programming tasks that lead to the desired metacognitive experiences required by first year students studying programming. The paper concludes with a set of design principles to apply when devising programming tasks, to encourage metacognition in students in order to improve their learning, thereby addressing the third question.
The ability to monitor one's knowledge and learning processes is no trivial matter as far as education is concerned. The following literature review discusses some of the research and theory behind the concept of metacognition. The literature indicates that students can enhance their performance by becoming aware of their own thinking as they read, write and solve problems. In this paper we argue that academics can promote this awareness directly by designing activities to enhance metacognition and learning. What follows is some of the research that defines metacognition and supports its importance in academic learning.
Metacognition has been defined simply as thinking about thinking, cognition of cognition, or using Flavell's words, "knowledge and cognition about cognitive phenomena" (p. 906). Flavell suggests that metacognitive thoughts are deliberate, planful, intentional, goal-directed, and future-oriented mental behaviours that can be used to accomplish cognitive tasks . Research into metacognition suggests that learners need to become aware of the processes of their learning, as distinct from the content they are learning, to improve their learning outcomes .
Metacognition has also been defined as an "awarenessness of one's own cognitive together with the use of that self-awareness in controlling and improving processes" . Metacognition is the notion of thinking about one's own thoughts and has been described as the process of reflecting, exploring and linking, and basically understanding one's thinking . Those can be thoughts of what one knows (i.e., metacognitive knowledge), what one is currently doing (i.e., metacognitive skill), or what one's current cognitive or affective state is (i.e., metacognitive experience).
There are many definitions of metacognition that have similar meaning. The definition of metacognition adopted for this paper is one that Paris and Winograd believe most researchers recognize, that is metacognition "captures two essential features- self-appraisal and self-management of cognition" (p. 17). Self-appraisals are people's personal reflections about their knowledge states and abilities, and their affective states concerning their knowledge, abilities, motivation, and characteristics as learners. Such reflections answer questions about "what you know, how you think, and when and why to apply knowledge or strategies" . Self-management refers to "metacognition in action," that is, mental processes that help to "orchestrate aspects of problem solving" (p. 18). Focusing on self-appraisal and self-management helps to conceptualise learners as individuals who need to be actively involved in the orchestration of their knowledge construction.
Metacognition appears to be a central feature of learning; those who are better managers of their thinking are judged to be better learners, and more often metacognitive processes play a major role in learners' successes in acquiring new knowledge. Metacognitive research includes studies that have examined ways in which metacognitive theory can be applied to education. Broadly defined, these studies have focused on a fundamental question - Can instruction of metacognitive processes facilitate learning? The researchers who have contributed to the present volume of literature, along with many other researchers and educational practitioners, have responded to this question with a resounding yes .
What follows is a discussion of three aspects of metacognition and their importance to student learning. These are seen as critical for effective learning. As Butler (1995) contends, "Theoreticians seem unanimous--the most effective learners are self-regulating" (p. 245). The key to effective self-regulation (self-appraisal) has been described as "an accurate self-assessment of what is known or not known" . Hence, only when students know the state of their own knowledge, can they effectively self-direct learning to the unknown.
Importance of knowledge about your own thought processesAn important aspect of metacognition is a learner becoming aware of the processes of their learning. Houssman investigated metacognitive processes through student self-reporting journals and found that students who were aware of their metacognitive processes, and who monitored their own learning processes, became more proficient learners in a computer class compared to those who did not monitor their metacognitive processes. As educators we can provide many opportunities for students to develop their metacognitive actions and foster good learning behaviours.
Another important aspect of metacognition is how well students manage their time and effort when they are working on complex tasks. Types of management include:
According to Biggs metacognition involves the three aspects described above. With respect to programming, metacognitive actions might be suppressed or extended via overt instruction about processes of learning or by the nature of the task, or they may be an innate characteristic of some students. In this study we are focusing on the nature of the task including how it is written and presented to the students. As the aim of this study is to produce a set of design principles to help student develop a plan of attack, monitor their progress and evaluate their plan of action, Bigg's self questions have been reworked into ones more suited to elicit metacognitive actions in students studying programming. Some typical questions that might be woven into the task to assist students in developing a plan of action, might include:
While maintaining/monitoring the plan of action, tasks can be designed to encourage students to ask themselves the following questions:
Finally when evaluating the plan of action, programming students should be asking themselves:
One approach to achieving self-management is to use interactive multimedia tools that have been specifically developed to help remind students of planning, monitoring and regulating their own learning . Nardoo is one such tool that provides students with the necessary prompts to be able to monitor their cognitive processes and to be able to regulate their learning. However, most academics would prefer students to be independent by devising their own self-questions.
Importance of beliefs and intuitionsThe third aspect of metacognition in the literature considers what ideas a student brings into their work, and how that shapes the way they tackle problems. Students construct knowledge depending on what they already know, their previous experiences, how they have organised those experiences into knowledge structures and the beliefs that they, as individuals, use to interpret their own realities of the objects and events within the world. This aspect of metacognition does not appear to be as important in the domain of programming as it is in science. We have found only a very few idiosyncratic examples of students’ prior beliefs about programming influencing their learning.
Research Methodology
A variety of data collection techniques were used, including semi-structured student interviews, recordings and feedback from tutors at the tutor meetings and written descriptions of students' engagements in the programming tasks. This broad based data was complemented by more intensive data collected from two groups of first year students studying programming. These students provided written descriptions of their engagements in those programming tasks that left them with a powerful impression of either successful or unsuccessful learning.
The two groups of students that provided data studied the C programming language in the first year of a Bachelor of Computer Science (BCS) in 1998. The second group studied the Visual Basic (VB) programming language in the first year of a Bachelor of Information Management and Systems (BIMS) in 2001.
The first student group attended a short course in semester 2 of 1998, titled "Learning how to Learn". This course was designed to provide students with frameworks to analyse and describe their own learning so that rich data could be gathered on complex factors and issues. Two types of insights were sought: (1) insights into the students' perceptions of the issues currently surrounding their learning in programming and (2) insights into their engagement in tasks that left them with powerful impressions of either successful or unsuccessful learning.
The short course was announced to all first year students enrolled in the BCS at the start of semester 2, and was intended to be attractive to students who wanted to improve their learning. Of the nineteen students that volunteered to participate in the study, only seven participated in all eight workshops. Of the seven participants, four females and three males attended regularly. Surprisingly, students who volunteered had received high marks (in the range of 78%-91%) for their semester 1 exam. It was therefore, presumed that these students would have very good learning behaviours to start with. When they were asked why they decided to participate in this course, they said that they had heard that the second semester unit was far more difficult than the first and they were fearful of not maintaining their grades. Although the sample of first year Computer Science students was skewed towards the higher achieving students, the study was not aimed at generalising the findings to the population, but to understand what students were doing and their reasons for their actions. This issue is revisited in the conclusion section of the paper.
The group of BIMS students did not attend the short course, instead part of the material provided in the "Learning how to Learn" course was embedded within their programming unit. This provided students with an opportunity during the VB programming classes to explore their learning behaviours, and write reflectively about their learning of programming.
The workshops were conducted in the first four weeks in semester 2, 1998: two one-hour sessions per week. A series of eight workshops covered the following topics: deep and surface approaches to learning , poor learning tendencies and good learning behaviours . Between seven to ten students participated in each session. Small numbers allowed for authentic discussions and also allowed time for each participant to present information about their own learning and engagement in various tasks. Notes and small exercises were used to structure the sessions, with the researcher directing the sessions.
Students were expected to write two cases based on incidents where their engagement in a task or part of a task left them with a powerful impression of successful or unsuccessful learning. It was intended that the study would reveal insights into the nature of student learning in the programming context, and the characteristic programming tasks that directed their learning. In the sessions students had an opportunity make notes and discuss the following five stimuli items:
These stimuli were used to help the students plan and develop their written cases. This qualitative approach ensured that rich data was collected on complex interrelated factors and issues, enabling thick descriptions of their accounts. This method of collecting data was particularly successful, in terms of the deepness/richness of the data gathered, and was subsequently used as a method of data collection with the first year students studying Visual Basic programming in the Bachelor of Information Management and Systems, 2001. Extracts taken from the students' written cases are reported in the results section of the paper.
No attempt was made to quantify the data, rather an attempt was made to gain a deep understanding of its meaning. Miles and Hubermann describe a number of systematic approaches interpretivists use to gather and analyse qualitative material. Two approaches were taken to analyse the data gathered in this study. The first approach involved starting with the broad metacognitive categories and concepts presented in the literature and sorting the data into each of these categories. The second approach was to formulate common themes emerging from the students' written stories using the constant comparative method .
Reports on codes were then examined and codes merged and revised. The final coding system reflects those themes observed across students' stories and those issues salient to participants. This paper reports on the themes that relate to how tasks can influence students' metacognitive actions.Two limitations with this data collection approach were the reliance on the students' self-reports about their learning approaches adopted, and the researcher's relationships with the participants. First, students submitted self-reports of their engagements in the tasks without any observation to confirm the validity of their descriptions. Second, qualitative research should be open, honest and fair . This requires researchers to critically examine the research context, the role they play, and the power-relationships involved. Caulley and Lindsay suggest considering the relationship between the researchers and the participants, the interests the research serves, and the audience of the research. These contextual factors play an important role in the credibility and trustworthiness of the research.
This study has characteristics in which the relationships between participants involved power differentials. First, the investigation was conducted by the first author, a permanent academic Monash staff member, actively involved in the teaching of programming, who could possibly influence student marks. However, students were informed that the tasks offered in each course were set up as targets, and that their discussions and comments were openly taken on board to improve the quality of tasks for the benefit of their own learning. The data gathered suggests that this did not pose a concern; students frequently critiqued the tasks.
Second, the researcher was also responsible for the selection and recruitment of the tutors that participated in the Computer Science study, which could have implications for quality of the tutors' contributions in the meetings. This power differential may have implications for the truthfulness of contributions. However, the researcher was also a support person for the tutors. In 1997, the researcher ran the Tutor Training Programme to help tutors with problems they faced with the teaching of programming. Every effort was made to ensure that the power-relationship was minimised by adopting a collegial and collaborative atmosphere in gathering the data. This did not seem to pose any problem given the quality and nature of the comments.
The results presented below are organized under the two aspects of metacognition described above, reflecting the foci of this investigation. Comments are provided in italics along with the source of the data (interview, tutor meeting, written description) enclosed in parentheses. The comments are reported in a way that teases out aspects of metacognition in a fine-grained manner. Although this might appear artificial and messy, its purpose is to help readers to make associations between the two broader aspects of metacognition. Based on the results presented, the paper concludes with a set of design principles for writing programming tasks to encourage metacognition in students.
Knowledge about thought processesWorking in small groups enabled students (who were aware of their own thought processes) to comment on the lack of metacognitive strategies their fellow team mates demonstrated. As expressed by one student lacking awareness of thinking processes was a common occurrence amongst many first year students:
About half of my group for this exercise did next to nothing, mainly because they didn't have the code and the answers thrust at them before the application was due. These people rely on being taught the stuff, and then putting it to use. If they don't know how to do something they give up and say "I don't know how to do it"… the calculator example was meant for students to learn how to experiment and acquire knowledge needed to develop an application. Many of the students missed out on this lesson because they left the coding up to group members who knew more about VB than they did. [written case]
Key lesson learnt:
Study skills required at university are different to those required at the secondary school level. At secondary school much of the students’ progress is kept and monitored by their teachers, yet at university this is an activity expected of students. Students that lack skills to monitor their knowledge often find themselves lacking motivation and unaware of what is causing their laziness. A student wrote:
I was too distracted and lazy to concentrate on the learning task at hand. Independent learning requires us, as students to want to learn and not be forced by others to learn. Maybe I still thought I was in high school, and expected the teacher to come around, instructing, "Get to work! Where are you up to? What? You should be up to here by now…". The other reason why it was an unproductive activity was that I had the opportunity to learn what I missed out on during the lecture and ask for help but I did not take up the opportunity. I regret that now because as I study for the final exam, my preparation could have been that little bit easier if only I had not been so lazy and did not engage in such unsuccessful learning periods. Instead, I have to pay the price now by putting in extra effort in making sure that I understanding VB applications for my own benefit. [written case]
Key lesson learnt
When interviewed, some students reported feeling that they could not proceed onto another problem until they had their current programs working, despite whether they had learnt anything or understood the concepts. While students were not restricted in the type of learning approach they could take, it was particularly inviting for students to copy slabs of code directly from the text book with tasks that lent themselves being completed by that method. Some comments made by students include:
I copied the program to create a stack from the lecture notes. I couldn’t understand "pop()" and I didn’t understand the difference between "s->top and s.top" [student interview]
I had managed to get the first four questions working simply by copying sections of the code from my lecture notes. I didn’t really understand what was happening to the frame pointer, stack pointer, parameters and return values. I could just see that it worked, somehow. [student interview]
While it is interesting to see that, although students could have adopted a number of strategies to complete their programming tasks, many adopted ones that were directed by the task at hand.
Key lesson learnt:
Tasks that provided detailed step-by-step instructions, leave little opportunity for students to develop a plan of action to complete the task. So typical questions, like those listed in section 2.2.2, that one might expect programming students using metacognition skills to raise, were not stimulated. Although students realised this, they did not attempt to control or improve their metacognitive processes. An example is provided below.
This activity involved attaching an existing database to a VB form. I call this particular activity unsuccessful learning. My reason for this is that we were given step-by-step instructions on how to complete this task, which to me wasn’t really learning it was merely following a set of easy instructions. I believe it would’ve been more successful if members had to use VB help to discover for themselves how to complete the task. I know it may have taken some time to complete but I did not learn how to complete this task on my own and if I were asked to do it again I wouldn’t know how to without the step by step guide. I believe group members relied on the instructions and did not register how to complete the task on their own. [written case]
In hindsight, the whole experience was an illustration of unsuccessful learning because I was unable to approach the learning with flexibility and develop a plan to make the experience a success. [written case]
In contrast to the above comments, were other students who believed that if they could follow step-by-step instructions, or follow the code, then they have learnt to program. For example:
Not giving us clear step-by-step instructions I believe can lead to unsuccessful learning, because when the student has difficulty in completing a certain task it’ll remain stuck because it does not have clear instructions to go by to be able to successfully complete the task and hand in knowing they have gone well. [written case]
Highlighted by the passage below is a student's awareness of the difference, realizing that learning involved more than simply following step-by-step instructions or being able to regurgitate facts. Although this student realised his lack of understanding, he lacked strategies to do anything about it.
I finished the exercise, and did it well enough to hand in and finish with the studio lesson, but that is all I really achieved. I could now run through the code and tell you what it means, basically decipher the syntax and coding, but that does not constitute successfully learning. Just because I can regurgitate what another person told me does not mean I have learnt anything because I have not developed an understanding. [written case]
It is a common pitfall amongst many students that they believe that, if they can follow step-by-step instructions or complete a task, they have understood the concept. It was pleasing to see that some students who managed to complete the task were aware of the gaps in their understanding.
Key lesson learnt:
Knowledge about self-management issues
Some students attempt to understand what the problem is about before hastily attempting a solution. This may also involve planning how they should proceed or taking on a particular course of action. The students below indicate that this promoted positive self-perception, and motivated their learning:
The activities required me to create applications that included: Do…Until Loops, Do…While Loops, For…Next Loops, and User Defined Types. I found this activity fairly easy to complete, mainly because I had done a little planning before I started to design and code the applications. My planning included sketching what I thought would be my design and writing pseudo code for the operation of the application. [written description]
Using knowledge obtained from previous activities, I was able to plan what I thought the application would look like, what the coding should basically include, and fairly accurately predict the outcome of the application. If I had forgotten anything that I required to complete the application, I simply referred to my notes of previous activities and lecture notes. [written case]
… The preparation was a relief. We were required to draw a binary search tree, write a declaration for one and also draw table and write a declaration for a hash function. All of these tasks I found quite easy as I felt I had a good grasp of both binary search trees and hash functions. [written case]
A feature of the domain of programming is that programming is extremely cumulative, in that there is no opportunity to "shelve" a tough topic. Aspects of one lesson are usually required in the next. This implies that for students who have understood earlier work, planning a solution becomes easier. However, for students that remain confused or stuck on a concept, planning for the following task almost becomes impossible.
Key lesson learnt:
In most programming units students have difficulty managing their time. Despite efforts to manage time, many students saw the demands of the tasks and pressures to handle events outside the capabilities chew away their time. This usually meant that not enough time was left for students to build an understanding of the concepts. As in the case with the following student, the student originally wanted to build an understanding of the problem at hand. However once this became a very time-consuming activity with limited success the student opted for strategies that limited their learning:
After a good fifteen minutes, the underlying sense of it all was not sitting quite nicely, as I would have hoped. The sample code seemed to be making sense, but I was struggling to gain an overall picture. I considered spending more time looking at my notes. But time was running short and I had a prac to finish. In the hope that my actually implementing the code would concrete the concept, I dove straight into it… but hit the ground very quickly. Now I was getting impatient. "That’s it", I thought, "I will do this the crude way. I will copy the notes." So that is precisely what I did. [written case]
With many programming tasks, it is common for students to spend much of their time debugging their code. Some make conscience decisions not to devote large amounts of time to this aspect of programming:
I had little patience to spare at the moment with exams approaching like a mad dog to a piece of meat and ten billion other projects/ assignments/ pracs to complete – none of which were easy, mind you. However, I decided to do the best I could on this prac, but I would not devote any large amounts of time to problem solving or de-bugging – I just could not afford to at the moment. [written case]
Yet others are unable to continue unless their code is bug free. Often, pass grades are only given to those that demonstrate a working piece of code; otherwise, they are at risk of failing. This pressure to demonstrate working code within a limited amount of time available often causes students to miss valuable lessons spent in the process of debugging, to produce working solutions.
… It wasn’t even a very big mistake, like one misplaced instruction or something, but because the SPIM emulator ‘MIPS’ was so unwieldy, it took me close to 2 hours to find the fault, which would not have been found with commenting. I don’t feel like I learnt anything of value, except that MIPS is incredibly frustrating. I knew how to do the prac - I could see it ticking over in my head, but I at least needed to get it working to get a pass grade. That was also frustrating - all of my energies went toward ’marks’ instead of ‘learning’. It would have been an invaluable prac, but as it was, I walked away with naught but a headache. [written case]
…there have been times when I have been left with a sense of unsuccessful learning. This feeling usually has many sources, for example if I have wasted all day trying to fix some bits of code that won’t fix, maybe because we hadn’t been taught properly how to do the activity or because the computers don’t have a help file. I feel that I have not learnt all that I should have [written case]
A significant dimension of programming that needs considerable attention is the dependence on the technology that often results in time-consuming problems that cannot be managed by the programmer. An inevitable part of working with new and ground breaking technology is that often the equipment may be faulty, the software is not behaving as it should, or unpredictable network failures occur. Again students see this as a source of frustration, not beneficial to their learning experience, and something that is beyond their ability to manage and control. A student wrote:
It was the Week 9 activity on Help files. The tutorial sheet, had quite clear instructions on how to complete the requirements. The only problem was that the programs didn’t actually work. This, however, I didn’t find out until I had fiddled with the activity for a couple of hours. This was both a very frustrating and annoying experience. At the end of the studio session I had not completed the activity and had spent most of my time trying to get it finished. Although it wasn’t directly my fault that I couldn’t finish it, I still felt that I had not achieved what I should have from the activity. This was one of the most frustrating experiences I have had with Visual Basic. [written case]
What seems particularly interesting about programming is that no matter how well students plan to manage their time and effort when working on a programming task, they are often confronted by unexpected technical difficulties, which they have little or no control over. It is common for academics teaching programming to feel the need to set tasks that require coding and the use of a computer, in fact not all activities should require the use of a computer to master concepts. Often the technology - the hardware and software - can be an obstacle to students' learning rather than helping them to self-regulated their learning. Many students spend time debugging programs that have not been clearly thought through because of their haste to 'get on the computer'. Given that this may be the case, academics need to think about appropriate strategies that encourage students to reflect what they have learnt from their experiences rather than superficially completing the task at hand.
Key lessons learnt:
The next quote was used earlier to show a student’s poor ability of time management, but also shows that novice programmers find planning difficult and continue to work on a problem even if they are unsure how to proceed. This makes monitoring or keeping track of how well they are going difficult, because they do not really know where they are heading.
In the hope that my actually implementing the code would concrete the concept, I dove straight into it… but hit the ground very quickly. [written case]
However, when they arrive at the right outcome they need to reflect on their actions, as highlighted in the following case.
Although confused at first I managed to realize and understand the concept behind the next two activities. Confused at what I just completed, I took a break and looked back at what procedures and steps I undertook to see how I completed the exercise. [written case]
Key lessons learnt:
The focus of this research was to explore factors of programming tasks that influence the process of metacognition: reflection, exploration and linking.
This paper describes and discusses a subset of many issues raised by students during their engagement with programming tasks in their first year of study. In particular it focuses on those issues surrounding characteristics of tasks that influence certain metacognitive actions and learning behaviours in students. The results presented in this paper are largely derived from the thematic analysis of the written descriptions provided by students of their engagement in the programming tasks. These results provide a useful starting point, for producing a set of design principles for programming tasks to encourage the use of metacognitive skills in students.Overall, the impression one obtains is that the tasks can influence the metacognitive behaviours of our students. This study provides valuable evidence suggests that tasks can be designed to direct the learning behaviours of the students. These insights along with an understanding of the student’s learning situation are useful in devising guidelines for designing programming tasks that academics can apply. Given that the majority of the written cases came from some of the better students studying Computer Science, is that it would be unlikely that less successful students would be any more metacognitive.
A summary of the features of programming tasks that might discourage metacognitive behaviours in students are presented in Table 1 below.
Table 1: Features of programming tasks that discourage metacognitive behaviours in students
|
Feature of task |
Intended student behaviour by lecturer |
Student behaviour |
|
Solution to exercise can be directly copied from the notes |
Expects student to refer to notes for clarification purposes only |
Copies directly from notes |
|
Tasks that give step-by-step instructions |
Expects students to follow steps, and experiment afterwards |
Little opportunity to plan and experiment |
|
Tasks that don't require students to record and monitor their activities |
Expects students to consider what they are doing and why |
Laziness and lack of motivation may settle in |
|
Tasks that don't require the logging of errors encountered, possible explanations and suggestions for fixes |
Expects type and cause of error is understood |
Interesting insights are ignored and seen as time wasting lessons, nothing valuable to be gained. |
|
Tasks that don't require students to report on unpredictable problems |
Expect students to explore the problem |
Lack of understanding of nature of the problem |
|
Tasks that don’t reward students for discovering interesting "technical" insights |
Expects students to take a life-long learning approach, discovering technical insights to be competent programmer |
Ignores the value in understanding the problem and ways to fix it |
|
Tasks that don't encourage and reward experimentation |
Expects students to explore and be engaged |
Treats task as a hurdle requirement |
|
Task or equipment contains an unintentional problem or error. |
Expects students will take this in there stride and still focus on key ideas |
Key ideas completely lost. Very high level of frustration, angry and loss of motivation settle in. |
|
Does not prompt student to discuss plan of attack |
Analyse different approaches to tackling a problem |
Does not collaborate or see need to reflect on approach adopted |