Semi-colons, hexadecimal and a career in librarianship: Reminiscing about coding

By Dave Hook

I don’t shy away from opportunities to geek out. Yes, I’ll happily discuss defunct search engines (say what you want about Alta Vista, but HotBot was way better!) or discuss old applications that disappeared far too soon (like WinAmp – It really did “whip the llama’s ass”). So, when I saw Open Shelf’s call for coding stories, I couldn’t resist. The call did bring up some fond memories of coding from the past, but also got me thinking about how being able to code has influenced my problem solving style in my work today, even though I’m no longer actually coding anymore.

Warning: Non-coders proceed with caution. Because it’s about to get nerdy!

I first learned to code when my dad (a school teacher) brought home a Commodore PET from his school and I learned how to program in BASIC (a programming language developed in 1964 and designed to teach coding to beginners). I’m not sure what my very first BASIC program was, but it was likely very similar to everyone else’s first BASIC program. Something along the lines of: 

10 PRINT “Dave is awesome!”

20 GOTO 10

Shortly thereafter, we got a Commodore 64 for the family (yes, that’s right—no 20KB Vic 20 for us, nothing less than 64KB of memory would do!). And that is when I really got to learn BASIC.

By the way, if the Commodore 64 reference doesn’t give you an idea of my age, I’ll also tell you that when I took Computer Science in high school we got to learn on the brand-new VAX machines. The year before, students were saving their programs on punch cards. If you don’t know what a punch card is, watch an episode of the original Batman series starring Adam West. 

Photo by Alexander Grigoryev.

While I was in high school, Pascal (developed in 1970 by Niklaus Wirth)  was the language we learned. Admittedly I quite liked Pascal, despite all the semi-colons. If you’ve ever programmed in Pascal, you’ll know exactly what I mean about the semi-colons. If you’ve never used Pascal, I’ll oversimplify it a bit: with some lines of code you have to put semi-colons at the end and others you don’t. 

There are some ultra-complex rules out there about when you do and do not need a semi-colon, but they probably only made sense to the person who invented Pascal. Oh, and by the way, if you get one semi-colon wrong, your entire program will crash. 

The best thing about Pascal was that it was easy to debug. If your program crashed, you knew it was likely because you either put a semi-colon where you shouldn’t have, or you forgot to put a semi-colon where you should have. It was far easier than actually learning the rules in the first place.

In university, I learned FORTRAN (developed by IBM in the 1950’s, which I didn’t care much for) and REXX (first developed in 1979, also at IBM, which I loved). Unfortunately, few companies ever used REXX though and it never really caught on.

In one course I took, we learned to program in Assembly Language. And if you thought that Pascal’s semi-colon laws were overly complicated, Assembly Language says “Hold my beer…”

Imagine the most complicated programming language you can think of. Now, imagine a language that is ten times more complicated and that requires a detailed understanding of the computer’s hardware. Now, imagine having to code that in hexadecimal. That’s Assembly Language. It may as well be just one step away from coding in ones and zeroes. 

Assembly Language code isn’t compiled into more complicated code that the computer can better understand; Assembly Language is the code into which other code gets compiled.

Photo by Bill Bradford.

Looking back on my university days, I find myself thinking: “Oh. My. God. I can’t believe I actually programmed in Assembly Language.” And while I may not have a whole lot of practical use for it nowadays, the experience has served me well in a couple of ways. Any time I run into something in IT that I’m not familiar with, I can always remind myself that I’ve programmed in Assembly Language and there can’t be anything more complicated in Information Technology than that. 

In my first job after I got my library degree, one of my first roles was managing an Intranet. As a result, I had to teach myself a number of web-programming languages: HTML, JavaScript, ASP, Visual Basic, and even SQL. Teaching myself web languages wasn’t all that difficult (because, you know, Assembly Language and all that). I learned mostly through looking at other people’s code, figuring out what it was doing, changing a few things around and seeing what broke. Always in a controlled environment, of course. 

My career has since taken a different direction. I don’t get to directly use my coding skills as much anymore. About the only coding I do these days is when I need to troubleshoot a problem on my library’s website. And that is often as easy as going into the website and looking at the source code directly.

But, that being said, the skills that I gained through learning to code have helped me immensely in my current role. As manager of IT, I came into the role having to learn dozens of new software applications in a very short timeframe. Understanding the logical flow that you need in order to code really does help in picking up the kinds of logic needed to understand a new application. As painful as coding sometimes was to learn, it also taught me a great deal about the inner workings of a computer. 

And so, even though I don’t get to use my coding skills nearly as much anymore, I’m still glad that I’ve had those experiences. They have been invaluable in allowing me to become proficient in the skills I need to do my job well and learn new skills much faster than I would have otherwise. 

Plus, if I ever get the “you’re just a librarian…what do you know about IT?” attitude, I can always play the “Back off! I’ve programmed in Assembly Language” card. Maybe I should get that printed on a T-Shirt.

Dave Hook is the Manager, Information Technology at Milton Public Library. He has programmed in Assembly Language and lived to tell about it.