The Life of a Programmer

January 1997

I have now been doing programming of some sort for 30 years, getting paid for it for 29 years, and getting paid enough to live on for anywhere between 28 years and 10 years, depending on what your definition of "having enough to live on" is.

This month I am supposed to talk about how to find stuff on the internet. Here is how expert in that subject I am: My wife asked me to find some information on some furniture that she wanted to buy, so I ran an Alta Vista search for "leather couches". Well, I never knew there were so many different ways that you could use leather products, and none of them concerned couches.

So, I thought I would talk this month about what it is programmers do. Most everybody in the reading audience presumably uses a computer, or else you really don't have much need to read this particular publication. And some few of you probably do some form of programming, although you would not at first glance think that is what you are doing. If you have ever designed a spreadsheet, or generated a word processing macro, you are doing programming, albeit within the context of some application package.

Real Programmers write the applications.

The most stressful thing in a programmer's life, is that his knowledge has a half life of less than five years. Less than half of what you know today will be useful to you in five years, maybe a quarter will be useful in 10 years. I am using absolutely none of the technical knowledge that was my forte even fifteen years ago.

The explosion of knowledge in the programming field is scary. A few years after I started in the field, I believed that I had a pretty good grasp of the knowledge of virtually all the technology that a programmer would work with, from business programming to scientific, from mainframe to minicomputer, from applications programming to systems work. Today that is all but impossible except for the most bearded and ponytailed of gurus, and I have neither. Today I struggle to maintain some degree of knowledge of the few specific fields that I actually have to work in, and let the rest of it fall by the wayside. Two buildings away from my office is the accounting department of World Wide Widgets, and they do all their work with some computer called an IBM AS-400, and they might as well be working in Sanskrit programming for all that I know about what they are doing, and know about the RPG language that they use.

How much programming has changed over the years can be shown in, of all things, cartoons. I have been collecting computer related cartoons for many years, cartoons clipped from newspapers, trade journals, even the Wall Street Journal (some of the best, in fact). The earliest cartoons showed some computer jocks (mostly dressed in a white lab coats), standing in front of a wall sized console filled with hundreds of blinking lights and dials, with mag tapes whirling and printer tape pouring out of slots in the thing, and saying something like "Does anybody know where the ON switch is on this thing?". None of it had any anything remotely to do with reality, but it dealt with the perception of the people who had then never actually seen a computer, and about what computers must be like. Today, everybody uses one, and most people own one, and so it isn't mysterious anymore. Today, you have Dilbert cartoons in every newspaper. Today, even Adam, Funky Winterbean, and Sally Forth cartoons in the Spokesman Review regularly feature people using a computer. It has become part of the background.

Programming, though, is still not part of the common understanding, and so you do have a Dilbert cartoon, concentrating on an engineer / programmer sort of person, but mostly it pokes fun of management relationships, and not the actual job. Where it does relate to the job, here again the situations are generally something that seem possible to the dilettante, and quite impossible to the professional.

There used to be a pretty high barrier between those people who do commercial programming (eg paychecks and accounting stuff), those who do scientific programming (process control and fun stuff), and the systems guys who make the machines work and could care less what they are used for. There is much more intermingling of these disciplines now because of the PC revolution. Much of the programming that was done on a specialized computer before (business on mainframes, scientific on supercomputers) is now done on workstations today.

So, what do programmers do, and how do they do it? Programmers provide the instructions to the computers that creates the applications that the vast majority of us, even other programmers, use. The first job of a programmer is to figure out just what it is that the client of the product wants. This should be the simplest part of the job, since you would think that all you gotta do is ask the client. The problem is the client generally has only the vaguest idea of what he wants, but will be sure to know that whatever it is you produce will be not what he wants, once he sees it. In a formal arrangement, at this point you and the client would create a specification of the work to be done. The client, at a later point, will of course disavow all knowledge of ....

