I just need a programmer
Knowing and Doing: December 2010 Archives

              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 /etc/group values on the two operating systems. For example, the
              staff group has a value of 50 on Ubuntu and a value of 10 on Solaris. On Ubuntu, the value 10
              identifies the uucp 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
              /etc/nsswitch.conf.

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

              
                Thank goodness I'm a CS professor and don't have to know how all this works.
              

              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 are 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 mean time to competence 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 mean time to mastery. 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.
            