Image via Wikipedia

Adam Gonnerman wrote an insightful post about how showing the average user the Linux command line (or the DOS command shell on a Windows box, for that matter) can create a sense of fear and intimidation.  It’s an interesting piece and I highly recommend reading it as well as the conversation in comments.

As I look at my own comments in that discussion, I’m reminded of how much my thinking about computers has changed over the years.  When I was in college, I was a total command line snob.  I looked down at GUI’s in general and thought they were the road to making every computer user stupid.

I think this was a common mentality for a lot of us who were into computers back when I was in college and before.  After all, when I first started college in the Fall of 1992, Windows was still something you started from the DOS command line after you booted the machine.  And the computers in the college’s computer labs were set up under Novell.  You’d enter your login credentials, get dumped to the DOS prompt, and type “win” if you wanted to start that stupid GUI.

Even Linux distributions tended to treat XWindows as an afterthought at the time.  That same freshman year, I loaded Slackware Linux onto my IBM XT clone (I will admit that I was nowhere near the cutting edge in terms of the computer I personally owned).  It involved downloading a couple dozen images and burning them onto 3.5″ floppies and then using a special boot disk to install the system on the computer.  XFree86 was an optional install and the distribution was — again — set up to have you log into a command prompt and then start XWindows from there.  And since trying to get XWindows to work on your particular configuration was no easy task back then, it struck me as mostly a waste of time.

So I came through a time when using a computer meant you had to be a wizard with a command prompt.  It wasn’t optional.  You learned all the magic commands and you lerned how to use them extremely well or you were hopelessly lost.  It was a glorious time, especially for those of us who loved the challenge.  So to me at the time, the growing popularity of GUI’s (by my senior year, all the computers in the lab were running NT 3.5) and the ease of access they offered was destroying the challenge.  It was making computers something useful for anyone rather than the playground of the geeky elite.  And I was just enough of a snob (and had just enough of my self-worth invested in my geekiness) that this upset me.

So what changed?  To be honest, I changed.  I quit keeping up to date on computers.  I became the average computer user myself, and I found that I liked being an average computer user.  So I let go of my elitism.

I suppose a few readers may be surprised to hear me refer to myself as an average computer user.  After all, how can a software engineer — someone who is well versed in programming computers — be merely an average computer user?  Well, the answer to that is that I’m an embedded software engineer.  And that’s a rather different kind of computer programming.

I’m currently developing the software for a very unusual device.  It’s a computer, but you won’t see it sitting on anyone’s desk.  It has no keyboard, mouse or monitor.  In fact, if you look at it, all you see is a big metal box with a bunch of cables coming out of it.

Inside, there is a bunch of analog-to-digital converters and I/O expanders that allow the processor to read or assert logic levels on various signals on the circuit boards inside that box.  My job is to develop the software that accesses those ADC’s and those I/O expanders with all the signals, do stuff with the data read, and assert certain signals based on that data.  I spent most of this afternoon making sure I could communicate with the ADC’s and I/O expanders.  Tomorrow, I’ll spend a significant amount of my time making sure that the readings I’m getting from the ADC’s are valid and mean what I think they mean.  I’ll also spend time making sure that I can read and control the logic signals from the I/O expanders as I expected.

This is a typical programming project for me.  I spend most of my time looking over data sheets for devices like ADC’s, I/O expanders, microprocessors/microcontrollers, EEPROM’s, and power management chips.  I also read schematics and hardware design specifications that explain how these devices are configured and are supposed to work on the system I’m currently working with.  I’ve learned to write assembly code for PowerPC‘s, ARM processors, Blackfin processors, and a few others I’ve probably forgotten about.

Quite frankly, after I’ve spent all that time learning about the stuff I need to know to work with the devices I program, I don’t want to learn about the computer sitting on my desk anymore.  I just want it to work and work relatively well.  I’ll let someone else worry about making sure all my programs work correctly and that my computer is secure and safe from viruses.  After all, the computer on my desktop is just a tool to me now, and tools are good if they’re easy to use.  It gives me more time to focus on all that embedded stuff that’s part of my job.

So I quit being a command line snob.