Code Monkey and the Magnificent Seven

This is something I wrote back in 2007, slightly adapted; the original is available on the IP list archives.

I really was going to keep my mouth shut on this topic, but I just can't help myself; the topic is stuck in my brain and I have to get it out through my fingers.

This discussion has ranged from how CS is taught to the grand structure of society, touching on whether or not a college education is worthwhile, the place of the programmer in society and the company, choice of career, and the issues of globalization. Let me offer first a link that I think is an actual contribution to the discussion; the rest I'll let you judge for yourself :-). First the CS education, then the larger issue, including a few embryonic thoughts about apprenticeship.

On how to teach CS, let me point out that this issue has received attention at the highest levels. The ACM issues guidelines on curricula for:

• computer science
• computer engineering
• information systems
• software engineering
• associate degree programs
• K-12

and most have been revised since 2000. The CS undergrad curriculum recommends, for example, a core of only 18 lecture hours on operating systems, out of a total of 280 or so core hours. In a U.S. research university, that would roughly represent the sophomore-junior content of a CS degree, and would probably roughly be doubled in the senior year to a total of perhaps 560 hours of lecture and maybe three times that in homework, a couple of thousand hours on CS alone, ignoring math, other sciences and engineering, humanities and social sciences. In other types of advanced learning institution, the amount could be substantially less or quite a bit more.

Craig Partridge mentioned a workload for students that amounted to about 600 lines of code a week for the term. I would hope that master's students in CS would be able to work at that rate, but that's clearly too much to expect of first-year programming students. The ACM curriculum above includes a several-page discussion of the importance of teaching programming v. principles, which I won't go into here, but I highly recommend reading it.
(If you're keeping score on the anecdotal topics mentioned so far in this conversation, version control probably makes the core curriculum, automata and shared libraries are in the supplementary curriculum. A couple of lectures on privacy, intellectual property and other aspects of computers in society seems like a positive thing.)
I'm not involved in the curriculum effort, but I suspect they are under more or less constant revision. In recent years, some universities have been adding programs in game design, bioinformatics, business/technology dual majors. One can certainly argue that the overall CS curriculum is in flux and varies across the country (and around the world), but beyond that it's difficult to generalize.
The above I'm fairly confident is a positive contribution to the discussion. From here down, I'll let you form your own opinion. Much of what I would write Karl Auerbach has already written, and far more succinctly and eloquently than I seem to be capable of. But let me offer a twist or two, and go a step farther.
Zach and other writers made several major points:

1. The undergrad CS curriculum at many colleges/universities is inadequate.
2. The undergrad CS curriculum at many colleges/universities is poorly taught.
3. Students arrive with differing backgrounds and ability levels, and consequently come away with different learning experiences and knowledge.

There are several corollary points:

• A. It's possible to pick up "on the street" what you need to know to do most jobs in a Silicon Valley startup.
• B. Promotion at major research universities forces a focus on research rather than teaching.
• C. CS as a major is not very attractive right now, for a variety of reasons, culminating in "programmers are treated like dirt in companies, and with all the jobs being exported to India, it's a bad career choice anyway".

I think all of these points except #3 are debatable. Certainly the discussion so far has not made a distinction between #1 & #2. I'm not really going to discuss most of these points directly, but they form the undercurrent in what follows.

For millenia, kids were apprenticed to a profession at an early age. We still have this, after a form. LeBron James, Michelle Wie, the Magnificent Seven (remember them?), and all pro go players and musicians took up their vocations essentially full time well before what we consider "working age". Many of us starting hacking at a similar age, but maybe we need formal extracurricular mentoring and a similar support system? A way for kids to "go pro" earlier and still get the coaching they need? Virtuosos almost all spend 20-40 hours a week at it from the age of fourteen or earlier, why should programming be any different?

I've heard people say, "Oh, who needs college?" But I'm a fan of the modern apprenticeship -- the Western liberal arts college degree. It's your chance to read Wilde, Plath, Joyce, Thoreau, the Federalist Papers; learn a foreign language (okay, I flunked German), play on the basketball team, take up scuba diving; study how the encroachment of the modern world is impacting the Mbuti pygmies and the Navajo; maybe do a year abroad (I wish I had). Personally -- call me a science chauvinist -- I think anyone who claims to have a well-rounded education should be able to talk intelligently about relativity (special, at least) and quantum theory, arguably the two most important (and misunderstood) discoveries of the twentieth century (fans of the nature of the chemical bond, the structure of DNA, the Big Bang and plate tectonics all have a case, though). (On a tangent, let me recommend Alan Lightman's The Discoveries and Richard Muller's course titled "Physics for Future Presidents".)

For most people, college will be the broadest point of your life. For many -- including a particular skinny sixteen-year-old from southern West Virginia -- it's your first extended contact with people from other parts of the country and the world, and with the breadth and wealth of the world of ideas. Take time to hang out with the music majors (okay, Caltech doesn't have any of those, but it does have English majors). Consider a career in astronomy or geology instead of hacking. Trust me, once you're in a company and writing code, the world gets a whole lot narrower, even if you're working shoulder to shoulder with people from China, India and Finland.

