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.

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.

If you enjoyed this article, please consider sharing it!

15 Responses to “Not Just Coding”

Oddly, I grew up in Amherst, NH, about 90 miles from its MA counterpart, and we do pronounce the H there.

The irony is I now live two towns over from Amherst, MA, and I get glared at when I pronounce it the way I grew up with, as though I’m some hated midwesterner who can’t be bothered to learn the local pronounciations. Which is unjustified, when I’ve known since I was 8 how to pronounce Worcester (“Woo-stah”), Billerica (“Bi-rica”), and Somerville (“Slumaville”).

Sadly, I think the stereotype you point out is the common perception. Some of the most technically challenging engineering projects I’ve worked on have (surprise) involved a lot of face time and non-coding activities, and when I talk to the clients years later they don’t remember there was any engineering at all.

Working in a big corporation, the software was always the most expensive of any engineering projects. But the sheer paperwork requirements placed on the software designers (justifications for changing variable names etc) were part of the reason for that. Software isn’t as developed a discipline as say mechanical engineering. That is partly what I like about it. You get to explore and tinker in ways you might not get to 200 years from now.

I did read an interesting article in an Embedded Design magazine. The core idea was that if you really want re-usable code you need to have nuts and bolts of software that you can just plug in. This is not code re-use. This is a tiny little processor that performs a function. It has input and output and always does what you expect. It doesn’t matter if your compiler changes because it is already compiled. You just pull it off the shelf and plug it in.

I’m amazed that the things this guy said actually got past the NYTimes editors’ libel filtering. Seriously, he stops short of calling programmers wife beating drunks, but “drowning in ignorance” and “hunching over keyboards”?

Any way to create software just ends up being a type of programming, unless you have a type of AI which is so smart it knows better than the user what the user wants. At which point the AI decides it has no use for users and takes over the world.

On Hungarian notation: it is much maligned and misunderstood. The kind of Hungarian notation you see in MFC or DirectX code looks like this, and is completely pointless:

DWORD dwValue;

… where dw merely repeats the fact that it is a DWORD. Simonyi intended his notation to be used as something like this:

float posNormValue;

…which indicates that it is a positive normalised value, and that’s information that is not contained merely in the type of the variable. Or, as another example:

string usUserInput;

…where us indicates that the string is unsafe, that is it might be user input to a webpage, and has not been security checked for HTML tags or script code, so should not be directly written back into another webpage. In this way, merely looking at the name of the variable tells you things you need to know, which almost never includes the type of the variable. Just looking at an unsafe string variable name, a programmer using this notation would never write something like this:

Interesting. Either there’s a limit on the number of characters you can put in a comment, which is why my previous post got cut off halfway through; or more likely, it didn’t like the fact I had less-than (<) signs in my post. Which is kind of ironic, as it happened right in the middle of the bit where I was demonstrating WHY it’s important for a programmer to know whether a string is safe or not, and HOW Hungarian notation, properly used, makes that much easier.

Well… I’m not going to retype the rest of what I wrote, as I feel the point is proven – though as the rest of you may never get to actually READ my point, it’s only really proven to myself…

The part about programmers not knowing what users want is by far the most delusional part of the article, perhaps followed closely by Bill Gates as a programmer-billionaire (programmer, indeed). All in all, this guy just exposed himself as ignorant about his topic, to say the very least.

However, the state of the software industry is indeed sad. What passes for ‘standards’ in IT is openly laughable in other true engineering fields. For any programmer to call themselves an engineer is a complete travesty and standing insult to real engineers. And the situation seems to be getting worse. Try to differentiate, for example, between the OS and an application to even a seasoned admin (well, windows admin anyway) and you get a blank stare as if speaking a lost tongue. Its as if the process of ‘dumbing down’ is slowly making headway into the ranks of programmers themselves.

Personally, I fault universities for this. A student can get a ‘computer science’ degree without any advanced math at all, or even advanced programming (like systems programming), or even any abstract knowledge of how computers work. It as if computer science degrees are now little more than job training.

I’d wouldn’t equate admins with engineers. Admins would equate to field technicians. And I think that given the length of time the field has been developing relative to say mechanical engineering, it is doing pretty well. I will agree that many universities could do much better. My university (Western Washington U) had some excellent teachers and the silliest curriculum I’ve heard of. I was a math major fortunately, but when I took computer classes I found out that I was the only student who had taken any logic classes. The curriculum didn’t teach logic to the programming students until they were seniors!

I agree wholeheartedly with what you had to say about Intentional Software and blogged about it earlier today. Good point about the ridiculous description of software engineers – you should write a letter to the editor. I have worked around software engineers for years, and the best ones can absolutely communicate with users and figure out what they want – if they couldn’t they would never get anything done. I also agree with your comments about “just programming”. I was more of an analyst/manager type most of my career but had always wanted to understand programming and computer science so I went back to school and got my Master’s in CS (just finished in December and still recuperating!) Seriously, it was a great experience and I didn’t know how much I didn’t know until I started down that path. My program was pretty rigorous – a fair amount of math and formal logic. I now find that it is 10 times easier to learn a new technology than before because I have a good foundation now. If undergraduate CS programs are really not providing this any more, than the software engineering profession is in trouble.

I disagree with the entirety of bithead’s last paragraph… that universities teach too little advanced math and are little more than job training.

We should be so lucky if universities taught the profession of software engineering. At best they teach the science of computing, at worst they fail to do both. I’ve interviewed/hired enough fresh talent from CMU to know how ill-prepared they are to produce software in a commercial setting. I believe the bit-centric approach is a large reason for the disconnect between some programmers and the non-programmers forced to work with them.

I posted a piece on this article too (http://www.edmblog.com/weblog/2007/01/does_everyone_e.html). I think part of the problem is that people good at programming do think differently (more logically, more precisely, more pedantically) about a problem than most business people do. Technology to bridge that gap exists and has existed for a while but many business people like being able to blame programmers. Getting everyone on the same side involves the communication skills you mention, and technology/approaches that engage technical and business skills in defining a solution
JThttp://www.edmblog.com

[...] I was feeling pretty good about myself last week. I was able to read an infuriating article in the New York Times and because I am more mature and grounded these days, I was able to see past all of the little peeves in the piece and write an impassioned critique of the big picture problems. [...]

Hi! Welcome to Tea Leaves!

Thanks for dropping by! Feel free to join the discussion by leaving comments, and stay updated by subscribing to the RSS feed.