TITLE: Mean Time to Competence and Mean Time to Mastery
AUTHOR: Eugene Wallingford
DATE: December 10, 2010  3:43 PM
DESC: 
-----
BODY:
I'm on a mailing list with a bunch of sports fans, many
of whom are also CS academics and techies.  Yesterday,
one of the sysadmins posted a detailed question about a
problem he was having migrating a Sun Solaris server to
Ubuntu, due to a conflict between default  <TT>/etc/group</TT>
values on the two operating systems.  For example, the
<TT><EM>staff</EM></TT> group has a value of 50 on
Ubuntu and a value of 10 on Solaris.  On Ubuntu, the
value 10 identifies the <TT><EM>uucp</EM></TT> group.

Another of the sysadmins on the list wrote an even more
detailed answer, explaining how group numbers are
supposed to work in Unix, describing an ideal solution,
and outlining a couple of practical approaches involving
files such as <TT>/etc/nsswitch.conf</TT>.

After I read the question and the answer, I sent my
response to the group:

<BLOCKQUOTE><EM>
Thank goodness I'm a CS professor and don't have to know
how all this works.
</EM></BLOCKQUOTE>

I was joking, of course.  Some people love to talk about
how CS profs are disconnected from computing in the real
world, and this is the sort of real-world minutia that
CS profs might not know, or even have to know if they
teach courses on algorithms, intro programming, or
software engineering.  After seeing my friends' exchange
and seeing all that Unix guru-speak, I was happy to play
to the stereotype.

Of course, the numbers used to implement Unix group
numbers really <EM>are</EM> minutia and something only
practicing sysadmins would need to know.  The professor
who teaches our systems courses is deeply versed in these
details, as are the prof or two who manage servers for
their courses and research.  There certainly are CS
academics divorced from reality, but you can say that of
any group of people.  Most know what they need to know,
and a bit more.

Later in the day, I became curious about the problem my
friends had discussed, so I dug in, studied a bit, and
came to understand the problem and candidate solutions.
Fun stuff.

Our department has recently been discussing our curriculum
and in particular the goals of our B.A. and B.S. programs:
What are the desired outcomes of each program?  That is
jargon for the simpler, "When students graduate, what
would we like for them to be able to do?"  For departments
like ours, that means skills such as being able to write
programs of a certain size, design a database, and choose
appropriate data structures for solving a specific problem.

I was thinking about the Unix exchange on my mailing list
in this context.  Let's be honest...  There is a lot of
computer science, especially CS as it is applied in
specific technology, that I don't know.  Should I have
known to fix my friend's problem?  Should our students?
What can we reasonably expect of our students or of
ourselves as faculty?

Obviously, we professors can't know everything, and neither
can our students.  That is true in any discipline and
especially in one like CS, which changes and grows so fast.
This is one of the reasons it is so important for us to
define clearly what we expect our programs to achieve.  The
space of computing knowledge and skills is large and growing.
Without a pretty good idea of what we are hoping to achieve
with our courses and curricula, our students could wander
around in the space aimlessly and not having anything
coherent to show for the time or effort.  Or the money they
spent paying tuition.

So, when I first read my friends' messages about Unix groups,
I didn't know how to solve the problem.  And that's okay,
because I can't know everything about CS, let alone every
arcane detail of every Unix distro out in the world.  But I
do have a CS degree and lots of experience.  What difference
should that make when I approach problems like this?  If one
of our graduates confronts this situation or one like it, how
will they be difference from the average person on the street,
or even the average college graduate?

Whatever specific skills our graduates have, I think that
they should be able to come up to speed on computing problems
relatively quickly.  They should have enough experience with
a broad set of CS domains and enough theoretical background
to be able to make sense of unfamiliar problems and understand
candidate solutions.  They should be able to propose solutions
that make sense to a computer scientist, even if the solutions
lack a detailed knowledge of the domain.

That is, CS graduates should have a relatively low <B>mean
time to competence</B> in most sub-areas of computing, even
the ones they have not studied in detail yet.

For a smaller set of sub-areas, our students should also have
a relatively low <B>mean time to mastery</B>.  These are the
areas they have studied in some detail, either in class or
through project work, but which they have not yet mastered.
A CS degree should put them in a position to master them
more quickly than most educated non-computer scientists.

Mean time to competence (MTTC) and mean time to mastery (MTTM)
are actually a big part of how I distinguish a university
education from a community college education when I speak to
prospective students and their parents, though I have never
used those terms before.  They always wonder about the value
of technical certifications, which community college programs
often stress, and why my department does not make study for
certification exams an explicit goal for students.

We hope, I tell them, to put the student in a position of
being ready to prepare for any certification exam in
relatively short order, rather than spending a couple of
years preparing them to take a specific exam.  We also hope
that the knowledge and experience they gain will prepare them
for the inevitable developments in our discipline that will
eventually make any particular certification obsolete.

I am not certain if mean time to competence and mastery are
student learning outcomes in the traditional educational
jargon sense of the word, or whether they are abstractions
of several more concrete outcomes.  In any case, I am left
thinking about how we can help to create these outcomes in
students and how we can know whether we are successful or
not.  (The agile developer in me says, if we can't figure
out how to test our program, we need to break the feature
down into smaller, more concrete steps.)

Whatever the practical challenges of curriculum design and
outcomes, I think MTTC and MTTM are essential results for a
CS program to generate.  Indeed, they are the hallmark of
a university education in any discipline and of education
in general.

Now, to figure out how to do that.
-----