Affective Aspects in Learning and Teaching Programming
Abstract
Learning programming evokes strong emotions in people. These emotional responses can be either positive or negative. In this paper we start by looking at how we as educators can utilise these responses. The affective domain in education focuses on the feelings associated with learning. We describe some traditional educational theories on affective education and how they could apply to learning programming. We argue that affective issues are important and educators should be aware of them. One of our aims is to see if there are practical ways in which we as educators can increase the level of affective attainment of students and in so doing improve their cognitive development in programming.
Introduction
Anyone who has programmed is aware of the “highs” associated with success and the “lows” associated with a program that will not work. These emotions can often be extreme (we look at some examples of such extreme emotions in the following section). In this paper we are not only talking about these emotional responses, but also the broader issue of how programmers feel about programming, such as to what extent they are willing to accept or value a new programming concept.
Our aim in writing this paper was to attempt to develop some understanding of the dimension of
feelings in learning programming. There is clearly a link between achievement and feelings: if we
succeed, we feel good and this encourages us to succeed more. There is also a reverse link. If we
feel bad about a subject this can cause a major block to success. In a study of a CS1 course, McKinney & Denton (2004) showed that affective factors including interest, perceived competence and value were significantly correlated with course grades. We therefore ask whether there are ways in which we can influence learners’ achievement and therefore their feelings and whether there are ways in which we can influence learners’ feelings and therefore their achievement.
In this paper we firstly look at the topic of emotional responses in the context of learning to program. The aim is to see whether we can use these responses to achieve educational objectives. We then look at affective objectives as defined in the taxonomy of Krathwohl et al. (1964), and see how these can apply to learning programming. Finally we discuss the close relationship between the affective and cognitive domains, and how this interdependence can be used to facilitate attainment of both cognitive and affective objectives.
Emotional responses
Students often experience strong emotions when learning to program. The following two quotes were extracted from a journal written by a school teacher learning to program in a new language (quotes marked with an asterisk have been translated from Afrikaans into English):
Saturday 27/09/03: “Somewhere there is a mistake in my Tree class’s setRate method, but I can’t find it. I feel so stupid!!! And frustrated!!!” *
Sunday 28/09/03: “What a wonderful feeling to eventually succeed after so much struggle and frustration – now I feel so CLEVER!!!!!” *
Here we see a teacher’s emotions swinging from one day to the next from feelings of frustration and stupidity (punctuated by 6 exclamation marks) to the wonderful feeling of being clever (punctuated by 5 exclamation marks!). Similarly we found most teachers’ journals littered with emotive words and phrases like: “I feel terribly pleased with myself”*, “I am ready to throw in the towel”, “It gives me such a kick”*, “learning another language can be a painful experience”, “the fact that it did what I wanted was a miracle”, “I HATE Java with a passion”, “Java is like a drug. Certain people just get hooked!!”
This kind of emotional energy is evident in our learners. Do we as educators understand this energy and are there ways of harnessing it?
Positive emotions
In this section we look at the “highs” of programming. The positive emotions that result from success in programming can serve as an important motivator for further success. As the following teacher expressed: “What made all the trouble worthwhile was when I managed to get
something right. Then I would tackle the next section eagerly and enthusiastically”*. What is it about programming that makes it so enjoyable? If we understand more about when and why these emotions arise, it could help us to ensure that there are sufficient opportunities for motivation at different stages of a course.
In the “Mythical Man Month”, Fred Brooks (1982) gives a number of reasons as to why he thinks programming is fun: “First, it is the sheer joy of making things. As the child delights in his mud pie, so the adult enjoys building things, especially things of his own design.” Students seem to derive great pleasure from successfully writing a program which performs a task which they have devised themselves. For example, the following teacher (after having been shown how to do simple textual output in Java) decided to draw a tree shape using stars. He wrote the following in his journal:
“I am thoroughly enjoying learning about Java… I think what influenced me was when I wrote my very first program. It went something like this [code listing with 4 output statements which draws a tree shape] … the fact that it did what I wanted was a miracle. The fact that I understood what I had done was an eye opener to me. It demystified computers for me and I was immediately curious as to what else I could do”
The fact that the program did what he wanted he saw as a miracle. This supports Brooks’ idea that the adult enjoys building things, “especially things of this own design”. To keep motivation high, we should therefore build in enough opportunities for students to devise and implement some of their own ideas at appropriate stages of a programming course. We also need to ensure that these ideas are manageable, because success (the program working) is critical to the resulting positive feeling. Incorporating simple graphics or the use of colour at an early stage can be especially motivating for students – probably because the results of the program running (which is what students need to see) are more dramatic.
The second point made by Brooks is:
“Second is the pleasure of making things that are useful to other people. Deep within, we want others to use our work and to find it helpful.” To fulfil this desire to develop programs that are useful to others, we need to give students problems that are relevant (or could lead to problems that are relevant) to keep motivation high. This couldfollow on from the simpler “irrelevant” problems which initially only satisfy students’ need to make something that works, as observed by the following teacher: “With graphics, learners become excited when they learn how to draw houses, but they soon start to question the application value of these programs.”
For interest, we list the remaining points made by Brooks:
Thirdly, “… the fascination of fashioning complex puzzle-like objects of interlocking moving parts and watching them work in subtle cycles, playing out the consequences of principles built in from the beginning.” He equates this to the fascination of the pinball machine and the jukebox mechanism.
Fourthly, is the enjoyment of continually learning, because programming is generally nonrepetitive in nature.
Finally, is the enjoyment that comes from “working in such a tractable medium”. From a pure idea, a programmer can produce a concrete program which produces visible outputs. In summary, the practice of programming has an inherent motivational quality which we as educators should use. Some of the ways of maximising motivation is to ensure that students achieve visible success with initial programs; they have opportunities for implementing their own ideas and they are given problems that are relevant or will lead to programs which could be useful to others.
Negative emotions
Unfortunately, not all experiences of programming are positive. Just as the “highs” of programming can be very motivating, so the “lows” can be extremely demotivating. One of the reasons why programming can result in such extreme negative emotions could be because it requires us to perform perfectly (Brooks, 1982). The smallest, most trivial error can result in a program that does not work at all.
These “lows” of programming cannot be avoided. As educators we need to try to equip student with coping mechanisms. Skills such as debugging skills, being able to collaborate with others, problem solving strategies, etc. can help students to move out of the doldrums of programming.
We can, however, do more than this. The nature of programming can present us with the opportunity to develop affective competencies such as selfcontrol and confidence (Elliott & Peelle, 1975).
Programming is an environment where both success and failure occur on a regular basis. When a
program does not work (failure), things will not improve unless the programmer does something
about it. It also does not help to “take it out on the computer”, since the computer does not respond. In this way the programmer can learn self-control and that he/she has to take responsibility for improving the situation. For this learning to take place, the educator may need to act as the facilitator:
acknowledging and discussing feelings, so that students can develop the consciousness of self and
control over emotions. If students can learn to deal with their emotional reactions to failure in programming, it could help them to deal with failure in their own lives in more mature ways. So we see that maturity in dealing with emotions is an affective outcome that can be developed because of the nature of programming. Are there other affective objectives which we should be aiming to achieve with our students? In the next section we look at affective attainment in general, and see how this applies to programming.
Affective objectives
There are affective objectives besides emotional maturity that we strive for in teaching programming. For example, we want our students not only to understand concepts, but to value them and apply them because they believe in them. Krathwohl et al. (1964) proposed a taxonomy of affective educational objectives which specifies levels describing feelings, emotions and degrees of acceptance in learning. This taxonomy was developed subsequent to the well-known Bloom’s taxonomy on the cognitive domain (1956). Although cognitive objectives were generally considered to be the most important component of learning, and the easiest to evaluate, many educators affirmed the importance of affective objectives in teaching and learning. Krathwohl, Bloom and Masia therefore set about specifying a taxonomy for the affective domain equivalent to Bloom’s taxonomy of the cognitive domain.
The affective domain Krathwohl’s taxonomy of affective objectives describes a continuum, from merely being willing to receive and accept new ideas, through to constructing a world-view of beliefs and values, in the form of a hierarchy of levels. Note that this hierarchy does not specify levels of intensity of emotional responses; Krathwohl et al. describe it as a continuum of increasing internalisation. In other words, the levels describe degrees to which learners attach personal value to ideas. Each of the levels are divided into sublevels. In the following table we describe these levels and their sublevels and provide an example relevant to object-oriented programming.
Students can be at different affective levels at different stages of learning. For example, consider
the following comment made by a teacher: “OK, I have been naughty. I suppose it is because I have built up this aversion for Java. I walk past the books and the computer and just keep going; I feel I just cannot any more!”. This teacher is not even on Level 1 of affective attainment. Her ‘aversion’ to the subject is forming an obstacle to her ability to receive the material.
As a further example, consider the following:
Students were given a problem to solve in Java which involved the user typing in any even integer and the program continually halving and printing this until the number became odd. One student’s program included the following comment:
// I am going to try to solve this
// problem in an object-oriented
// way. Change Ex9b to a class
// called Halve which is called by
// the main program below. I will
// also do method overloading. *
Although object-oriented principles had been introduced in this course, the student called the class “Halve”. This was a poor choice of name since it did not describe an object but rather a process. His application of method overloading was also flawed in that it resulted in duplication of code. What is interesting about this example is the willingness of the student to apply object-oriented ideas when not specifically required. This student was therefore at level 2 of affective attainment. Even though he did not fully comprehend object-oriented principles, he was showing a positive response through his willingness.
We have attempted to show that the affective taxonomy as described by Krathwohl et al. is applicable to learning programming. But should specific affective objectives be built into teaching programming, and if so, how can this be done? Affective objectives in programming As teachers of programming, we do not merely want our students to understand the concepts and principles of programming. We also want them to believe that these concepts and principles are worthwhile. When they have to work as programmers in their jobs, we trust that they will resist the temptation to produce quick-and-dirty solutions, even when they are under time or other pressures. We hope that they will gain personal satisfaction from writing good code. The only way that they will make good programming practice a personal issue is if they have internalized the concepts and principles and made them their own.
We can add affective objectives to the desired outcomes specified in the curriculum statement of our programming courses. For example, consider the following objectives:
• the student should become aware of the advantages of code re-use
• the student should develop an appreciation for good code
• the student should develop an attitude of positive self-criticism in order to debug code
/ produce better programs
Although these objectives depend on cognitive abilities, each expresses an affective aim. The keywords in this case are: “become aware”, “develop an appreciation” and “develop an attitude”.
Of course, to make the specification of such affective objectives meaningful, we need ways of
achieving them. One way this can be done is by utilizing the interdependence of cognitive and
affective objectives.
The link to cognitive attainment
In this section we briefly describe the cognitive domain and discuss its interdependence with the
affective domain.
The cognitive domain
Bloom’s taxonomy (Bloom, 1956) was developed prior to Krathwohl’s affective taxonomy. It proposes a hierarchy of cognitive educational objectives, each level representing a type of cognitive learning or understanding of increasing complexity. In the following table we briefly outline these levels and provide an example relevant to object-oriented programming.
Bloom (1956) divides each of the levels in this hierarchy into sublevels. We do not discuss the hierarchy (interesting as it is, particularly in its application to learning programming) and the sublevels any further in this paper. We refer the reader to Bloom (1956) for a more detailed exposition of what these categories represent and to Scott (2003) and Masterson & Meyer (2001) for examples of its application to programming. Although we distinguish between the cognitive and affective domains, this does not mean that we believe that human beings have them as separate faculties. This is supported by Scheerer (1954): “... behavior may be conceptualized as being embedded in a cognitive–emotional–motivational matrix in which no separation is possible. No matter how we slice behavior, the ingredients of motivation– emotion–cognition are present in one order or another”. The cognitive and affective domains are therefore simply different aspects of behaviour as seen from different points of view.
We now discuss the mutual dependence of cognitive and affective attainment, in particular affective attainment leading to cognitive attainment, cognitive attainment leading to affective attainment, and the alternation between the two. Affective attainment leading to cognitive attainment Krathwohl et al. (1964) state that one of the main affective ways of promoting cognitive attainment is by increasing interest and motivation. Students “are more likely to learn and remember material for which they have a positive feeling”. An affective stimulus is often necessary to open the door to receiving and understanding; to engage and draw the student into the learning experience. As we discussed in the section on “Positive emotions”, motivation can be increased through fun programming exercises (by using graphics, for example).
Apart from overtly motivational techniques, there are small scale affective objectives lower down on the hierarchy that are intimately connected to and even a prerequisite to cognitive development. The first level of the hierarchy of affective objectives is Receiving. The student has to have a positive disposition towards, not just learning programming in general, but also to the specific concept being dealt with, to be able to receive and understand it.
This means that if there are affective blocks preventing cognitive attainment, these need to be addressed before effective learning can take place. As discussed before, to motivate students, programming examples should preferably solve meaningful problems. If a student's immediate reaction to an example is “What does the program do?” and there is no answer besides “It illustrates the concept”, then the example will probably constitute an affective stumbling block to the student receiving the concept. Even if the example does solve a problem, but the student's first question is "But who would ever write a program to do this?" there is a danger of a negative affective effect.
Abstract or meaningless examples can alienate the learner from the concept being dealt with, especially when there is no handle to grasp and connect/relate the new concept to something which is already known or understood.
Cognitive attainment leading to affective attainment
Being able to apply programming concepts successfully has a positive affective outcome, as the following quote from a teacher shows: “With programming in general I find that what influences the pupils most positively ... is that they can see results of their labours and when they start to gain enough knowledge to be a bit creative then this motivates like nothing else.” Conversely, students’ failure to understand makes them feel negative towards programming: “The biggest problem for me is writing classes. Therefore I have a negative attitude towards programming with Java. But I know that once I understand classes, I might feel different about it.”
In a certain sense, higher level affective objectives can only be attained after the cognitive objectives of understanding and being able to apply concepts and principles. Valuing and believing in a concept or principle is a product of having understood and applied the concept or principle in various situations and needs time to develop. For example, we cannot hope that our students will believe in the power and usefulness of object oriented programming before they have understood what it is and how it can be applied.
Note that we are not saying that the development of desirable values is a guaranteed consequence of having attained certain cognitive competencies. For example, a student may fully understand classes and be able to write them when required, but might prefer to put everything in the main method when not specifically required to use classes. This would be because they don’t value classes (an affective goal).
Alternating attainment
Sometimes it is not easy to tease out which comes first: affective or cognitive attainment. They either occur simultaneously, or an instance of affective attainment at a particular level leads to some cognitive attainment, which in turn leads to affective attainment on a higher level, and so on. As Krathwohl et al. put it: “In some instances, the joint seeking of affective and cognitive goals results in [the use of] one domain as the means to the other on a closely-knit, alternating basis.”
As an example, consider the following scenario. Say we want our students to be able to apply the
concept of inheritance. (This represents a cognitive objective.) To attain this objective, a student first needs to be willing to pay attention to (i.e. receive) an explanation of inheritance (affective attainment level 1). This hopefully leads to some understanding of what inheritance is and why it is useful (cognitive attainment level 1). Only with some understanding can the student respond positively to further examples, seeking out instances of inheritance (affective attainment level 1) and testing them against her understanding to see if they match up, making adjustments to her understanding if they don’t (cognitive attainment level 2). A willingness to practically try out the new concept (affective attainment level 2) is needed before the student implements exercises using inheritance (cognitive attainment level 3). Satisfaction in her efforts (affective attainment level 2) is important in gaining the confidence needed to try further problems using inheritance (cognitive attainment level 3). Through the application of good examples, the student sees the power and usefulness of inheritance and starts valuing the new concept (affective level 3). Since the student believes in inheritance, she chooses to use it often and through this practice develops the ability to analyse when inheritance is appropriate to solve a problem (cognitive attainment level 4).
In this way the affective and cognitive stages feed into each other, with attainment in one domain acting as a stimulus for attainment in the other.
Conclusion
As teachers of programming we have a unique situation. Strong emotions are inherent in the practice of programming and we can use them. In this paper we have shown, through practical examples, how educational theory on the affective domain is applicable to learning programming. The affective and cognitive domains are linked:
attainment in the affective domain can act as a stimulus, or even as a prerequisite, to attainment in the cognitive domain, and vice versa. In programming this relationship is particularly important to understand because the associated emotions tend to be so extreme. As educators, we can utilise this link in our teaching by incorporating affective objectives in our programming courses.
References
Bloom, B. S. (Ed.) 1960. Taxonomy of Educational Objectives, Handbook I: The Cognitive Domain, New York: Longman
Brooks, F.P. 1982. The Mythical Man-Month: Essays on Software Engineering, Addison- Wesley Publishing Company.
Elliott, P.C. and Peelle, H.A. 1975. “Computer Augmented Teacher Training”, SIGCUE Outlook 1, si (January 1975):19-30, ACM Press.
Krathwohl, D. R., Bloom, B. S. and Masia, B. B. 1964. Taxonomy of Educational Objectives.
Handbook II: Affective Domain, New York: Longman.
Masterson, T.F. and Meyer, R.M. 2001. “SIVIL: A True Visual Programming Language for Students”, The Journal of Computing in Small Colleges 16, 4 (May 2001).
McKinney D and Denton, L.F. 2004. “Houston, We Have a Problem: There’s a Leak in the
CS1 Affective Oxygen Tank”, in Proceedings of SIGCSE ’04, Norfolk, Virginia, USA (March 2004), 236-239.
Scheerer, M. 1954. Chapter 3: Cognitive Theory, in Handbook of Social Psychology, Volume I. Cambridge, Ass.: Addison-Wesley.
Scott, T. 2003. “Bloom’s Taxonomy applied to testing in Computer Science Classes”, The Journal of Computing in Small Colleges, 19:1 (October 2003).
Introduction
Anyone who has programmed is aware of the “highs” associated with success and the “lows” associated with a program that will not work. These emotions can often be extreme (we look at some examples of such extreme emotions in the following section). In this paper we are not only talking about these emotional responses, but also the broader issue of how programmers feel about programming, such as to what extent they are willing to accept or value a new programming concept.
Our aim in writing this paper was to attempt to develop some understanding of the dimension of
feelings in learning programming. There is clearly a link between achievement and feelings: if we
succeed, we feel good and this encourages us to succeed more. There is also a reverse link. If we
feel bad about a subject this can cause a major block to success. In a study of a CS1 course, McKinney & Denton (2004) showed that affective factors including interest, perceived competence and value were significantly correlated with course grades. We therefore ask whether there are ways in which we can influence learners’ achievement and therefore their feelings and whether there are ways in which we can influence learners’ feelings and therefore their achievement.
In this paper we firstly look at the topic of emotional responses in the context of learning to program. The aim is to see whether we can use these responses to achieve educational objectives. We then look at affective objectives as defined in the taxonomy of Krathwohl et al. (1964), and see how these can apply to learning programming. Finally we discuss the close relationship between the affective and cognitive domains, and how this interdependence can be used to facilitate attainment of both cognitive and affective objectives.
Emotional responses
Students often experience strong emotions when learning to program. The following two quotes were extracted from a journal written by a school teacher learning to program in a new language (quotes marked with an asterisk have been translated from Afrikaans into English):
Saturday 27/09/03: “Somewhere there is a mistake in my Tree class’s setRate method, but I can’t find it. I feel so stupid!!! And frustrated!!!” *
Sunday 28/09/03: “What a wonderful feeling to eventually succeed after so much struggle and frustration – now I feel so CLEVER!!!!!” *
Here we see a teacher’s emotions swinging from one day to the next from feelings of frustration and stupidity (punctuated by 6 exclamation marks) to the wonderful feeling of being clever (punctuated by 5 exclamation marks!). Similarly we found most teachers’ journals littered with emotive words and phrases like: “I feel terribly pleased with myself”*, “I am ready to throw in the towel”, “It gives me such a kick”*, “learning another language can be a painful experience”, “the fact that it did what I wanted was a miracle”, “I HATE Java with a passion”, “Java is like a drug. Certain people just get hooked!!”
This kind of emotional energy is evident in our learners. Do we as educators understand this energy and are there ways of harnessing it?
Positive emotions
In this section we look at the “highs” of programming. The positive emotions that result from success in programming can serve as an important motivator for further success. As the following teacher expressed: “What made all the trouble worthwhile was when I managed to get
something right. Then I would tackle the next section eagerly and enthusiastically”*. What is it about programming that makes it so enjoyable? If we understand more about when and why these emotions arise, it could help us to ensure that there are sufficient opportunities for motivation at different stages of a course.
In the “Mythical Man Month”, Fred Brooks (1982) gives a number of reasons as to why he thinks programming is fun: “First, it is the sheer joy of making things. As the child delights in his mud pie, so the adult enjoys building things, especially things of his own design.” Students seem to derive great pleasure from successfully writing a program which performs a task which they have devised themselves. For example, the following teacher (after having been shown how to do simple textual output in Java) decided to draw a tree shape using stars. He wrote the following in his journal:
“I am thoroughly enjoying learning about Java… I think what influenced me was when I wrote my very first program. It went something like this [code listing with 4 output statements which draws a tree shape] … the fact that it did what I wanted was a miracle. The fact that I understood what I had done was an eye opener to me. It demystified computers for me and I was immediately curious as to what else I could do”
The fact that the program did what he wanted he saw as a miracle. This supports Brooks’ idea that the adult enjoys building things, “especially things of this own design”. To keep motivation high, we should therefore build in enough opportunities for students to devise and implement some of their own ideas at appropriate stages of a programming course. We also need to ensure that these ideas are manageable, because success (the program working) is critical to the resulting positive feeling. Incorporating simple graphics or the use of colour at an early stage can be especially motivating for students – probably because the results of the program running (which is what students need to see) are more dramatic.
The second point made by Brooks is:
“Second is the pleasure of making things that are useful to other people. Deep within, we want others to use our work and to find it helpful.” To fulfil this desire to develop programs that are useful to others, we need to give students problems that are relevant (or could lead to problems that are relevant) to keep motivation high. This couldfollow on from the simpler “irrelevant” problems which initially only satisfy students’ need to make something that works, as observed by the following teacher: “With graphics, learners become excited when they learn how to draw houses, but they soon start to question the application value of these programs.”
For interest, we list the remaining points made by Brooks:
Thirdly, “… the fascination of fashioning complex puzzle-like objects of interlocking moving parts and watching them work in subtle cycles, playing out the consequences of principles built in from the beginning.” He equates this to the fascination of the pinball machine and the jukebox mechanism.
Fourthly, is the enjoyment of continually learning, because programming is generally nonrepetitive in nature.
Finally, is the enjoyment that comes from “working in such a tractable medium”. From a pure idea, a programmer can produce a concrete program which produces visible outputs. In summary, the practice of programming has an inherent motivational quality which we as educators should use. Some of the ways of maximising motivation is to ensure that students achieve visible success with initial programs; they have opportunities for implementing their own ideas and they are given problems that are relevant or will lead to programs which could be useful to others.
Negative emotions
Unfortunately, not all experiences of programming are positive. Just as the “highs” of programming can be very motivating, so the “lows” can be extremely demotivating. One of the reasons why programming can result in such extreme negative emotions could be because it requires us to perform perfectly (Brooks, 1982). The smallest, most trivial error can result in a program that does not work at all.
These “lows” of programming cannot be avoided. As educators we need to try to equip student with coping mechanisms. Skills such as debugging skills, being able to collaborate with others, problem solving strategies, etc. can help students to move out of the doldrums of programming.
We can, however, do more than this. The nature of programming can present us with the opportunity to develop affective competencies such as selfcontrol and confidence (Elliott & Peelle, 1975).
Programming is an environment where both success and failure occur on a regular basis. When a
program does not work (failure), things will not improve unless the programmer does something
about it. It also does not help to “take it out on the computer”, since the computer does not respond. In this way the programmer can learn self-control and that he/she has to take responsibility for improving the situation. For this learning to take place, the educator may need to act as the facilitator:
acknowledging and discussing feelings, so that students can develop the consciousness of self and
control over emotions. If students can learn to deal with their emotional reactions to failure in programming, it could help them to deal with failure in their own lives in more mature ways. So we see that maturity in dealing with emotions is an affective outcome that can be developed because of the nature of programming. Are there other affective objectives which we should be aiming to achieve with our students? In the next section we look at affective attainment in general, and see how this applies to programming.
Affective objectives
There are affective objectives besides emotional maturity that we strive for in teaching programming. For example, we want our students not only to understand concepts, but to value them and apply them because they believe in them. Krathwohl et al. (1964) proposed a taxonomy of affective educational objectives which specifies levels describing feelings, emotions and degrees of acceptance in learning. This taxonomy was developed subsequent to the well-known Bloom’s taxonomy on the cognitive domain (1956). Although cognitive objectives were generally considered to be the most important component of learning, and the easiest to evaluate, many educators affirmed the importance of affective objectives in teaching and learning. Krathwohl, Bloom and Masia therefore set about specifying a taxonomy for the affective domain equivalent to Bloom’s taxonomy of the cognitive domain.
The affective domain Krathwohl’s taxonomy of affective objectives describes a continuum, from merely being willing to receive and accept new ideas, through to constructing a world-view of beliefs and values, in the form of a hierarchy of levels. Note that this hierarchy does not specify levels of intensity of emotional responses; Krathwohl et al. describe it as a continuum of increasing internalisation. In other words, the levels describe degrees to which learners attach personal value to ideas. Each of the levels are divided into sublevels. In the following table we describe these levels and their sublevels and provide an example relevant to object-oriented programming.
Students can be at different affective levels at different stages of learning. For example, consider
the following comment made by a teacher: “OK, I have been naughty. I suppose it is because I have built up this aversion for Java. I walk past the books and the computer and just keep going; I feel I just cannot any more!”. This teacher is not even on Level 1 of affective attainment. Her ‘aversion’ to the subject is forming an obstacle to her ability to receive the material.
As a further example, consider the following:
Students were given a problem to solve in Java which involved the user typing in any even integer and the program continually halving and printing this until the number became odd. One student’s program included the following comment:
// I am going to try to solve this
// problem in an object-oriented
// way. Change Ex9b to a class
// called Halve which is called by
// the main program below. I will
// also do method overloading. *
Although object-oriented principles had been introduced in this course, the student called the class “Halve”. This was a poor choice of name since it did not describe an object but rather a process. His application of method overloading was also flawed in that it resulted in duplication of code. What is interesting about this example is the willingness of the student to apply object-oriented ideas when not specifically required. This student was therefore at level 2 of affective attainment. Even though he did not fully comprehend object-oriented principles, he was showing a positive response through his willingness.
We have attempted to show that the affective taxonomy as described by Krathwohl et al. is applicable to learning programming. But should specific affective objectives be built into teaching programming, and if so, how can this be done? Affective objectives in programming As teachers of programming, we do not merely want our students to understand the concepts and principles of programming. We also want them to believe that these concepts and principles are worthwhile. When they have to work as programmers in their jobs, we trust that they will resist the temptation to produce quick-and-dirty solutions, even when they are under time or other pressures. We hope that they will gain personal satisfaction from writing good code. The only way that they will make good programming practice a personal issue is if they have internalized the concepts and principles and made them their own.
We can add affective objectives to the desired outcomes specified in the curriculum statement of our programming courses. For example, consider the following objectives:
• the student should become aware of the advantages of code re-use
• the student should develop an appreciation for good code
• the student should develop an attitude of positive self-criticism in order to debug code
/ produce better programs
Although these objectives depend on cognitive abilities, each expresses an affective aim. The keywords in this case are: “become aware”, “develop an appreciation” and “develop an attitude”.
Of course, to make the specification of such affective objectives meaningful, we need ways of
achieving them. One way this can be done is by utilizing the interdependence of cognitive and
affective objectives.
The link to cognitive attainment
In this section we briefly describe the cognitive domain and discuss its interdependence with the
affective domain.
The cognitive domain
Bloom’s taxonomy (Bloom, 1956) was developed prior to Krathwohl’s affective taxonomy. It proposes a hierarchy of cognitive educational objectives, each level representing a type of cognitive learning or understanding of increasing complexity. In the following table we briefly outline these levels and provide an example relevant to object-oriented programming.
Bloom (1956) divides each of the levels in this hierarchy into sublevels. We do not discuss the hierarchy (interesting as it is, particularly in its application to learning programming) and the sublevels any further in this paper. We refer the reader to Bloom (1956) for a more detailed exposition of what these categories represent and to Scott (2003) and Masterson & Meyer (2001) for examples of its application to programming. Although we distinguish between the cognitive and affective domains, this does not mean that we believe that human beings have them as separate faculties. This is supported by Scheerer (1954): “... behavior may be conceptualized as being embedded in a cognitive–emotional–motivational matrix in which no separation is possible. No matter how we slice behavior, the ingredients of motivation– emotion–cognition are present in one order or another”. The cognitive and affective domains are therefore simply different aspects of behaviour as seen from different points of view.
We now discuss the mutual dependence of cognitive and affective attainment, in particular affective attainment leading to cognitive attainment, cognitive attainment leading to affective attainment, and the alternation between the two. Affective attainment leading to cognitive attainment Krathwohl et al. (1964) state that one of the main affective ways of promoting cognitive attainment is by increasing interest and motivation. Students “are more likely to learn and remember material for which they have a positive feeling”. An affective stimulus is often necessary to open the door to receiving and understanding; to engage and draw the student into the learning experience. As we discussed in the section on “Positive emotions”, motivation can be increased through fun programming exercises (by using graphics, for example).
Apart from overtly motivational techniques, there are small scale affective objectives lower down on the hierarchy that are intimately connected to and even a prerequisite to cognitive development. The first level of the hierarchy of affective objectives is Receiving. The student has to have a positive disposition towards, not just learning programming in general, but also to the specific concept being dealt with, to be able to receive and understand it.
This means that if there are affective blocks preventing cognitive attainment, these need to be addressed before effective learning can take place. As discussed before, to motivate students, programming examples should preferably solve meaningful problems. If a student's immediate reaction to an example is “What does the program do?” and there is no answer besides “It illustrates the concept”, then the example will probably constitute an affective stumbling block to the student receiving the concept. Even if the example does solve a problem, but the student's first question is "But who would ever write a program to do this?" there is a danger of a negative affective effect.
Abstract or meaningless examples can alienate the learner from the concept being dealt with, especially when there is no handle to grasp and connect/relate the new concept to something which is already known or understood.
Cognitive attainment leading to affective attainment
Being able to apply programming concepts successfully has a positive affective outcome, as the following quote from a teacher shows: “With programming in general I find that what influences the pupils most positively ... is that they can see results of their labours and when they start to gain enough knowledge to be a bit creative then this motivates like nothing else.” Conversely, students’ failure to understand makes them feel negative towards programming: “The biggest problem for me is writing classes. Therefore I have a negative attitude towards programming with Java. But I know that once I understand classes, I might feel different about it.”
In a certain sense, higher level affective objectives can only be attained after the cognitive objectives of understanding and being able to apply concepts and principles. Valuing and believing in a concept or principle is a product of having understood and applied the concept or principle in various situations and needs time to develop. For example, we cannot hope that our students will believe in the power and usefulness of object oriented programming before they have understood what it is and how it can be applied.
Note that we are not saying that the development of desirable values is a guaranteed consequence of having attained certain cognitive competencies. For example, a student may fully understand classes and be able to write them when required, but might prefer to put everything in the main method when not specifically required to use classes. This would be because they don’t value classes (an affective goal).
Alternating attainment
Sometimes it is not easy to tease out which comes first: affective or cognitive attainment. They either occur simultaneously, or an instance of affective attainment at a particular level leads to some cognitive attainment, which in turn leads to affective attainment on a higher level, and so on. As Krathwohl et al. put it: “In some instances, the joint seeking of affective and cognitive goals results in [the use of] one domain as the means to the other on a closely-knit, alternating basis.”
As an example, consider the following scenario. Say we want our students to be able to apply the
concept of inheritance. (This represents a cognitive objective.) To attain this objective, a student first needs to be willing to pay attention to (i.e. receive) an explanation of inheritance (affective attainment level 1). This hopefully leads to some understanding of what inheritance is and why it is useful (cognitive attainment level 1). Only with some understanding can the student respond positively to further examples, seeking out instances of inheritance (affective attainment level 1) and testing them against her understanding to see if they match up, making adjustments to her understanding if they don’t (cognitive attainment level 2). A willingness to practically try out the new concept (affective attainment level 2) is needed before the student implements exercises using inheritance (cognitive attainment level 3). Satisfaction in her efforts (affective attainment level 2) is important in gaining the confidence needed to try further problems using inheritance (cognitive attainment level 3). Through the application of good examples, the student sees the power and usefulness of inheritance and starts valuing the new concept (affective level 3). Since the student believes in inheritance, she chooses to use it often and through this practice develops the ability to analyse when inheritance is appropriate to solve a problem (cognitive attainment level 4).
In this way the affective and cognitive stages feed into each other, with attainment in one domain acting as a stimulus for attainment in the other.
Conclusion
As teachers of programming we have a unique situation. Strong emotions are inherent in the practice of programming and we can use them. In this paper we have shown, through practical examples, how educational theory on the affective domain is applicable to learning programming. The affective and cognitive domains are linked:
attainment in the affective domain can act as a stimulus, or even as a prerequisite, to attainment in the cognitive domain, and vice versa. In programming this relationship is particularly important to understand because the associated emotions tend to be so extreme. As educators, we can utilise this link in our teaching by incorporating affective objectives in our programming courses.
References
Bloom, B. S. (Ed.) 1960. Taxonomy of Educational Objectives, Handbook I: The Cognitive Domain, New York: Longman
Brooks, F.P. 1982. The Mythical Man-Month: Essays on Software Engineering, Addison- Wesley Publishing Company.
Elliott, P.C. and Peelle, H.A. 1975. “Computer Augmented Teacher Training”, SIGCUE Outlook 1, si (January 1975):19-30, ACM Press.
Krathwohl, D. R., Bloom, B. S. and Masia, B. B. 1964. Taxonomy of Educational Objectives.
Handbook II: Affective Domain, New York: Longman.
Masterson, T.F. and Meyer, R.M. 2001. “SIVIL: A True Visual Programming Language for Students”, The Journal of Computing in Small Colleges 16, 4 (May 2001).
McKinney D and Denton, L.F. 2004. “Houston, We Have a Problem: There’s a Leak in the
CS1 Affective Oxygen Tank”, in Proceedings of SIGCSE ’04, Norfolk, Virginia, USA (March 2004), 236-239.
Scheerer, M. 1954. Chapter 3: Cognitive Theory, in Handbook of Social Psychology, Volume I. Cambridge, Ass.: Addison-Wesley.
Scott, T. 2003. “Bloom’s Taxonomy applied to testing in Computer Science Classes”, The Journal of Computing in Small Colleges, 19:1 (October 2003).
0 Response to "Affective Aspects in Learning and Teaching Programming"
Post a Comment