What my CompSci degree got me

How a computer works on the inside

This is the Von Neumann Architecture, as well as things like the latency hierarchy (which I notoriously failed to grasp for one of my independent projects. more on that learning experience later), and why multi-processing is hard. This was useful to know.

Kids these days can get that from online study. But in 1993, 'online' was a hard place to navigate, and your local community college library was a better place for that kind of research.

Parallel processing is the future, and really cool

My one focus for my degree was parallel and distributed computing. That fascinated me. It was a good thing I did, because that's where the industry went in the next couple decades. The Pentium Pro, which introduced SMP parallel computing to the x86 space, released while I was in college. The department got a computer with one in it, though I don't remember if I ever used it.

The lessons I got in writing to write parallel programs stuck with me the rest of my career. We knew those problems in the 1980's, and still didn't stop us from rediscovering all of the bugs along the way multiple times.

Distributed databases are hard

Remember that failed independent project I mentioned? It was for my Databases class, and I took that the quarter after my parallel processing class. So I decided to write an experiment to discover the effects of strong versus weak data locality in joins across a distributed database. This was written with the PVM C extension, and I roped in every campus computer I had login rights to (3 DEC machines, 3 NeXTs, and an x86 linux box). I got it to do what I wanted!

Except. Latency. I didn't make my tables big enough to overcome the round-trip-time latency inherent in this design, so my experiment didn't have a signal, per se. I ended up writing a null-result paper when I turned it in. I fully expected to get a bad grade on it.

I got an A on it.

Buwhuh? went I. So I hunted up my prof during office-hours and asked. And he said:

Once I realized you got it working, you got the A.

...huh...

At the same time I was doing this, Novell was writing and bringing to market a new distributed database called Novell Directory Services for use with version 4 of NetWare. Unlike NetWare 3.x and earlier, NDS would allow the same accounts, passwords, and groups to work on multiple NetWare servers. They had a lot of bugs in the early versions. By the time I got into NetWare 4.11 in about 1997, the most egregious bugs had been smoked out; but they were still finding consistency problems along the way.

This was before the CAP Theorem had been written up, but their bugs were all CAP problems. You see, they had some competing priorities in their build:

• Eventual consistency was fine for boring attributes like Surname or office-address, but we needed fast consistency for things like account-lockout and password changes.
• Networks fail, stuff gets lost. You need janitor processes to clean up the messes and retry things.
• Database replication over slow links (think 56K leased-lines or ISDN) is even harder.

Watching Microsoft go through the same learning process for the early versions of Active Directory was full of luls for us Novell admins.

Microsoft solved the consistency problem by providing a filtered view of the database in the form of the Global Catalog, and by doing differential sync of attributes; certain attributes replicated Right Now, while others waited for the replication scheduler.

Because of that class I had, I understood far better why these systems were failing on me, helped me provide much better bug reports, and allowed me to not put false trust in the reliability of these systems under odd circumstances.

Fixing other people's code is a separate skill

I'm not proud of this, but one of my best learning experiences for dealing with modern software development came with my computer graphics class. That quarter I put in a 1.5x load, and simply didn't have time for a heads-down programming project. So I put in for an extension, which I got.

That class was well timed. Toy Story came out during that class run, so we had a field trip out to see it. Then afterwards, we met at the Prof's house to tear apart all the artifacts we saw and techniques on display. It was fun!

But the project for it was vexing me. I copied a version of my roommate's code. But, it didn't work. It didn't work in rather spectacular ways, as I found out. I got it working, and scrubbed some of the personality off of it while doing so. Got a B, because my hidden surface removal shouldn't have worked, but it somehow did.

That experience was highly educational because it was my first experience looking at someone else's codebase, and fixing their problems. Getting the experience was unethical; but review-and-fix is a skill I kept, and came in very useful.

A 4 year degree

Career gate-keepers for my first two jobs were very relieved I had one. Otherwise, they couldn't have hired me.

Except for the degree itself, these are all things that you can give yourself with enough online digging, and drive. Now. 20 years ago was a different Internet, and finding information wasn't nearly as easy as it is now.

But what did I not get as part of my CompSci degree from the mid 90's?

• Test-driven development. Not invented yet.
• Agile methods. Not invented yet.
• Scrum methods. Not invented yet.
• Extreme programming. Not invented yet.
• Waterfall. We were a CompSci department, not a 'how to write software for profit' department!
• Web Development. WWW took over from Gopher during my time in college. My last year, a few students were experimenting with httpd and cgi-bin/ things, but it wasn't in the curriculum yet.
• Virtualization. That was a mainframe-only thing in the mid 90's, and we didn't have one.
• Interpreted languages. Like many CompSci departments of the time, it was all C development, with maybe some other languages as bolt-on electives. I didn't elect.
• Java. 1.0a released while I was in college. No one used it yet.
• Assembly. There was a brief section of it. I already knew my career would never involve it.
• The names of algorithms not involved in sorting. They may have come up, and I may have been tested on them. But did not stick. Red/black B-trees, and suchlike may have come up, but by the time I was running into them professionally I had forgotten everything.

I got some good life-skills as part of my degree. Most of the best learnings were abstract concepts I ended up applying later to troubleshooting and analysis work. It was the right move for me in the time-period I was in. If I were to time-travel back to 1993, I'd probably have myself go through the program again.

If my non-existent child was considering a career in programming, the choice is less clear today.