As I’m getting ready to head to Canada, I thought I’d take a step back and just offer a bit of insight into another area of my life and psyche.

I learned to program in machine code when I was in junior high school.  Some of my readers are probably somewhat impressed. A couple of them might be saying, “me too!”  I suppose some might have even learned at a younger age than I did.  The rest of my readers are going, “What the heck is machine code?”  For this group, let me give a quick explanation.  (Those who already know this or can’t handle so much geekery are welcome to skip over the next few paragraphs.  I’ll throw up a flag letting you know where you can rejoin me post-geekgasm.)

Machine code is the only programming language that the microprocessor that makes your computer work actually understands.  While most programs you use are written in C, Perl, Javascript, Java, Python, C#, or one of dozens of language, another program which is already in machine code either took the program written in that other language and converted it over to machine code or read the program in the other language and told the microprocessor what to do.

It’s much easier to write a program in C, C#, Pearl, Javascript, Java, or Python than it is to write one in machine code.  Machine code consists of very simple instructions, like:

• Add the number stored here to the number stored there and store the result over there.
• Check the number stored here and if it’s greater than the number that’s stored there, set this flag over here.
• If that flag over there is set, jump back twenty instructions in this program and start running from that point.

Even the simplest of tasks can take dozens of instructions in machine code to complete.  Doing everything a word processor does would require hundreds of thousands of machine code instructions.  Maybe millions.  Only people who write device drivers and extreme masochists (and believe me, there’s a lot of overlap between those two groups) write in machine code.  Even then, they tend to write in assembly, which uses keywords to represent instructions.  So for example, if I was writing in assembly language, I might write:
ADD AX, BX  (Meaning:  Add the value in AX to the value in BX and store the result back in AX)

In machine code, that would just be a bunch of numbers:
102, 01, 208

The microprocessor would read in those three numbers and know that it was supposed to add the value it had in AX to the value it had in BX and store the result back in AX.  There are programs (conveniently called assemblers) that read programs written in assembly and translate them to machine code for you.

Like I said, in junior high school, I learned (taught myself, actually) to program in machine code.  Technically, I learned to program in assembly too.  But I had to learn to translate my assembly programs into machine code myself (this is called hand-assembling, by way) because I didn’t have an assembler.  You see, I was working on a VIC-20 (the predecessor to the Commodore 64, for those who remember them, and those who don’t, well, just assume we’re talking some really old computers that probably aren’t as powerful as the graphing calculator you used in your algebra class) that my father had gotten me at a garage sale.  I had the computer, the power supply, the old tape drive that you could use to save your programs to cassette tapes.  It was an ancient computer when I got it, so there was no way I was going to find an assembler for it.

Okay, the geek-talk is more or less over.  Welcome back to those who chose to skip it.  So, why on earth did I decide to teach myself programming in machine code when I was so young?  Well, because I was bored.  As I said, I was playing around with a computer that I had nothing for, a computer that let you type in programs written in BASIC (an old programming language hardly anyone ever uses before — and no, VisuaBasic is not (quite) the same) and run them.  I had written all the programs in BASIC I could think of and I was bored with it.  I needed something new to do.  Something challenging.  Then I noticed that one of the manuals I got with the computer included a section on assembly code and listed all the machine code instructions that the microprocessor in the computer knew.  So my next challenging adventure presented itself.

My point in all of this isn’t to show off my geek cred or brag about what a smart (and possibly insufferably smart) kid I was.  It’s that I’ve always loved a challenge.  When I get bored, I want something to do.  I want something to tinker with.  I want a problem to solve.  I especially love those challenges where people tell me I can’t do something, especially when it comes to computers.  (I had college professor use that fact to trick me into taking on a project for him, actually.)  Learning to program in machine code on that old computer meant doing something that wasn’t easy.  (It also gave me the ability to do something with that computer that an uncle said I couldn’t possibly do.  Like I said, I especially love challenges where people tell me I can’t do something.)  It’s a trait that’s marked most of my life.

Granted, the downside is that it also means that I’m more interested in the challenge than the result at times.  There’s been a few times where once I’ve conquered the challenge, I’ve lost interest in the work that was actually related to the challenge.  “Why should I finish the program?  I figured out how to do the hard part.  The rest of it is easy tedious, and uninteresting.”  Needless to say, that’s an attitude the college professors found irritating.  Fortunately, I learned to suppress it on the job.  But I’ve also learned to let my boss know when I need another challenge.  Because I live for them.  And I falter without them.