Catch up on stories from the past week (and beyond) at the Slashdot story archive


Forgot your password?

Journal Ichijo's Journal: Moore's Law of Computer Science Degrees 1

So our CS Ph.D guy wrote a class to chop up a string by a given token character. It uses strtok() which is not thread-safe, so he wrote this disclaimer:

// if object is used by only one thread then it is thread safe

This kind of description from a Ph.D truly boggles the mind.

Now keep in mind the following terms:

class-level thread safety: Objects of the same class may safely be instantiated any number of times in the same or multiple threads. This means there is no global data (with the possible exception of instance counters). However, multiple threads may not necessarily be able to safely access the same object.

object-level thread safety: A single object of the class may be safely accessed by multiple threads. A class that is safe on the object level offers synchronization for its data members.

So his code was thread-safe on the class level but not the object level. But we're just getting started...

So far he has only used this routine in a situation where we already have a completely (class & object) thread-safe string-chopper. Now the string in question represents a data structure, so you should not parse it yourself. Anyway, I've always thought, if you're going to reinvent the wheel, you should make a better wheel.

I've identified two main problems with his code so far (it's redundant and not thread-safe). But this is the same person who:

  • replaced a database with a series of ASCII (not Unicode) flatfiles with non-escaped field delimiters, which depends on the Windows registry for some of its data, and
  • thinks, because we use structured exception handling to catch OS errors, he doesn't have to fix his NULL pointers. This leads us to the fact that he...
  • always uses char *'s instead of C++ strings.

I hope he doesn't use that strtok class for creating and parsing CSV files, because I'm afraid he won't use proper escapement.

We also had an employee from India with a Bachelor's degree in Computer Science. He and an ex-lawyer were the only two programmers we've ever fired due to technical ineptitude.

Speaking of degrees, have they even started teaching C++ and OO in college yet? Chances are you won't learn about realtime operating systems, Beowulf clusters, Extreme Programming, or any other cutting-edge technology throughout your Computer Science college career, unless you do your own research.

So all of this background brings me to my point. Just as a brand-new computer is obsolete before you bring it home, so are Computer Science degrees. Call it Moore's Law of Computer Science Degrees. Maybe mandatory refresher courses to maintain your degreed status and/or industry licensing/certification are the answer.

Update (6/8/2003): I should point out that my good friend Zoarre disagrees with my conclusion. The principles learned on the road to a CS degree will withstand the test of time and can make a programmer better. (The example I gave of the Ph.D he dismissed as being a "sloppy coder.") In his words:

A CS degree can only help a good programmer write better code. If someone with a CS degree (or a PhD) is a shitty programmer, it's because they always were.

Zoarre doesn't have a degree, but he's worked with both types of programmers. I don't have as much experience as he does, but I think he's right. So I stand corrected.

This discussion has been archived. No new comments can be posted.

Moore's Law of Computer Science Degrees

Comments Filter:
  • Don't hire people with CS degrees...

    Seriously - if you can find a programmer who can pass an on-site test (as in, write a program that does <foo>) and doesn't have a CS degree, chances are they learned their programming skills because they enjoy doing it, or else because they've been doing it since before there was such a thing as a CS degree. Either case is better then the person who got a CS degree in college just because they thought it was a good way to make a big salary. Bleh.

    At my last job,

I go on working for the same reason a hen goes on laying eggs. -- H.L. Mencken