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.
-----