TITLE: More Mathematics, More Coincidence AUTHOR: Eugene Wallingford DATE: October 06, 2005 6:48 PM DESC: Students should master skills and content before they move on to the next level. How well do our university computing courses ensure this? How can they? ----- BODY: When I started writing my recent piece on math requirements for CS degrees, I had intended to go in a different direction than the piece ultimately went. My original plan was to discuss how it is that students who do take courses like algebra in high school still seem so uncomfortable or ill-prepared to do basic arithmetic in their CS courses. But a related thread on the SIGCSE mailing list took my mind, and so the piece, elsewhere. You know what they say... You never know what you will write until you write. So I figured I would try to write an article on my original topic next. Again before I could write it, another math coincidence occurred, only this time nearer to my intended topic. I read Tall, Dark, and Mysterious's detailed exploration of the same problem. She starts by citing a survey that found 40% of university professors believe that *most* of their students lack "the basic skills for university-level work", explores several possible causes of the problem, and then discusses in some detail what she believes the problem to be: an emphasis in education these days on content over skill. I think that this accounts for at least part of the problem. Whether we overemphasize content at the expense of skill, though, I think that there is another problem at play. Even when we emphasize skill, we don't always require that students master the skills that they learn. For many years, I had a short article hanging on my office wall that asked the question: What is the difference between a grade of C and a grade of A in a course? Does it mean that a C student has learned less content than the A student? The same content, but not as deeply? Something else? Several popular jokes play off this open question. Do you want your medical doctor to have been a C student? Your lawyer? The general leading your army into battle? In my experience as a student and educator, the difference between a C and an A indicates different things depending on the teacher involved and, to a lesser extent, the school involved. But it's not clear to me that even for these teachers and schools the distinction is an intentional one, or that the assigned grades always reflect what is intended. Learning theory gives us some idea of how we might assign grades that reflect meaningful distinctions between different levels of student performance. For example, Bloom's taxonomy of educational objectives includes six levels of of learning: knowledge, comprehension, application, analysis, synthesis, and evaluation. These levels give us a way to talk about increasingly more masterful understanding and ability. Folks in education have written a lot in this sphere of discussion which, sadly, I don't know as well as I probably should. Fortunately, some CS educators have begun to write articles applying the idea to computer science curricula. We are certainly better off if we are thinking explicitly about what satisfactory and unsatisfactory performance means in our courses, and in our curricula overall. I heard about an interesting approach to this issue this morning at a meeting of my college's department heads. We were discussing the shortcomings of a course-by-course approach to assessing the learning outcomes of our university's liberal arts core, which purports by cumulative effect to create well-rounded, well-educated thinkers. One head described an assessment method she had read about in which the burden was shifted to the student. In this method, each student was asked to offer evidence that they had achieved the goal of being a well-rounded thinker. In effect, the student was required to "prove" that there were, in fact, educated. If we think in terms of the Bloom taxonomy discussed above, each student would have to offer evidence of that they had reached each of the six cognitive levels of maturity. Demonstrating knowledge might be straightforward, but what of comprehension, application, analysis, synthesis, and evaluation? Students could assemble a portfolio of projects, the development of which required them to comprehend, apply, analyze, synthesize, and evaluate. This reminded me very much of how my architecture friends had to demonstrate their readiness to proceed to the next level of the program, and ultimately to graduate: through a series of juried competitions. These projects and their juried evaluation fell outside the confines of any particular course. I think that this would be a marvelous way for computer science students, at least the ones focused on software development as a career path, to demonstrate their proficiency. I have been able to implement the idea only in individual courses, senior-level project courses required of all our majors. The result has been some spectacular projects in the intelligent systems area, including one I've written about before. I've also seen evidence that some of our seniors manage to graduate without having achieved a level of proficiency I consider appropriate. As one of their instructors, I'm at least partly responsible for that. This explains why I am so excited about one of the sessions to be offered as a part of the upcoming Educators Symposium at OOPSLA 2005. The session is called Apprenticeship Agility in Academia. Dave West and Pam Rostal, formerly of New Mexico Highlands University, will demonstrate "a typical development iteration as practiced by the apprentices of the NMHU Software Development Apprenticeship Program". This apprenticeship program was an attempt to build a whole software development curriculum on the idea that students advance through successive levels of knowledge and skill mastery. Students were able to join projects based on competencies already achieved and the desire to achieve further competencies offered by the projects. Dave and his folks enumerated all of the competencies that students must achieve prior to graduation, and students were then advanced in the program as they achieved them at successive levels of mastery. It solves the whole "C grade versus A grade" problem by ignoring it, focusing instead on what they really wanted students to achieve. Unfortunately, I have to use the past tense when describing this program, because NMHU canceled the program -- apparently for reasons extraneous to the quality or performance of the program. But I am excited that someone had the gumption and an opportunity to try this approach in practice. I'd love to see more schools and more CS educators try to integrate such ideas into their programs and courses. (That's one of the advantages of chairing an event like the OOPSLA Educators Symposium... I have some ability to shape or direct the discussion that educators have at the conference.) For you students out there: To what extent do you strive for mastery of the skills you learn in your courses? When do you settle for less, and why? What can you do differently to help yourselves become effective thinkers and practitioners? For you faculty out there: To what extent do you focus your teaching and grading efforts on student mastery of skills? What techniques work best, and why? When doyou settle for less, and why? I myself know that I settle for less all too often, sometimes due to the impediments placed in my way by our curriculum and university structure, but sometimes due to my own lack of understanding or even laziness. Staying in an intellectual arena in which I can learn from others such as West and Rostal is one way I encourage myself to think Big Thoughts and try to do better. -----