How I Learned to Code Part II

Last time I talked about my first experience with coding, entering and debugging a type-in program on a mainframe. This time, how I learned “Computer Science”. I went to school for “Computer Engineering”. The school I went to also had “Computer Science”. This was early on enough that universities were still trying to figure out how to teach software development or, as they called it back then, “programming”.

The “Computer Science” program was in the Math department and basically lopped off a bit of math from the undergraduate Math degree and replaced it with programming courses. There was still way too much math for my tastes, lots of advance calculus and the dreaded “diff eqs”. So, CS was not for me.

CE, on the other hand, was an Electrical Engineering degree minus some of the electronics and, better still, the mechanical engineering course replaced with programming. Still too much calculus for my tastes, but a better fit.

With both degrees, what “programming courses” meant was different that it is now. Then the focus was breath, not depth. If language popularity sites existed at the time (which would have been a good trick since the web was 10 years away), the top three languages probably would have been FORTRAN, COBOL, and some random assembly language (likely for a CPU that’s long gone).

So, in some kind of rough order, I had courses in Pascal, IBM 360 Assembler, FORTRAN, Lisp, Ada, PDP11 Assembler, and 8086 Assembler. The only language I ever had twice was Pascal, there was a theory course that used it. CE was light on theory, CS had more, but tended to have assignments written Pseudocode instead of actual code. Of course Computer Science Theory was pretty much a work in progress at the time anyway.

The idea was that, because there was no way to know what you’d be using in the real world (and it was as like as not it would something that was new, proprietary, and/or assembler), you’d better be exposed to as many language and as ideas as possible.

This is an awesome idea and it’s served me well over the years. Most languages of the time were functional, but Lisp taught me lambdas, Ada had objects and exception handling, and assembler forced you to understand what was going on under the hood.

For a long time now it seems to me that the trend, especially in code schools, is to go deep in one language. All Java, or all JavaScript. Maybe there’s some kind of survey course/class that covers other ideas, but it’s not learning in depth. I think that’s a shame. While there is value in going deep, I think there’s far more value in starting with a broad understanding.

My (official) experience in school didn’t teach me a single programming language I ever used in anger, but it did teach me concepts I still use everyday and, far more importantly, it taught me how to approach new languages.

Hopefully, my point is clear, learn more languages. If you mostly to JavaScript, learn some Ruby. If you already know Ruby, try out the new functional hotness. And don’t just read up on it, write some code. Or better still, take apart someone else’s. More on that idea next time.