If you're of pragmatic bent and recoil in horror at the thought of whiling away your days trying to decipher Joyce and Eliot rather than starting that get-rich-quick Internet business, well, I have trouble imagining that anyone can be effective at building large-scale computer systems without some background in probability. Probability requires at least basic calculus, and if we can get you as far as queueing theory, it will change the way you think about systems problems. If you are interested in image or audio processing, you need linear algebra and Fourier transforms, and the basics of amplifiers and RC circuits won't hurt; if you're in communications, antenna design and wave guides help; if you write firmware, you gotta understand what the funny lines on a signal analyzer mean. And I have yet to meet the engineer (myself included) whose writing and presentation skills need no polishing. Note that none of that is included in the 560 lecture hours mentioned above, but I wouldn't trade any of it for another hour hacking code.
Is it possible to learn all of this without going to college? Of course! Two of the brightest people I know are extremely well-rounded, and neither finished college. Did it hurt their careers? Probably in a minor way. Are they successful anyway? Very. (And no, neither is named Gates or Jobs). If you're smart, disciplined, get a good break and a good mentor, you can do it. But for most people, the direction and semi-structure (compared to high school) of a university will bring them needed breadth, depth, and maturity -- and a higher probability of success in life. (No guarantees, though!)

It's also true that the university environment as currently constructed is not perfect for everyone. But for many people, bailing out with the excuse, "I wasn't learning anything anyway," is a true statement that says as much about them as it does about the system.

And lest you think I'm in favor of stuffing people's heads with facts but not teaching them to solve problems, let me reassure you: I tell my students that the only thing they *must* learn in college is how to think, everything else is optional. While I do believe there is a core curriculum I wish they would learn, four years is a short time and a focus on any given technology is extraordinarily short-sighted when planning for a forty- to sixty-year career.

By now I've no doubt convinced you that I'm an unrepentant ivory-tower academic. However, I've spent about half my career to date in industry. Was I well-prepared when I came out of school? Let's say I was still a work in progress, and I owe more to a mentor and friend named Wook than any professor. Certainly I have regrets, the largest of which is not taking Jim Blinn's graphics class, but most of them are due to my own shortcomings. But because I was taught how to learn and how to work hard, I have followed up with enormous amounts of learning, and at every step of the learning process I felt that my time at Caltech helped.

From here, I was going to springboard into the place of the programmer in society and globalization, but this is way too long already. Let me thank you for reading this far, and finish with four thoughts:

• The Western liberal arts CS degree, properly taught and learned, has long-lasting value. The key question is, is it worth a thousand bucks a week for four years? 
• Engineers are paid to solve problems, not to write code. Demonstrate an ability to learn about the problem domain in which you are working, and your prospects improve; breadth and depth help. 
• What is it that makes Code Monkey such a pathetic figure? The fact that he's not in control of his own destiny. If you want that control (and, IMO, if you want a date), being articulate and well-rounded is the path to leadership.
• Finally, keying on that last word, the job of a university is to provide productive members of society. You should graduate knowing not just a handful of technical facts, but how you can find the best role for yourself, where "best" makes you happy, earns you a buck or two, and allows you to contribute to the greater good.

Do we accomplish all of this in four years? Nah. Do we start students on the right path? Some of them. Should we figure out how to do our best for more of them? You betcha. Are professors perfect, giants striding the Earth before whom all should bow? No way. They're taught to swagger, but if they haven't humbled deep down by their own learning experience, they haven't been paying attention.

One thing's for sure, though: the development of the next generation of leaders, both in technology and society, is far too important to be left to what disaffected teenagers pick up surfing the blogs of disaffected, semi-literate, technical and political ideologues.

(Heavily Used) Distributed Systems that Influenced Me

 I had my first job, as a VMS sysadmin, and did my master's degree at USC, during the heyday of distributed operating systems research and implementation. Here are a few of the ones that influenced me:

