Not Just Coding

We were driving home tonight, and NPR was interviewing some Robert Frost scholar about the publication of a book of Frost’s cryptic notebooks. It took the guy five years to put the thing together. I was drifting into a nice NPR doze while they droned on and on, when suddenly the host went from relating a story about Frost at the Kennedy innaguaration to talking about a talk that the book editor had given at the dedication of the Robert Frost library in “Am-Hurst.” At this point my ears perked up. The Robert Frost library is in Amherst, MA, the town in which I grew up. You pronounce the name with a silent H. Pretend you are saying “Amerst”. To this day it pains me physically to hear people say this the wrong way.

As I’ve gotten older, a lot of my old peeves have fallen by the wayside. However, some of the world’s indiscretions still slice at my psyche like a brand new mandoline julienning a piece of zucchini. Just this weekend, there was a fluff piece about that crazy Hungarian Charles Simonyi and his silver bullet for solving the software problem. I read much of it without getting upset at all. There was a lot of complete nonsense about the paradise of “intentional” programming. This paradise has been at least 10 years in the making with no product in sight. This was not the cause of my distress. I ignored the rhapsodic prose about a system so sophisticated that the non- technical “experts” who just want to “get something done” can interact at a magic “workbench” and build what amounts to a perfect specification of exactly what they want, unless it isn’t in which case they can hack up another iteration of the perfect specification with almost no difficulty at all.

This sort of hype does not bother me anymore. Our modern world is all about instant gratification. If people want to delude themselves into thinking that difficult technical problems have magic solutions, then more power to them. It’s common to think of the general-purpose computer as a machine that can be told to do anything. But the real nature of the machine is that it can be told to do anything provided that you have sufficient time and money. If you are lacking in the other resources, you need to compromise on the specification. Anyone who thinks otherwise is delusional, but I don’t have time to fight that educational battle anymore.

I also was not bothered by the boilerplate text bemoaning the sad state of the software industry. If experts are to be believed, there is almost no modern endeavour more doomed than that of software projects. They ship late. They go over budget. They fail entirely. They are the epitome of incompetent management. I’ve heard this before. I find that these days I like to emphasize the positive aspects of the software industry. The modern consumer electronics industry has software at least partially to thank for its continued riches. Almost every major appliance or device that you interact with these days is running some of this software stuff that never works and is never shipped on time or on budget. Software is what transformed the Internet from a pile of wires to something that people want to use every night to talk to their parents on the phone. People don’t seem to realize this. That’s OK. I understand.

I also did not let myself be bothered by the fact that the New York Times spent so much copy profiling the man who inflicted “Hungarian Notation” on an unsuspecting software engineering world in the 1980s. It’s amazing to me that they let him near a machine anymore. But that’s not the main subject of my wrath.

No. What set me off was the reason that the Times writer offers for the so- called software problem:

The reasons aren’t hard to divine. Programmers don’t know what a computer user wants because they spend their days interacting with machines. They hunch over keyboards, pecking out individual lines of code in esoteric programming languages, like medieval monks laboring over illustrated manuscripts.

This is certainly a popular depiction of the software engineer. In fact, a different piece in this same paper about six months ago had this classic:

Jamika Burge is heading back to Virginia Tech this fall to pursue a Ph.D. in computer science, but her research is spiced with anthropology, sociology, psychology, psycholinguistics - as well as observing cranky couples trade barbs in computer instant messages.

“It’s so not programming,” Ms. Burge said. “If I had to sit down and code all day, I never would have continued. This is not traditional computer science.”

My pet peeve is this notion of “just programming”, or “just coding”. It is hateful and insulting. It implies that what we software people do is completely rote and lacking in any creativity whatsoever.

Consider that Computer Science, while still young, has managed to keep some of the best minds of the last century (Turing, Gödel, von Neumann, Erdos, Newell) busy with its intricate mysteries. It’s an area that is a fascinating juxtaposition of mathematical theory and engineering practice. It has not only introduced a pile of new ideas into the Academy, it has at the same time built a commercial industry that has completely changed how we collect, store, manipulate and communicate information from the world and to each other. And with all of this as background, this clueless second year graduate student is still characterizing “traditional” computer science as “just programming.” The field was never just about programming, even if its deepest problems are ultimately motivated by the toil of the humble programmer. Anyone with half a clue should know this.

The quote in the piece on Simonyi is insulting in a more personal way, because it makes a profoundly incorrect generalization about the very profession in which I work. This generalization is really the same “just coding” sentiment but with bigger words. Because software people spend a lot of time doing something that is complicated and mysterious, it is apparently popular to think that this is all they do to the exclusion of everything else. The picture goes further than that. It’s not just that we do nothing but this weird stuff at the keyboard. No. Programmers, in fact, are not capable of doing anything else. In other words, besides coding, they are not able to

1. Communicate with other humans in a language that the other person can understand.

2. Absorb and understand the desires and problems of a non-technical person, and think creatively about how to solve these problems.

In other words, without Simonyi’s magic tool, programmers, being crippled in the particular way that they are, are completely unable to understand the needs of their clients and are therefore doomed to failure.

Hogwash.

What everyone involved in the production of this piece of goat excrement in the shape of a newspaper article fails to grasp is that the paragraph that they have written down above describes a particular sort of software engineer. Here’s the word I use to describe this sort of software engineer: bad. These people should not be hired. If you have people like this on your staff, fire them. The reason this quote infuriates me should now be obvious. It basically says that all software engineers are people who don’t know how to do their job.

We should know better by now. We should realize that the things that I have listed above are exactly what a good software engineer needs to be able to do day in and day out in order to be successful in the modern marketplace. You have to be able to understand the problem you are trying to solve. You have to be able to communicate that understanding to the rest of the team, many of whom may not be fellow software people. You have to keep communicating this understanding until the others understand it as well.

A software project is, at its core, an iterative collaboration that translates initially vague requirements into the relatively rigid confines of the computing machine. The job of the software engineer is to facilitate this translation and at the same time to be able to guess how long it will take to implement it in code and then spend the long hours needed to debug that code so that the project can ship something that is as close to what was initially desired as possible.

Then we have to do it all over again for version 2.

In this environment, it’s obvious along with everything else they have to know how to do, two skills are critical to the success of a software engineer:

1. Plays well with others.

2. Communicates effectively.

These are exactly the two skills that the New York Times thinks we poor progammers don’t have. This is why they have tickled my pet peeve. This is why, for tonight at least, I hate them.

Afterword

Later in the same issue of the paper, there is a great piece about “nutritionism” and how it has ruined food. So I guess I will forgive them. Eventually.