So you make a WAG (Wild Asked Guess) of what the client wants, and start to think about just how to generate the application. First you have to have some idea about what platform the application will run on (mainframe, workstation), what operating system (Unix, DOS, Windows), and what programming language you are going to use (C++, dbase, Visual Basic). Then you have to generate a design of just how you are going to break things down. And this is where the real programming starts.

Computers are fast idiots. They know how to do only a very small number of things, but they do those few things very quickly. I have worked with computers that had only seven useful instructions. There has to be some way to do math (add, subtract, although that simple computer only subtracted); a way to move data around; a way to make decisions; and a way to get data in and out of the computer itself. More complex computers maybe will have two or three hundred instructions, but most of these instructions are variations on each other (add two bytes; add two 16 bit words; add two 32 bit words; add two floating point words).

Thirty years ago, it was common to work with computers at that level, then known as assembly languages or machine language. Except in quite rare cases, that does not seem to be done much anymore. In a sense, I miss it, because it was fun to do, and you could derive a lot of cool ways to get your job done, most of which were horrible practices, but quite effective. Today, we mostly use high level languages, and even non procedural languages to tell the computer what to do to accomplish our task.

Regardless of what language you are going to use, to some degree you still have to break your task down into smaller and smaller functions, with more and more detail in each function. The traditional way to portray this is to ask: How do you get up in the morning? A simple answer (the specification) is: get out of bed, brush your teeth, put your clothes on, and go to work. If you were to treat this as a series of instructions to a computer (the design), the answers would have to be much more detailed. Something like: 1) open left eye, 2) open right eye, 3) yawn, 4)lift right leg, 5) move right leg over edge of bed, 6) put right foot on the ground, 7) lift left leg, 8)move left leg over edge of bed, 9) put left foot on ground, 10-20,000) etc etc etc.

Different languages would allow you to state the functions (eg yawn) in more or less detail (non procedural languages would let you simply state yawn, and machine language would actually have to go into the physiological details of what makes up a yawn).

The actual program, the list of computer instructions, is first entered into a machine readable form by using a text editor, something like a simplified word processor. Windows Notepad would be an acceptable text editor, for instance.

You then use a computer program named a compiler to translate this text into the actual machine instructions (the adds, subtracts, etc) that the computer actually understands. Different companies sell compilers for different languages on different platforms. Generally, your text files contain instructions for only a small part (a single function, perhaps) of the entire job. All these functions must be built together into the complete program by another program called the Linker. At this point, you have the actual program (in DOS terms, the EXE file) which you can try to run.

The above sequence takes you half or less of the total time to do a project. Now the real work begins, in first debugging your program (finding all the errors that you know about), and then testing the program (finding all the errors you don't know about). It is at this point that the client will finally see his program and start telling you what an idiot you are for at such high cost providing him with this indescribable piece of trash, and that clearly what should have been provided is blah blah blah, regardless of some silly specification written weeks or months before.

And finally, after the client either does accept what you have provided, or you have caved and rewritten everything six more times, you get to document the whole mess. Essentially, write the manual. Most programmers find this process the least fun of the project, and most managers seem to have run out of project money by the time we get to this state. I think that you, the gentle reader, will understand that in this regard, at least, I differ from my valued colleagues.

I have stayed in this business for all this time because, quite simply, it is a whale of a lot of fun. There is a real intellectual satisfaction that comes from finally getting this stupid machine to actually do what you want. There is an even greater high that comes after figuring out why the machine did NOT do what you thought you told it to do; it always does what you told it, it is just very often you accidentally tell it to do the wrong thing. In the process control business which I specialize in, not only do you see a screen dancing away to your instructions, or a printer clattering out a ream of output, but you can go and see a piece of machinery actually responding to your commands, hopefully working more efficiently than before, or running faster, or producing more widgets per hour, or whatever. The widget business is itself not real state of the art, certainly not something like aerospace or even semiconductor chip manufacturing. But I am satisfied in knowing that groups like ours can apply computer technology to a traditional smokestack manufacturing business, and maybe keep it going for another half century.