The incredible lightness of code - programming as art - Technology Transfer - Column

We probably came from some 16th century scientist or mathematician bent on discovering new pieces of the puzzle called "life." Or maybe we came from some Renaissance artist bent on portraying "life" through oil and canvas. But we really weren't unleashed in the world until the "mindless thinking machines"--computers--came into being. We began our quest for dominance over them.

The first computers were rudimentary, and didn't really present the right conditions for Programmers to evolve. But somewhere in that early labyrinth of wires and tubes, the first true Programmer was born.

Then came IBM with its mainframes--a "real" computer. The chance to make these monsters do what they were told to do brought forth Programmers in great numbers.

Enter the IBM PC. Its affect on the industry, and on Programmers, was profound. A Programmer could go into a room by himself with a computer that served him only, and be king. (Or queen. I use "he" for consistency, a Programmer's trait.) And then came the add-ons--gizmos and peripherals that made the kingdom more powerful and more interesting.

And software, oh, the software. I know, it sounds a bit strange--a Programmer getting excited about prepackaged, unmodifiable software! Perhaps it was source-code unmodifiable, but modifications were made. Some called these Programmers by another word--hackers.

These dyed-in-the-wool Programmers could dissect an executable file using DOS's DEBUG or the Norton Utilities. If a program didn't suit them, they'd find the offending part of the code, modify it, and get back to work (or play) with an undocumented upgrade.

There are two classes of Programmer: System and Application. System Programmers are excited by installing a product and fitting it in with the current system. They enjoy the power and authority they have in being the "superuser." Applying "patches" and installing "hooks" gives themsustenance. Most Systems Programmers need only please themselves to be fulfilled in their computer-conquering missions.

Application Programmers, on the other hand, enjoy turning others' dreams into a computing reality. They, unlike their systems brothers, must talk to the "other world" of users. This communication is a clinical necessity, done in order to get enough of a description to make the dreams real.

For an Application to Programmer to feel satisfied, most everyone must be happy with the product. However, the Programmer must be satisfied as well, but frequently is not because the needs of the users outweigh his own with respect to functionality. In these cases, he is quick to point out why something ends up working the way it does, and not the way he thinks it should have.

Apps Programmers will also play user for themselves. When time and opportunity permit, they will create new applications or enhance existing ones to suit their needs.

A professor mine (who must have been a Programmer) said that programming was an art. He stressed that there were many ways to write the same program, and he would be highly suspicious of any programs that looked too much the same.

It took me several years, but I finally discovered what he meant. After those first simple, straightforward programs I wrote, it started to become apparent that there were myriad ways to do things. The end product was the same, but the readability, modifiability and execution time could vary infinitely. The structure itself could be arranged so that it was indeed "a work of art" in the eyes of anyone who knew anything about Programming.

Along this same line, Programmers embed "how they think" into the source code. There is little wonder that many Programmers are very touchy about code reviews from people they consider their technical inferiors--they risk having their innermost workings criticized.

In today's world, managers of Programmers tend to overlook the closet artist living inside. Rather than give him the freedom he needs to create a business solution, the Programmer/Artist is given a deadline. This, of course, creates stress the boss can't relate to. This is a stress caused by not only having to produce the solution, but having to do it in such a way as to preserve some of the Programmer's artistic creativity.

Being forced to do both in a usually impossible time period generally causes the "overtime syndrome"--a cyclic malady that causes high turnover. The Programmer/Artist must work overtime to get the solution AND satisfy the balance of creativity that is self-imposed. The late hours cause "burn out," which is compounded by a lack of sleep. This, in turn, slows turnaround at work, pushing him further behind schedule so he works more overtime ... see?

What happens is that the application goes in the night before it is due, 85% tested, 50% artistically complete, and the Programmer goes home thinking, "Another piece of junk goes into production." He spends the next week reading the help wanted ads. Wake up bosses!

PROGRAMMERS VS. WANNABES

Programmers must deal daily with others who see themselves as Programmers but who are, in reality, programmers--or worse, programming types. These Programmer wannabes think that because they can get a program to write "Hello World" to the screen, or solve a polynomial equation, that they are Programmers. HA!

You can tell these phonies from real Programmers. First, they have no sense of creativity. It's the difference between Renoir and a house painter.

And application structure is amazing, too. It is sometimes incredible that all the programs can talk to each other. If you try to get the "author" to tell you how it works, he will probably have to get back to you after he studies the code a while. (Programmers can quote you code that they have written.) But the easiest way to spot a non-Programmer is to give him a dump or error message to figure out. He will find the weirdest connections between the problem and the rest of the world, and usually won't even look at the data involved, which 95% of the time will lead to the problem code.

Of course, wannabes have their place. Bosses usually like them because "deadlines don't hamper their creativity." So what if their programs have to be completely rewritten the next time they have to handle a slightly different set of data or parameters? "You can pay me now or you can pay me later."

At home, your Programmer will take on one of two roles if he is the norm. The more prevalent is a slow-moving, even-tempered person who tends to analyze all the ramifications of any significant event, such as making a purchase, adding a room to the house, or going out to dinner. Out of the blue, he will perform a cause-and-effect analysis of situations he or you have been in and determine, de post facto, what the best course of action would have been. It's a natural extension of his Programming skills.

The second role is the "turn-it-off-at-home" type. These are a rarity (within the bounds of Programmer definition) and are usually the life of the party. These people from friendships and alliances with many people who represent different walks of life. While this Programmer type likes to mingle and take charge, the first type prefers to blend in with others like him.

Juggling home and job is a problem for both types. Even though Type 2 can leave it at the office, he may not leave the office until he has put in 50 to 70 hours a week. Type 1, on the other hand, generally puts in 40 to 55 hours, and brings the rest of it home to mull over or work on. He probably has a PC at home. If he can link up by phone to the office, he'll do that, too.

There is no trick to coexisting with a Programmer. However, keeping in mind their traits, they are fairly easy to get along with.

Bosses, give them the time and resources to get the job done right, and quit trying to save a few bucks in the short term only to pay it out tenfold in the long run. And give them something new to work on regularly. If Picasso had been forced to do still lifes over and over ... get my drift?

Spouses, let them analyze the world for imperfections and better ways. After all, at most it is just an annoyance. And if they work a 50-hour week, it's because they feel challenged to "beat the machine."

COPYRIGHT 1991 Wiesner Publications, Inc.
COPYRIGHT 2004 Gale Group