A pattern is supposed to capture best practice in some domain. Pedagogical patterns try to capture expert knowledge of the practice of teaching. This paper contains a number of patterns that have been used and refined over many years of teaching by the author and others. The intent is to capture the essence of the practice in a compact form that can be easily communicated to those who need the knowledge. Presenting this information in a coherent and accessible form can mean the difference between every new instructor needing to relearn what is known by senior faculty and easy transference of knowledge of teaching within the community. The knowledge embodied here was not invented by the author, but was seen to work in many situations. Many of the ideas here are very common knowledge to skilled instructors, but are captured here because they lead to pattern languages.
A pattern language is a set of patterns that work together to generate complex behavior and complex artifacts, while each pattern is itself simple. As shown here, these patterns do work together, but do not in this form make a pattern language since there are no instructions here about how they do work together. In this form, however, they form the basis of such a language for course development and these and others are being brought together into such a language. See http://csis.pace.edu/~bergin/patterns/coursepatternlanguage.html
In essence a pattern solves a problem. This problem should be one that recurs in different contexts. In teaching we have many problems such as motivating students, choosing and sequencing materials, evaluating students, and the like. These problems do recur and in slightly different form each time. Each time a problem pops up there are considerations that must be taken into account that influence our choice of solution. These forces push us toward or away from any given solution to a problem. A pattern is supposed to present a problem and a solution to the problem together with the forces that must apply to make that solution a good one to the problem.
In this paper we use a form called modified Alexandrian form. Christopher Alexander is an architect who was the inspiration for the idea of software patterns through his writings, especially A Pattern Language (Oxford, 1977). The way we present material is a modification of his style. Each pattern begins with a name. This is followed by a short description of the problem that the pattern addresses. This discussion will include a number of "forces" that the users must consider to decide if the pattern is appropriate in their current context. The first sentence is a "you" form. It describes a context in which you may or may not find yourself. If you don't find yourself in the situation described, then the pattern probably doesn't apply to you.
The section beginning with a bold face Therefore... is the introduction to the solution. This is what you need to do to apply the pattern correctly.
This may be followed by additional commentary giving additional information about the pattern and how to use it. This will often include examples of the use of the pattern and what happens if you don't use it. Occasionally examples also appear in the forces section to emphasize the need for the pattern. We might also include references to related work and even contraindications to point to known situations in which the pattern definitely does not apply.
Finally, the patterns are marked with 0-2 asterisks. These stars indicate our confidence that the pattern is universal in some sense and whether or not it captures real truth. Two stars says that the authors think that something fundamental has been captured. Zero stars indicates a complete lack of such faith and in fact an assurance that things could be done better.
|
You are teaching something new to you. The thing you need to teach has characteristics different from what you are used to, requiring different thinking modes on the part of users. Perhaps you are teaching Functional Programming for the first time and most of your teaching has been in C. Functional Programming is very different in many ways from procedural programming as done in C.
Therefore use different pedagogy, not just different examples, to teach the new topic. You need to learn this pedagogy, either by developing it yourself (in the case of state of the art topics) or steal it from those who have been teaching this topic effectively. Match the pedagogy to the thinking modes required in the paradigm you are teaching.
For example, procedural programming can probably be taught bottom up, with students building most things themselves and progressing from the level of single statements to larger structures. Object-oriented programming probably can not be effectively taught that way, requiring more of a top down approach, integrated with design.
I use the word paradigm here in a fairly strict sense. A paradigm shift occurs when the thought processes of the old paradigm do not work effectively in the new, requiring new patterns to be used. By this definition, functional and procedural programming are different paradigms. Similarly procedural and object-oriented programming are different paradigms, though this is less apparent to many procedural programmers.
A Fahrenheit to Celsius converter, for example, is an effective early example in procedural programming as it expresses a nice procedural encapsulation. However, if this is used early in an object-oriented course, students will get the wrong idea about the nature of a program. This is especially true if you wrap the converter function in a complex (class) syntax, adding nothing conceptual and nothing to the power of the abstraction. Such a class need not actually be instantiated (static function), and if it is (poor design) then it never needs more than one instantiation as it has no remembered state. A consequence of this is that you may need to throw away a lot of your materials. Others will need to be adapted and used in different ways at different points in the course than before.
Similarly anthropomorphism is probably not effective pedagogy in procedural programming (machines don't think). It is effective in object-oriented programming and agent based programming, however.
You are designing a course and determining the content and how much emphasis to put on each topic. You know that you have too much to teach and too little time in which to do it. Some topics are harder than others and some topics are newer than others in a rapidly changing field. On the other hand some older topics are interesting, though solutions are well known and implemented in standard libraries or even "in the silicon" such as floating point algorithms. If you try to teach everything your course would never finish.
Therefore focus your course content on what the students need to know to be successful. Topics that are "in the silicon" can be given less emphasis. Those things of purely historical interest can be reserved for courses on the history.
The key is to look at what students need to do to be successful. What actions do they need to take. Emphasize those topics that help them take these actions and that help them make the corresponding decisions.
This advice applies most to the early courses. There may be advanced courses in which certain historical or "siliconized" topics form a necessary foundation.
You are planning a course or a lecture and are deciding how to structure your own activities and your time. You realize that you have a lot to teach your students and want to use the time well. However, the important thing is not what you do, but what your students do. If you are brilliant and give a finely honed lecture covering all the necessary information in an elegant way you are very likely to be effective with only a small fraction of your students. In fact any single explanation, no matter how elegant, will only reach a fraction of its audience. The more finely honed it is, the worse in many cases, since a moments inattention by a student may leave her puzzled by what follows if an important linking point is missed.
Therefore focus the course or lecture time on what the students will be doing, not on what you will do. When you do too much the students are too passive. Find ways to get them actively engaged with the material. Become a resource for their questions, rather than trying to anticipate all questions. So, spend more time designing their activities than your own lectures. Make sure you know what they will be doing at each point in the course you are creating.
Remember that some of your students may already know what it is you want to teach and many others are predisposed to learn it easily. With these students, the carefully honed lecture is just boring. Other students struggle with the material and need a lot of enforcement of the concepts. These students may get lost easily in detailed matter. The right set of activities can help both kinds of students.
A skilled instructor will have many different explanations for any given topic. Some of these will be visual and others textual or use other means. Different students learn differently. The larger your class the harder it is to reach everyone--especially with carefully constructed arguments that require strict attention from the students. However, a really skilled instructor won't give all the possible explanations, hoping to cover everyone. Instead he or she will look for the clues that learning is not occurring and will offer appropriate help to those who need it.
When I was a young professor of mathematics I thought that if I just came up with exactly the right explanation the students would immediately get it. I spent hours and days constructing explanations. I quickly learned that it wasn't working, but it took years to discover why.
Note that courses in Law are often driven completely by student questions on a set of readings done prior to class. The professor isn't prepared to say any specific thing, but is carefully prepared to discuss any aspect of the case at hand as well as to point the students in directions in which the questions didn't naturally lead. I once heard of a Law professor who assigned a set of readings on the first day. Then on the second, asked if there were any questions and when there were none, made another reading assignment and left the room. This was repeated exactly as above for several days until students learned that unless they asked questions they weren't going to learn anything.
Note: This pattern focuses on instructor activities. Active Student, on the other hand, focuses on what the students do. Also see Abandon Systems All Ye Who Enter Here.
This pattern has sometimes been phrased as: He teaches best who teaches least.
Professors Grossman, Williams (NC State U), and Bergin. Teaching. Was learning going on? See Active Student. (photo by Ron Frank)
You are feeling overwhelmed by the amount of material you need to cover in a course. Educators in the early courses are continually asked to teach new material. They often ask what material should be dropped to make room for the new. Sometimes it is appropriate to do so, as some things are made obsolete by advances in technology, but not always. We need to find ways to be more efficient in our teaching. There is always new material to teach in the field of computer science. There never seems to be enough time to teach all that we want to. Students want and need interesting things to learn and do. They dislike boredom more than almost everything else.
Therefore choose your examples and exercises so that they cover more than one idea or topic at the same time. For example, when teaching novices how to program in an object-oriented way you still need to teach them if statements and loops. You can either do this in isolation with abstract examples, or you can do so in such a way that the broader goals of object orientation are also reinforced. Do this by choosing examples and exercises that illustrate while statements, for example, but in the context of doing something useful in a class. Even better, you can choose the example in such a way that it also teaches students something about the breadth of computer science as well. For example, a finite automaton has a control loop. It can be built as a class, and it shows some of the underpinning theory of CS.
Students have to see some examples and they have to work on some exercises. These can be either single faceted or multi faceted. The former seldom stretch the students imagination or skill. You can often be a Stealth Instructor to achieve this. Teach a topic in such a way that it reinforces another idea also.
Often you can add new material to a course simply by changing the examples you use in class. When used well, this gives the students very rich environments in which to learn. It can also engender a questioning attitude in the students.
A set of classes that implement logic gates teaches inheritance and if statements. It also gives breadth. (see http://csis.pace.edu/~bergin/iticse99 )
Karel++: A Gentle Introduction to the Art of Object-Oriented Programming (Bergin, Stehlik, Roberts, and Pattis. Wiley, 1997) requires that the students build a new class and new methods to do anything, reinforcing object-orientation at every step, even while teaching if statements.
A Spreadsheet program teaches breadth as well as multiple dimension arrays, simple parsing (of user input), and perhaps other things as well. I have one that uses a simple stack based machine code to save and execute cell formulas. It also has a graphical front end. That is at least five different fronts to advance on. (see http://csis.pace.edu/~bergin/iticse99 )
Note that Toy Box and Lay of the Land are intended to enable this pattern.
You want to maximize student learning. Passive students don't learn much. If students listen to explanations, without themselves becoming engaged, what is learned is unlikely to go into long term memory. The deep consequences of a theory are unlikely to be obvious to one who reads about, or hears about the theory. The unexpected difficulties inherent in using the theory or applying the ideas are not likely to be apparent until you actually do use the theory. Readings, lectures, and multi-media demonstrations, unless interactive, leave students passive.
Therefore keep the students active. They should be active in class, either with questions or with exercises. They should be active out of class. Reading is often insufficiently active. Short readings should be followed by activities that reinforce what has been learned in the reading. The same is true of information given verbally or even visually through multi-media visualizations. If the students don't actively engage the material, they won't retain it. They need to write and they need to "do."
Choose (or write) textbooks and other materials that have a lot of activities at different levels of scale and difficulty. Students can write as well as read (Write Over Read), they can answer questions in writing or orally. Make them work together (Groups Work) both in class and out of class. Make them answer their own questions (Test Tube).
The most important aspect of course planning is in knowing what the students will be doing throughout the course. Remember that your job is not to give the students information. It isn't really even showing them ways to find information. Your real job is to show them ways to build new information structures for the problems of their days. This is an inherently active process.
Law schools use moot court and Law Review and a number of other devices to keep the students active. Business schools use case studies requiring extensive write ups for the same purpose.
I have often phrased the underlying idea of this pattern as: "It doesn't matter what I do. It only matters what my students do."
A corollary to this idea is that of the Active Lecture, in which the students are active during "lecture" time. See Student Design Sprint, for example.
A special case of this is Christoph Steindl's Self Test Pattern. A self test is a pseudo exam that the students may take informally to prepare themselves for an upcoming exam. Make these available, but don't require them. Provide answers and feedback for those who ask for it.
Four Doctoral Students at Pace learning. Actively.
You have more to do than the time permits. You have lessons to teach that are related to other lessons in complex ways. In addition to technical things you need to teach professionalism and respect for quality and integrity.
Therefore think hard about which lessons you can teach implicitly without taking up time and bandwidth. Include these in your course plans as well as those things you teach explicitly. Remember that you may be doing this unconsciously. If you focus on it, you will be more likely to keep the implicit messages consistent.
Topics can be introduced implicitly by using Lay of the Land examples, for example. Just make sure that the example embodies a lesson you want. Syntax and coding style can be taught this way if you give your students plenty of well written programs to read and extend. Pattern oriented design can be introduced if you examples use plenty of patterns and document their use with references to the literature. General professionalism should be obvious from your own style, of course.
If you have a particularly complex subject to teach (the STL comes to mind) then you can give some ideas of overall structure whiile you focus on some detail if you choose well designed examples. Make sure that your examples reinforce each other and help show the bigger picture.
However, don't overdose on this. Most things you need to be explicit about. Even those things that are introduced in stealth mode may need to be made explicit later.
Also see Language Reinforces Paradigm.
Many of today's students work in addition to going to school. They do their outside of class exercises at odd times. They are otherwise very busy. It is frustrating to have a question and not be able to get it answered for several days. On the other hand, modern communication equipment can make it possible for a student to ask questions without it intruding on the lives of professors. In medieval times students and professors lived very close together and their lives were intertwined. This is probably no longer possible at most colleges and universities.
Therefore use the technology to keep in touch with your students. One very effective tool is the list server, which connects a group of people together using email. Any mail sent to the server is redistributed to all subscribers. A student asking a question of a list server can get back an answer within a few minutes to a few hours. This is especially true if you encourage the class members themselves to answer all questions posed.
You need to monitor the mail stream, of course. You need to make sure no question goes unanswered and you need to make sure that incorrect answers are corrected.
Often you can be most effective, however, by delaying an answer for a bit to see if another class member will provide an answer.
Another useful idea is to point the class to a place from which the answer can be easily obtained, rather than providing a direct answer.
You should also capture the knowledge gained in these message exchanges. Sometimes an exchange will point you to an unanticipated problem with the course. Sometimes the exchange can be the basis of a new handout or web page.
If used well, students will have the idea that they are in contact with their professor twenty-four hours a day, seven days a week.
Note that if your students are not used to using such lists you may need teach them net etiquette. Such things as when to reply, how to phrase replies, avoiding flaming, and the like are not natural to new comers.
When introducing new topics and at the beginning of the course you need to get the student's attention and make sure all are ready for the new material. Otherwise topics may run together and students may mis important connections and may get confused by too much detail.
Therefore set the stage for the new material by using the following checklist
If two topics are similar and can be confused, a somewhat dramatic setting of the stage may be desirable to make sure that the students focus on the difference. I once knew a professor who wore different hats when discussing different aspects of the same problem. Each hat was associated with a view. When he changed hats you knew that you needed to think a little differently.
You are trying to implement Active Student and are designing student activities. Reading is more passive than writing. Professionals in computer science create things. They write. They write programs and more than programs. Students, on the other hand, seldom like to write, though they may like to program.
Therefore prefer writing exercises over reading exercises. Make your students write (and rewrite) programs, specifications, documentation, proofs, explanations, ...
It is best if the students publish what they write. See Student Online Portfolios. Work published online invites comment and comment invites rewrites.
Use writing to engage students with their readings. Ask for summaries of important material. Remember that Groups Work for this as well. Published summaries of important topics can be a way that students can be encouraged to help each other learn.
And by the way, encourage your students to rewrite their programs. Good advice is to ask students to rewrite any program that they write at least once before they show it to anyone, including the instructor. See, for example, the Elementary Coding Patterns at http://csis.pace.edu/~bergin/patterns/codingpatterns.html
You are trying to introduce a complex technical topic to your students for the first time. You want an example that will lead them in the right direction and will give them the right mind set for further work. However you don't want to overload them with detail. Some topics are so complex and have so many interacting parts that it seems impossible to know where to begin and there is a temptation to try to do it "all at once."
Therefore follow Albert Einstein's advice and make your example as simple as possible, but no simpler. The example must be complex enough that it covers the essential aspects of the topic you introduce. Any simpler and it will be misleading. If this "simplest" example is still complex, you should try as much as possible to draw on student existing experience. Also, try to choose it so that it doesn't have additional extraneous complexity. Be aware of Miller's "Rule of Seven, plus or minus two," and keep the maximum number of distinct elements at about seven, preferably fewer. Apply Active Student to engage the students with your example and be sure they have explored all of the relevant key aspects.
For example, suppose you want to introduce object orientation at the beginning of the first programming course. You want to give them an example that will give them the right ideas about objects and will lead them to eventual deep understanding. Object orientation is complex in some ways so the first example may need some complexity. The key idea of objects your students need to understand is that they interact with other objects, there are usually a lot of objects, and they have control (based on their type) of how they respond to messages. Therefore, your first example should have more than one class, at least one class should be instantiated more than once, the objects must interact, and the example must show that similar objects may behave differently based on explicit type and internal state. The problem should admit, though perhaps not require, a solution that uses dynamic polymorphism. Since this implies a fair amount of complexity, draw the specific example from something within the student's immediate experience. It could be the operation of the school's registration system, a music component system, or a commonly known sport or game. Be careful, however, that your example doesn't appeal to only a subset of your students.
Note: Occam's Razor is named for William of Occam who was charged with heresy in the fourteenth century. One of his axioms was: It is vain to do with more what can be done with less. It is generally taken to mean that when faced with two explanations of some phenomenon, one simple and the other complex, the simpler one is nearly always the correct one.
See also Simple and Complete Patterns Step by Step by ErzsŽbet Angster at http://www-lifia.info.unlp.edu.ar/ppp/pp47.htm. See also Lay of the Land.
You have a lot to do in your course and want to use a Multi Pronged Attack as much as possible. Some complexity can be hidden from students by use of instructor written libraries. On the other hand, some kinds of complexity embody lessons that need to be learned and, once learned, can pay off later in student learning and course efficiency.
Therefore use high leverage techniques whenever possible. Teach those things early that embody principles that can be reused to aid student learning and to make the course more efficient. You will, of course, need to mine the material for these high leverage opportunities.
One example is the Java i/o class libraries. Many instructors hide the complexity of these libraries in their own libraries. However, the design of these libraries is a good one, based on the Decorator design pattern. If you teach Java i/o with this in mind, you will have a powerful tool in the Decorator for use in other places. If you don't do it this way you will be spending some time on your own libraries, only to have to then teach the built-in libraries later. See, for example: http://csis.pace.edu/~bergin/patterns/strategydecorator.html
Recursion is another example of a high leverage technique, of course — especially if you relate it to recursively defined data structures.
Patterns in general are a high leverage idea since there is so much in the design literature now published in pattern form. Once students become familiar with the idea they can find their own solutions to many design problems on the net; for example on the wiki-wiki web http://c2.com/cgi/wiki. Also, see the Elementary Patterns Home Page at: http://www.cs.uni.edu/~wallingf/patterns/elementary/
In teaching data structures, I found that spending time at the beginning relating the various structures to each other, showing similarities and differences paid off later as I could teach the implementation of one in detail and then only needed to mention a few things about the other. Showing a collections hierarchy was the key to this. It also taught good OO ideas at the same time. This philosophy was used in the book Data Abstraction (Bergin, Wiley, 1994).
You want to give large projects to your students. Often the size of these implies that the evaluation of the project will have a large effect on the student's grade. These are difficult to grade fairly. For one thing it will likely take you a long time to look at all of them and your grade on later ones should be consistent with the ones you grade early, though you may be fatigued at the end. If your grading scheme is too monolithic, some student or team may suffer for a particular error you were looking for in an otherwise good piece of work.
One of the most important characteristics of the successful professor is perceived fairness. Sometimes it is harder to convince yourself that you have been fair to each student than it is to convince them. In all or nothing grading schemes it is very difficult to maintain fairness as fatigue and even emotion often get in the way.
Therefore divide up the evaluation into different components, each of which will be given an individual grade. Determine the weight of each component prior to giving the assignment and publish the grading rubric. Preferably use more than seven components. This makes it less likely that your personal preferences or subconscious biases will affect anyone's grade more than a small amount. Create a checklist of the individual components and their weights with room to write down the grade for each component. Leave room on this sheet for feedback that you can later give to the student.
I teach a course in which virtually the entire grade is based on a team project. To make the grading fair, I require that the teams present their work at least twice and grade the individual presentations as well as the written work. The written work is graded more than once (midterm and final) and on different criteria for different components. Each piece is assigned a number of points up to a maximum known in advance. There is a total of 1000 points possible, divided into seven or eight categories. Each grading task is relatively small, and even if I penalize a group or student for some act or omission in one part, it will have only a small overall effect, thus guaranteeing that the overall grade depends most on the overall effort. In essence, to get a bad grade, requires consistent poor work even though the grading is all based on one project.
Another course has 70% of the course grade in one project and by the nature of the project it can be graded only at the end of the course. Therefore, individual grades are given for different parts of the project, with the breakdown known to the students in advance. A check sheet is used to compile the overall grade on each project.
You want to encourage your students to help each other learn. If your students are competitive they may not want to help other class members, however. Each student will want to try to maximize their own position in the class. Your best students are a resource, however, that may be difficult to harness. Your real task is to find ways for each student to reach maximum potential.
Therefore explicitly link a student's grade to that of one or more team mates. Make nearly all student work paired.
Make all assignments, especially programming assignments, paired. These pairs can be permanent or not. It is easier to grade individuals if the pairs change for each assignment. This also gives students more experience working with others. This can and should be a goal of the educational process.
An example scheme is as follows. At the beginning of a term pair the students into permanent teams. Therefore each person has a buddy. Define the activities for the term so that some of them are team activities (projects) and others are individual projects (exams...) On the team projects each team member gets the same grade. On the individual projects, each team member gets 90% of the grade they earned themselves, plus 10% of the grade of their buddy. It is this last feature that is the key to this pattern. Depending on circumstances, the original pairing could be random or not.
A simpler scheme is to let students take exams in pairs. An ordinary exam is given. Studens are paired. Both student names appear on a single exam paper. One effective way to do this in a class that has no special equipment for it (such as study carels) is to ask the students to develop the answers independently and then for each pair to choose (for each question) which answer will be turned in to the professor. This doesn't require verbal communication, which might be disruptive in an exam situation.
The goal of this is to get the "brighter" buddy to help the other learn and to reward the helper for his/her efforts. Ideally you want each student to feel responsible for everyone's learning. This is not necessarily a drain on the "helper" in a pair, as devising explanations for another usually solidifies knowledge. Professors often say "I didn't really understand X until I was forced to teach it."
When elementary school students go to the museum they are assigned a buddy and are responsible for their buddy. The same is true when youngsters learn to swim at camp.
This pattern is also know as Pervasive Paired Learning. Also see Groups Work and Study Groups.
Jutta Eckstein's Ask Your Neighbor is related to this, but perhaps over a shorter time frame.
You are teaching an elementary course that has a strong programming or design component. You want to help them learn to eventually create large and complex programs. Creating anything is hard work, even for the skilled. Novices, on the other hand lack these skills. However, as with natural language, students have an ability to read and understand larger artifacts than they can be expected to create. They can also learn about structure, scope, and aesthetics from reading great works. In an English course, for example, students read and analyze Shakespeare's plays, but are not expected to produce such works.
Therefore give your students large programs or designs to read and evaluate before you ask them to build even small artifacts. These readings can and should be far more difficult than anything you would expect them to create. The artifacts you give for reading must be elegant in design and execution. These will be the exemplars that you want students to learn from.
Ideally, these programs and designs will be presented in such a way that students will be encouraged to borrow from them in their own work.
You should count on spending time helping students learn from these artifacts by pointing out the key aspects and any subtleties.
Your best student work from previous years and from other courses can be a source of artifacts for your students to read. They may need to be improved by you first of course.
Mike Clancy of Berkeley has the following list of suggestions. For further information, see "The Case for Case Studies of Programming Problems", by Marcia Linn and Mike Clancy, March 1992 CACM.
The Designing Pascal Solutions books, by Mike Clancy and Marcia Linn (W.H. Freeman, 1992 and 1996).
Programming Pearls, (second edition), by Jon Bentley (Addison-Wesley, 1999).
How to Program Well: A Collection of Case Studies, by Henry D. Shapiro (Irwin, 1994)
"The Marine Biology Case Study", by Mike Clancy, Owen Astrachan, and Cary Matsuoka (College Board: www.collegeboard.org/ap/computer-science/html/case_study.html)
Each has lots of exercises. For more exercise ideas, see "Case Studies in the Classroom", by Mike Clancy and Marcia Linn, 1992 SIGCSE conference.
You are teaching a course in which it is important that the students adapt their thinking to a particular style or paradigm. On the other hand, you probably have many different styles at your command. Novices, however, may not benefit from a comprehensive view if they are struggling with the one at hand.
Therefore examine the words you yourself use in class and make sure that you use reinforcing terminology consistently. When deep concepts occur in examples or discussion is subtle ways, make sure the lesson isn't lost and refer to the use explicitly.
If you have students who know one paradigm and are learning another this requires special vigilance. You can relate the old terminology to the new, of course, but if the meaning is subtly different then students will only be confused if you use inconsistent terminology.
For example, if you are teaching object orientation, don't say procedure call when you mean message send since the focus of control is different and confusing this will make polymorphism harder to learn. Use a metaphor in your own language if it is relevant to the topic at hand. Again, in teaching objects, a metaphor that works is to treat objects like people. You can ask "Who knows the price of coffee" when referring to a design, meaning which object is responsible for knowing the price of coffee. The idea is to stress the encapsulation and active nature of objects. See also Consistent Metaphor.
Students ultimately need to know several computational paradigms. The first courses are probably not the place to teach this. Rather, focus on one solid paradigm and get the students to adopt a compatible world view. Later you can teach other paradigms by reference to the one they learned first.
You want to maximize student learning, Active Students, and encourage the students to be responsible for each other's learning. You are only one resource for the students. Given the number and difficulty of student questions and concerns you are actually a rather small resource. Your students need frequent feedback on what they do and how they do it.
Therefore emphasize group work in your courses. Use both large and small groups. Use both long lived (weeks) and short lived (minutes) groups.
Groups can come together for a few minutes in a class to consider a question posed by the professor. They can work for an hour or two together in or outside the classroom or lab. They can work in teams for days and weeks on larger projects.
See Student Design Sprint for one use in which teams are volatile and increase in size over the course of an hour or so.
However, there is an important contraindication to the use of this pattern. If many instructors use it for long lived team projects, the students may find themselves on many teams simultaneously. This can be a heavy burden, due to the required team meetings implied by the use of this pattern. The wise instructor will coordinate with other instructors to avoid such conflicts.
Ref: Louise Moses (Mount Union College), Sally Finche (University of Kent at Canterbury) and James Caristi (Valpariso University). The name of this pattern is due to them. "Teams Work" was the title of a panel they presented at SIGCSE 2000.
Your students have different study skills. Your best students may often be bored while the poorest struggle constantly. You want to foster teamwork and have each member of the team benefit from the experience.
Therefore form your students into study gropus and guide them if necessary. Make sure each study group member has tasks upon which the other members depend. This can be outlining topics and doing outside research on a topic for presentation to the group. Team members can build web pages with links to relevant resources on a topic.
In some fields and at some universities study groups are the norm and you may not have to do anything to have the students use them. Other places you will need to form them and guide them. Written instructions about how to proceed may help. So may in class activities. In Medicine, groups of students form "journal clubs" in which they each keep a journal of what they learn and share these with other members of the group.(Thanks to Ron Frank of Pace for this reference).
There is a complete Pattern Language for Study Groups developed by Joshua Kerievsky.
You are in a difficult situation. You may be teaching a new topic for which no good pedagogy is known (or known to you). You may have a particularly difficult group of students for whatever reason of background or language. Your job is to educate the students.
Therefore take a limited risk with the pedagogy. Try things that are not known to work. Limit the risk to the students however, and be prepared to back out of such experiments and try alternative methods. Get feedback on your efforts, either from the students or outside observers. You may not be the right person to evaluate the results.
If someone gives you an idea or a teaching "trick" try it out experimentally and keep track of the effectiveness. Give feedback to the originator if possible. Some of these patterns may be such ideas to you if you didn't know about the captured idea previously.
My own first use of Student Design Sprint felt very risky to me when I did it. I learned about it at OOPSLA and thought it was "cool" but also that I could never bring it off. The students loved it, however, which encouraged me to do more of the same kind of thing.
However, make sure you evaluate the results of your experiment. Take special care to document the results, especially negative aspects.
Don't forget that the risk should be yours, not your students'. See Reduce Risk.
You don't want to act as a gate blocking your students, but a way that enables them. While you must evaluate your students, the exam process often gets in the way of education. Exams are viewed negatively by students and some do poorly for psychological reasons unrelated to what they have learned. Others do relatively poorly based on language or cultural factors. You don't want your students to become primarily good exam takers as you have more to give them than that.
Also, you realize that students come to you to be educated, not examined. You realize that the purpose of a course is not to have the students prove to you that they don't need that course. You want to enable the students to take risks, but not to feel at risk for doing so.
Therefore take effective action to reduce your student's risk of course failure. Exams can count for a smaller part of their grade. If this is impossible, you can give Trial Exams. You can help them form Study Groups. You can Grade It Again Sam. You can have them write a research paper on a topic on which they did poorly on an exam. You can use Student Selected Activities.
Trial Exams comes from Fricke and Völter, Seminars, Presented at EuroPLoP 2000, http://www.voelter.de/seminars
You want to Reduce Risk of failure in your students and you want to avoid boredom. You want to encourage creativity in your students. Rigid grading schemes increase risk and usually do not increase student creativity.
Therefore use something like the following scheme for determining student grades. First determine the core requirements for the course and determine how you will evaluate these requirements. This should account for about 75-80% of the students grade. For the other portion, publish a set of possible additional activities, and assign a number of points that each is worth. They should be worth in total say 30% of a course grade. The total should be more than 100%. These activities can (should) involve research and writing, explorations of additional related topics, class presentations, and the like. Students select any number of these activities during the term for additional credit. When a student completes a project worth (say) 20 points, the instructor asks the student how many points of the 20 they have achieved. If the answer agrees with the professor's assesment, that number of points is assigned. If there is disagreement, the student is allowed to refine the work for more points, with the professor's guidance and feedback (Grade It Again Sam).
The points so earned may perhaps be used to make up for deficiencies on the core parts of the course that were required.
A variation on this, has all grading done on the above basis, with perhaps some of the activities being required.
Student projects done this way should best be published for the benefit of other class members working on other topics. Student Online Portfolios is a way to accomplish this.
A variation on this idea is Student Suggested Activities, in which students negotiate the course grading value of an activity that they choose. (Thanks to Allen Stix of Pace University for this insight.)
You are teaching a subject that has both a rich theory and is widely applied. Your course is for novices with little experience with the field. Students have a need, and a right, to know if they have chosen a compatible field. They can only do so if they have an idea of what will occur in the educational process as well as what will occur later. This affects their choices and their lives.
Therefore choose some of your examples and student exercises to illustrate the inner working of the craft (inlook). Choose others to illustrate the applications of the field (outlook). Do not neglect either. Be sure to cover the ground as well as possible in both areas.
Students can learn about Turing machines and Assembler Language in the first course if they are to program simple examples in a high level language. They can learn about simulation and modeling by designing and building computer models of beverage dispensers and simple accounting systems. A spread sheet is a rich source of projects also, requiring features of both inlook and outlook.
Good examples can also be instances of Toy Box.
You are teaching a course in which teamwork is appropriate. You need to divide the students up into teams. Unfortunately students like to clump with similar students: good students with good, men with men, Asians with Asians... Also, many of the demographic subgroups in your class don't have critical mass. For example there are too few women students in most computer science programs now.
There is some anecdotal evidence that teams that contain at least one woman work better than teams that are all male. Interestingly, the same evidence suggests that the women themselves were happier if there were at least two women on the team.
Therefore give your groups diversity, but don't put everyone in a group in which they will feel like strangers.
The evidence of males and females may not transfer to ethnic/racial diversity, however. Given that our overall goal is one of humanizing our students and our world, it may be worth the effort in any case. I once suggested jokingly to my class that I might be willing to give a small bonus to teams that showed diversity. I teach in New York City and the Pace student body really does represent the world. No bonus was actually given but I did notice that the students went out of their way that term to form such groups and they worked well.
Ref: Louise Moses, Mt. Union College. The evidence cited here and the concept comes from Louise (SIGCSE '99).
Your job is to teach what is not known. You want to use tools that help you do this. Most tools, however, are terrible for teaching. This includes almost all existing textbooks.
If you examine the tables of contents of books intended for first year instruction you find that the underlying educational philosophy is one of Objectivism. This theory holds that the student's mind is an empty slate that the instructor fills up. The systems approach to education has the professor examine the subject to be taught, divide it up into small bits, sequence the bits in some logical order, and then put all students through the same process of learning the material in that order. For example, textbooks suggest that if statements MUST come before looping statements and so they contain chapters devoted to everything about selection, before anything is seen of repetition. I suggest that these books are reference works, not learning texts. The objectivist theory ignores the fact that such a methodology is deadly boring to most students. First, it forces them to "learn" things they already know. Moreover it ignores any individual difference in learning style or preference.
Constructivist educational philosophy, on the other hand, views the student as knowledgeable and task driven. New things are learned by integrating them into what is already known and it is done primarily so that meaningful (to the person) tasks may be carried out.
Therefore choose materials and methodologies that let students progress on multiple fronts, individually, and which enable new and meaningful problems to be solved. Do not force them to follow a particular, rigidly defined, path. Instead, set them to tasks they will find meaningful and provide minimalist aids for solving those problems and avoiding common difficulties.
Unfortunately, too many textbooks intended for novices apply the systems approach. These books may make excellent references for the relatively skilled seeking details, as they have everything about if statements, for example, in one place. However, they are terrible as texts to learn from.
The Nurnberg Funnel : Designing Minimalist Instruction for Practical Computer Skill, John Carroll, MIT Press, 1990
See also Spiral and Need to Know.
A good introduction to constructivist theory can be found at Elizabeth Murphy's site at UniversitŽ Laval, QuŽbec City, QuŽbec: http://www.stemnet.nf.ca/~elmurphy/emurphy/cle.html and especially on the Characteristics page: http://www.stemnet.nf.ca/~elmurphy/emurphy/cle3.html
An anecdote from my early days. I once (1973) taught three sections of the same course in back to back time periods. If questions arose in the first section, I would modify my lecture to cover the point raised in the question in subsequent lectures. However, I had no evidence that the students in those sections needed this extra explanation. I was also not able to "finish" the lecture I had planned. I was trying to do too much and was teaching to hypothetical students, not real ones. On the other hand, perhaps my explanations were poor, resulting in the questions in the first place. This should have caused me to rethink my pedagogy, not just add more explanation on top of what I already had.
At some point in your teaching, students will make serious transgressions of the code of conduct. If the punishments are overly harsh there will be little learning and much resentment. Students lives can be ruined by actions taken in desperation.
Therefore when serious transgressions occur treat the student like a person who is still learning. Turn the problem into a learning session, not a punishment session.
Often if students break the code of conduct it is a sign that learning has not occurred. The punishment can often be an exercise that will make the student focus on the lesson that was missed. An extra paper with a public presentation is often appropriate.
I sometimes joke with my colleagues that students are genetically predisposed to foul up. But the university is supposed to be a learning environment. It is also supposed to be a relatively safe place to grow up. This doesnt' mean that we should ignore transgressions or laugh them off.
I once had a very good student who had a habit of helping other students cheat. I had a long conversation with him to the effect that his personal reputation for integrity would be more valued by others than his technical skill. We also discussed the fact that the social contract could not be maintained unless we could trust each other. He also finally realized that he wasn't helping his friends learn and that they needed to learn if they were going to be successful.
This pattern is also known as Love the Sinner.
However, there are some transgressions for which the police must be informed and for which the law must intervene. Generally these are transgressions in which someone is harmed or valuable property is destroyed.
You want to provide a forum in which students can present their work to others. You realize that the work of prior students can help you teach the current group of students. Universities need a consistent way to assess students. This is becoming a requirement of most accrediting agencies. Students need a way to present their best work -- to potential employers, to each other, and to their professors. This permits feedback to the students from a variety of sources. (Aside: Parents love the idea of their child's work being published.)
Therefore provide a means for students to publish their best work. In each course, students publish one or two examples of their best work on the web, using separate pages. They also build an index of their pages, detailing the courses. This index page can take the form of a resumŽ. Ideally, these pages should be freely available across the web.
In arts and craft disciplines, students typically build portfolios over their professional lifetimes, beginning in the earliest courses. For example, students studying fine arts will build a portfolio with examples of their best work in different media--design, water color, etc. Computer science shares some of the features of the craft disciplines, so student portfolios may be valuable here as well.
As a side benefit, this pattern also helps reduce plagarism as public work is less likely to be copied due to the increased likelihood of discovery. This is not its main benefit however.
The work to be presented can be selected either by the professor, or by the student (or a combination). One option is to have one assignment in each course that is created specifically for web presentation.
Students can be asked to comment on one another's work. Examples of work from prior years can be used by current students as examples to emulate.
It will be difficult or impossible for assignments to become stale. Professors will need to update their assignments regularly. At a minimum, each professor will need one new assignment in each course each term, as students have access to prior years published work.
There are definite advantages if the University can commit to keeping the pages active far beyond the student's graduation. The student advantage should be obvious, but the advantage to the University involves continuing contact with the student as they advance in the profession. Both the Alumni and Admissions offices may find use for the material.
Note: The recommendation is that each piece of student work be a separate page. This is to facilitate faculty links to those pages that the faculty member considers of special merit. The student is free, of course, to link back to the faculty page that "confers" the merit. If there is a worry that students will change pages after faculty links are in place, then student pages need to be placed in a special directory to which the students do not have write/update access. The pages can still be created by the students, however.
For an example of use, see http://csis.pace.edu/~bergin/Java/groups.html. The course in question is described at http://csis.pace.edu/~bergin/StudentTasks.html In this course, the project was designed for web presentation an this was required of all students.
One possible contraindication: For this to be really effective, many professors at the same university need to adopt it.
You want to teach a topic in a way that the students will never forget it. You want a very dramatic demonstration of some idea.
Students often forget details of abstract concepts and confuse similar concepts. Analogies are a good way to prevent this if the analogy is close to the concept being taught and the student can quickly make appropriate associations when the details are required.
Dramatic, visible, and unexpected demonstrations are remembered. If they are also good analogies, then the students will carry important and unforgettable lessons.
Therefore use a physical device, such as a toy, that has some of the characteristics of the concept being taught. Give a very vivid classroom demonstration of its use.
The instructor must be willing to give some thought both to how the analogy holds and how it breaks down. Students can possibly gain incorrect insight by taking the analogy beyond its intent.
Astrachan uses a toy called Icky Poo ™ to illustrate many of the important concepts of C++ pointers. The toy is a sticky plastic that will stretch 20 times its length. It comes in the form of a snake. When you hold one end and "whap" the other against a surface it sticks. If the surface is a lightweight piece of paper, the object can be retrieved. Pieces of paper form the heap (free store). Calling new (whapping the Icky Poo against a piece of paper) retrieves it. Calling dispose detaches all Icky Poo snakes from it. Slinky™ springs can be used similarly, but require a person to play heap, holding one end of one or more Slinkys.
Michael Clancy originated a very vivid parameter passing exercise that demonstrates the concept of a parameter and the difference between value and reference parameters. Astrachan has adapted this as well. Frisbees™ are passed between caller and called function. The Frisbee represents a variable and has a name and a value written on it with a grease pen (Post-It™ notes can be used as well). In a reference variable, any change in the variable is written directly on the Frisbee. In a value parameter, the original value is written on the Frisbee, but the Frisbee is bagged in a transparent bag before being passed. Any change by the called function is written on the bag. Therefore the original value is not affected.
Tinker toys can be used to build trees and graphs of various kinds.
Astrachan uses various children's books (Cat in the Hat, Seuss) to illustrate some computer science concepts.
Some artifacts are created specifically with this pattern in mind.
There was a simple cardboard computer (Cardiac) that illustrated assembly language. http://www.larkfarm.com/cardiac_answers.htm
Ref: "The Official Icky Poo Book", by The Editors of Klutz Press, ISBN 0-932592-90-2. It is available for less than $10 US with the toy from http://amazon.com
See also the report on Non-Programming Resources for an Introduction to CS, a report of a working group at ITiCSE 2000 in Helsinki, Finland. http://csis.pace.edu/~bergin/iticse2000/
Owen Astrachan, Duke University ola@cs.duke.edu
You answer the same questions term after term. You also realize that when one student asks a question, several probably have the same or a similar question. You would like to be more efficient, both in your own use of time and in the student's learning.
Therefore, capture everything you do electronically and turn it into web-available documents. Carry a notebook (electronic or otherwise) to keep reminders.
For example, the result of an office or web chat can be added to a course FAQ (Frequently Asked Questions) list that is posted. Quite detailed answers can be given this way. When the same question arises in the future you can point students to the FAQ. By the way, a good writing style for such a FAQ is like that of a newspaper, with the key ideas presented in the first paragraph and supporting detail given later. This makes the readers efficient if they can get the idea from the first few sentences.
If you capture enough electronically, you may have the basis for a book, paper, or even a new course. Your resources can become valuable to others if you share them widely. At a minimum, these documents can help with Iterative Course Development (Anthony).
Captured exams can form the basis of Trial Exams (Fricke and Völter).
Captured lecture notes can become the basis of web pages of resources for your students and others.
You can also sometimes capture student work for use in your course. If students publish online you can point other students to the good work of others for example. You might want to mirror such work yourself to avoid losing it, however. This requires permission, of course. An example of this can be seen at: http://csis.pace.edu/~bergin/Java/StudentTasks.html where the previous year's student work is maintained as a set of links available to current students. You can emphasize what is best by giving it a GOLD STAR.
However, if you have a lot of documents, you must maintain them.
TBA -- students need and deserve constant feedback. Use a scheme in which positive feedback is always given first and last, sandwiching suggestions for improvement.
You teach rich courses with a lot of ideas. Some of the ideas are key to the course and others support the key ideas and themselves have less importance. The difficulty of the idea isn't always directly related to its importance. Your exams attempt to cover most of the material. You also realize that different students will have different levels of understanding of the various topics.
If your grading scheme weights material according to its difficulty or gives equal weight to all topics not regarding the importance of the topic, you may be giving the wrong ideas to your students about that importance. You will also be disadvantaging some students who, while not brilliant, understand the key ideas.
Therefore, the key ideas should be worth the most points in your grading, not necessarily the hardest material.
This applies to all work, actually, not just exams. Of course you want to challenge your best students. You can do this by asking difficult questions, but valuing them less than questions covering the key ideas.
A consequence of this is that you will be perceived as fair by most of your students. You may need to explain your scheme and the reasoning behind it to your best students, however. It is good to do so before hand, so that people know that much effort might be expended for few points. You can always also give a GOLD STAR for work that is exceptional even though it contributes little to the final grading.
Your students are individuals. You want to be fair in your grading to each individual. You also want students to be satisfied of your fairness and of their own accomplishments.
Therefore, publish your minimum grading standard and stick to it. Think of it as the minimum, however. Each student can do a bit better than the minimum without compromising fairness. Be generous, not miserly with your marks.
Think of your grading standard as a contract. If the students do such and so they will earn at least whatever. Grade so that it comes out a bit better. This has two benefits. You won't feel like you need to listen so much to complaints, since you have built in a cushion already. The students will also feel good about themselves and about you since they did a bit better than they, perhaps, expected.
You can be tough, but you must be fair. Moreover you must be perceived as fair.
It is worth looking at a grade distribution now and then and comparing it with other evidence you have about student learning. If your grades are lower than what you think justified by the real performance of your students, then you probably need to adjust: both generally and for the individuals involved.
This does not mean rewarding poor work. But this combined with other patterns here, such as Grade It Again Sam, can let you implement both high standards and high levels of student learning.
Remember that you NEVER need to withhold a reward from John to be fair to Mary. (Matthew: 20 in the Christian Bible)
You teach a course in which students work in teams. The grade of the individual depends on the work of the team. Different people contribute differently to the work of the team. You want to guard against the non contributing student benefiting in the grading from the work of others. You also want to help encourage students to be contributors, not just penalize those that are not.
Therefore, make grade part of the work based on the team product, but part of it on individual contributions.
The written artifact of the team may need to be graded as a whole with equal points given to each student, but you can also divide the project explicitly so that each student is responsible for a particular part. Even if this is not the case, you can have individual presentations of the work and grade these individually.
When the report is presented, you can ask for a summary sheet, signed by all members, that details the contributions of each. This can take the form of "All members worked equally on all parts." Or "John did ..., Mary did..." or whatever seems appropriate to the students. Make sure that they know this requirement at the beginning of the project or its effect on changing behavior is lost.
You can ask questions about the team's artifact on an exam. Those that have done the most work will likely be the most familiar.
However: keep in mind that differences in kind of contribution may be interpreted by students as differences in quality. This may be entirely unjustified. For example, in a programming project, a person who does little programming, but keeps the other members coordinated by integrating the work and giving feedback, may be the most important team member.
PEER FEEDBACK can be used to let the students themselves decide who has contributed most and have it reflected in the grade.
FAIR PROJECT GRADING has suggestions also, if the main artifact is a project.
If team members really disagree about a grade distribution, you can ask them to suggest one that they and you can all agree on. Ideally, let it be written down and signed by each member of the team.
I remember one student in particular (though there have been others) with modest technical skill who would, I predicted, soon be the employer of the hotshot programmers in the class because she repeatedly asked the right question: Why are we doing this?
TBA -- Whatever media you use (from blackboard to electronics) learn to use it well and consistently.
e.g. work methodically at the board, not all over its surface. Erase by sections, not just enough for a new thought.
e.g. make sure you have backup for electronic media: overhead foils in case the computer link is down.
TBA -- every artifact you show your students must be of the highest quality. They want to emulate what you show them.
TBA -- Key idea: Make a ritual of greeting your students each class. Leave your own problems behind, help them to leave theirs behind also. (From Lisa Bergin)
TBA -- Key idea: let your students learn something about your life outside the classroom to enhance your role as mentor.
TBA -- Students need and deserve to be challenged constantly.
TBA -- make your course plan and your lecture plan visible to your students. Show them the path before you walk it.
You want to treat your students like the people they are. You want each student to believe that your mission is to teach her.
Therefore, learn their names. Even if you have large classes. (From Lisa Bergin, who does teach large classes.)
You want your students to ask questions and yet you want to be able to conduct a relatively orderly lecture. Students will have questions from the previous lecture or their exercise work since the last lecture. If many students have the same questions you may need to spend more time on a given topic, but you need to know this to respond to it.
Therefore, distribute 3 by 5 cards at the beginning of a lecture and ask each student to write the question they most want answered today.
When you get the questions spend two minutes organizing them. Revise your lecture plans accordingly. If certain questions or themes dominate you can take special care and also revise your course and methodology for the future (Iterative Course Development [Anthony]).
If you are a 24 by 7 instructor you can use electronic means to get these questions instead. You will also then have a number of channels over which to answer the questions, not just the lecture.
You teach a course in which the students interact, either in teams or generally. Students in the course produce artifacts of various kinds and some of them are complex. Some of the artifacts depend on others. Poor quality in one part affects overall quality.
You want to teach your students how to evaluate quality and how to negotiate for it. You want to get them to accept evaluation by peers and to make this natural.
Therefore, make it possible for students to provide part of the grade for other students.
The portion of the overall grade provided by peers should be small and objectively assigned.
One possibility is to design it in such a way that students are rewarded for good work, rather than just punished for bad. In other words, the points can be bonus points, perhaps. Another is to design the system so that all must volunteer in some way to earn the points. Their actions result in earning points, not an abstract evaluation by others on unknown criteria.
This is especially useful in team projects where team members can evaluate each other. It can also be used in situations in which teams or individuals can provide services (artifacts) to other teams.
One way to do this is to give each student ŇpointsÓ that they can give to other students for services rendered on contract -- producing a subroutine, for example, or a service class in an object-oriented program. The contract can specify the number of points to be awarded, as well as due dates and quality constraints. You can provide special forms to facilitate this.
Students are reluctant to do this, of course. One way to help make it more acceptable is "musical chairs" (a game with one less chair than people). In a team of five, give each student two special forms that they fill in with their own name, the name of a student on the team and a short explanation of the special contribution of the other student. These are given to the student awarded the bonus and turned in with the work. Each award can affect the grade positively by a fixed amount.
Another example of use is to give each team "point dollars" that they spend in an open market place. For example, in a software engineering course, a team must contract with other students to build its design. It pays with point dollars. Contracts with possible penalties are negotiated by the students. Students volunteer to build for other teams and thus earn points for their own grade. You may need to set up a contract resolution service if you use this, however. (K. Todd Stevens, "Experiences Teaching Software Engineering for the First Time," ITiCSE 2001 Proceedings. Canterbury, England, June 2001, pg 77.).
You teach a difficult course. It has a lot of ideas and a lot of work for the
students. The time is short and there is pressure on the students.
If your students fall behind or miss early material it will be difficult for
them to catch up and therefore difficult to succeed.
Therefore, give them Early Warning when you see that they are headed
for trouble.
This can take many forms. If your course has special pitfalls for the student, you can publish these on your course FAQ. For example, if you Grade It Again, Sam, you can point out the trap of spending too much time on re-work of old papers rather than advancing on new.
Advice is best if it points a path to success, not just pointing out the roadblock. The earlier you give the advice, the better chance for success in the student.
It helps if you give frequent short exams and quickly return the marked papers. Some universities require exams in every course every Friday, for example.
You can speak to a student privately if you think she has potential above her performance.
I vividly remembers a respected Professor's quiet word in the elevator here, even after 35 years.
Your students are individuals. They learn differently and at different rates.
They understand you with differing degrees of precision. They have different
backgrounds that make it easier or harder for them to grasp certain topics.In
spite of all the difference, you want to teach all your students well
Therefore, give Differentiated Feedback whenever possible. The feedback
to a student is tailored to the needs of that student.
The best example of this is oral examinations, though these are labor intensive.
One of the worst examples is the correct answers posted after an exam. They
may show the correct answers, but may not show the path a student should take
to arrive at the best answer.
The best feedback helps the student move forward from where they are. It helps
them get over their own misunderstandings or gaps of knowledge. A poor performing
student might have been handicapped by Dr. Bad Professor in the past.
You need to analyze why they have answered as they have, but you can give them
pointers to places in which to learn rather than specific answers, of course.
Therefore this does not need to be overly burdensome.
Common feedback and answers to frequent questions can be put on a published
Course FAQ. If you frequently get the same question you can easily add to your
growing FAQ. This saves you time in which to give Differentiated Feedback.
I teach a course with a large project (a compiler) graded only at the end. During the term each team submits an interim report every other week. On this report changes from the previous report are hilited. At the next meeting these are returned with comments, but no grades. Most of the comments are just check marks, meaning OK. There is some shorthand used, but mostly the feedback is individual and directed at the individual student.
You are giving feedback to your student. You have a variety of things to say. You want your students to learn from the feedback you give them and treat it as part of learning.
If you are negative with your students they may tune you out and not listen. If they are especially sensitive they may be hurt. If they are especially arrogant they may take your comments as an attack and attack back. You want them to feel good about themselves and also to feel that they can do better.
Therefore, when you give feedback, start and end with positive feedback.
Suggestions for improvement are sandwiched between these reinforcing comments.
Even if you have largely negative things to say, you can still start with the
things that were well done and should be retained in the future.
Even in the less positive aspects of your feedback you can take a tone that
you are giving suggestions for improvement, not just condemning. You can say
“This might be made better if you think about …,” rather than
“This is bad.” You can also say you don’t understand something,
or something in a presentation doesn’t “work” for you.
Some of the other patterns in this language have your students giving feedback to each other. Make sure they know about this technique and practice it. This can make the giving of feedback easier for both the giver and the receiver.
The patterns community IS a community largely because we use this technique uniformly in analyzing each other’s work and giving feedback on it. It is a very powerful community builder.
Linda Rising, Lisa Bergin, Neil Harrison, Jutta Eckstein have all contributed ideas and improvements. Lisa, by the way, is my daughter and a new assistant professor of Philosophy. Welcome to the profession, Lisa.
Anthony, Patterns for Classroom Education, Pattern Languages of Programming 2, Vlissides, Coplien, Kerth (editors), Addison Wesley, 1996, pp 391ff. On the web at: http://ianchaiwriting.50megs.com/classroom-ed.html
Eckstein, Learning to Teach and Learning to Learn, Presented at EuroPLoP 2000, (jeckstein@acm.org)
Fricke and Völter, Seminars, Presented at EuroPLoP 2000, http://www.voelter.de/seminars
Steindl, Pedagogical Pattern Self Test, Presented at EuroPLoP 2000, (steindl@acm.org)
Joshua Kerievsky, Pools of Insight: A Pattern Language for Study Groups, http://industriallogic.com/papers/kh.html
Last Updated: May 11, 2002