• VAXclusters: My pal Wook, a former DEC employee himself, was rather disparaging of VAXclusters and the VMS operating system in general, but the distributed file system, distributed block-level access to network-attached disk drives mediated by a distributed lock manager, the ability to share a single set of accounts across the cluster, and especially the distributed processing queue for batch jobs became my expectations for what a system should be. Why did a good distributed batch system never become a standard feature of a UNIX house? (You should should definitely read Nancy Kronenberg's paper on VAXclusters.)
• NFS: Of course, one of the two indispensable tools of a CS research organization in the late 1980s was a Network File System (NFS) server; you could access it from almost any flavor of UNIX and many non-UNIX OSes. Naturally, this built on Sun RPC (remote procedure call), which among other things included mechanisms for marshaling data types for exchange across the network between different kinds of CPUs and OSes, though RPC itself as a concept was older.
• X Windows (from Project Athena): The other indispensable tool. Of course we first used workstation GUIs on Suns, MicroVAXen, Macs and Amigas, and then later Microsoft Windows, but the most important innovation of the mid-1980s was arguably X Windows, which allowed a program with a GUI to run a program with heavy computational, memory or I/O requirements on a remote server with the mouse, keyboard and graphics all on the desktop. Yeah, it was hard to configure and get working, and architecturally the split of functionality between the desktop and the server might not have been right, but this set the standard, pretty literally.
  I had forgotten how big Project Athena itself actually was; IBM and DEC contributed several thousand machines, from PC-class to large minicomputers and servers, and about ten staff to MIT.
  The other big thing to come out of Athena, of course, was Kerberos. Both X Windows and Kerberos are still in use today.

Those were the ones that permeated the local atmosphere at USC/ISI, where I worked 1986-1992, then again 1995-1997. There were probably other systems that I was using at the time that I have forgotten were radical or influential; to us, this was just the ocean we swam in, unaware of the water except when something broke. (My first job, as a sysadmin primarily responsible for the VAXen but with secondary responsibility for pretty much everything else, was to fix things when they broke; that was often enough to keep a pretty good sized group of us busy full time.)

I'll do a separate post on some of the distributed OS research systems and papers that influenced me. There are a bunch of those, too...

Spelunking CACM, Vol. 16 (1973)

James R. Bell of DEC (Digital Equipment Corporation) (any relationship to Gordon Bell or to the James Bell I went to Caltech with?) wrote a highly-cited article on threaded code that, to my eyes, looks like byte-code compiled code for an interpreted language, as in the figure above. (The figure doesn't quite convey the distinction between the left and right figures, but it's there). On the CPUs of the 1990s this many jumps would totally trash your pipeline and possibly your cache, though today's CPUs invest a lot of effort in branch prediction and the like such that some of those jumps could cost as little as zero cycles, though the indirect through a register could make that harder.

Before the late-80s trend toward language-agnostic RISC systems that put the onus of efficiency on compilers and run-time systems (and ignited the most ferocious era of Moore's Law-enabled competition), it was common in systems research to consider hardware architectures that were tuned toward execution of a specific language. A team from IBM microprogrammed an IBM 360 model 25 to accept a baroque machine language specifically for APL. I rather miss those days; I was a fan of the Lisp machines of the 1980s, though there were among the first and most thorough victims of the Killer Micros.

 It's interesting to note that people have been concerned that we might have too many PhDs for half a century now. Such opinions seem to alternate (during boom times) with the fear that we don't have enough, that we are eating our seed corn (to leap ahead to 1981 in CACM for a minute).

We have done a little work on clique finding on quantum computers, so I probably should be more familiar with the work of Bron and Kerbosch. I am rather deliberately not looking just for articles that are highly cited; that would be boring and wouldn't really help anything. Instead I am looking for trends as well as things that just catch my fancy, as clever or prescient or sometimes extra-far off base. But this one might be the single-most cited paper in CACM in calendar 1973, and so is interesting for that reason as well as the overlap with my own work.

Overall, my impression of 1973 is that it was a year of "settling in", of solid but mostly not groundbreaking work, at least as represented in CACM. Soon enough, though, we will be into the Xerox PARC, home PC and UNIX workstation eras...looking forward to seeing how CACM changes. Next stop: the current half-century!

Spelunking CACM: Some Thoughts on Operating Systems

Reading through these early papers, it's astounding how much the Titans understood, and what they could see. This is perhaps most evident in the field of operating systems.

I am known for saying, "Hardware has been ahead of software for my entire life," but it's important to make the distinction between vision and implementation in both. Also, for OSes, hardware support is often key, so they develop hand in hand, and given the difficulty of effective simulation, it may be natural for software to lag hardware, but here I am not talking about a few months; I think it takes us YEARS to fully exploit the bounty of computational capabilities that the hardware gods provide. See, for example, Larus's Spending Moore's Dividend.

And obviously, OSes continue to be developed, hopefully on a largely monotonic upward trend.

But here I want to talk about the profound ideas in operating systems. And, despite my general optimism and respect for the younger generations, this is going to sound pessimistic...

I don't think we have had a Truly Important idea since the late 1960s or early 1970s.

By that time, the basic structure was in place: the program and the process; multiprogramming and multitasking; files and hierarchical file systems; virtualization of memory and entire systems; inter-process communication; shared-memory and distributed-memory parallel processing; networks; even the rudiments of distributed file systems and systems existed in Farber's DCS. It was all there.

So...

What was the last "this changes everything" idea in operating systems?