On Tue, Dec 11, 2007 at 03:59:32PM +0900, Chad Perrin wrote:
[...]
> I tend to agree, to some extent at least.  I'm surprised, though, that
> you didn't address the matter of how a CS degree is characterized here.
> Computer Science degrees are not supposed to indicate a basic ability to
> program -- computer science as a field is something else entirely.  It is
> as though everyone expects a CS degree to be the definitive programming
> certification.  Of course, because that's how it is treated in the job
> market, schools have started chasing that in how they structure their CS
> degree programs, with the end result that they end up being about as
> worthless as vendor-driven certifications.  Oh, sure, they make you
> *look* good, but they don't make you *actually* good, at least judging by
> the results I've seen.
> 
> It seems most CS degree programs are just (really long, really expensive)
> Java certification courses, these days.
[...]
> Sadly, degrees are much the same -- but there's probably less than one
> hundredth of one percent of employers out there that realize this.  I
> learned a lot in college -- but mostly in two specific ways:
> 
>   1. pursuing knowledge on my own time
> 
>   2. sticking with a good instructor for future classes, even if they're
>   outside my chosen degree program
> 
> The end result is that I didn't learn all that much from the classes I
> needed for the degrees I pursued, even when I was getting As on
> everything.  Learning is something you do, not something you receive.

A CS degree does not say a whole lot, other than an ability to at least
tolerate an undergraduate education. A CS degree from a school with a known
reputation says a lot more.

An ideal CS program does not teach programming beyond the first year. It
requires programming, but it teaches problem solving within the context of
software (and maybe hardware) development. One should come out of a CS
program familiar with a body of knowledge involving numerous problem
solving approaches, including languages, algorithms, data structures,
architectures, approximations, strategies, design patterns/idioms, etc.,
and their tradeoffs. One should also have the ability to analyze the
relative suitability of various solutions (from an algorithmic analysis
perspective as well as time/memory/power/accuracy tradeoffs). Recognizing
problems as those one already knows how to solve (or can be proven
intractable) is pretty important, too.

Programming is a means to an end here. It is the practice of the various
skills listed above. It is also part of the learning experience. (Sure, you
can learn the theory of preemptive multitasking and concurrent processes,
but you understand it a lot better if you've implemented a semaphore in
assembly.) I learned to program well before college, and used (and
improved) that programming skill throughout college, but I didn't get
really good until I had to TA a software engineering course in grad school.
In college I managed to implement a preemptive multitasking OS on top of
DOS, a web-based DB-backed app (in 1994, before we had these nice
frameworks, in C, which sucked), an ATM (not the bank kind) networking
simulator, a version of Eliza (in ML), a raytracer (in C++), a parser (with
lex/yacc, though I can't remember the details now), and others I can't
bring to mind at the moment, as part of my coursework. Those projects
weren't about programming, they were about problem solving.

I'm not going to claim my undergrad education was perfect (for example, I
shamefully avoided the compilers course), but it did teach me how to solve
problems with software. That's what I do professionally, whether it's in
Ruby or some other language (as it has been and as it will be). I'll grant
you that a CS *degree* is no guarantee of a CS *education*, though. (Also,
for those of you who did not get a CS degree, the lack of a degree is no
guarantee of a lack of a CS education, either.)

> CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
--Greg