Saying that a programmer’s job is not to write code is disingenuous. It’s like saying that a construction worker’s job is not to build a house, but to make sure that the customer has a warm place to sleep. This is wrong. The decision has already been made. The worker WAS hired to build a house.
As usual, Jeff, your opinions reflect the environment you work in, and the type of software you make. I refer you to Joel’s “Five Kinds of Software”.
Not all software has users in the normal sense of the word. Many programs are not desktop or web applications. Who is the user of a router’s software? A car’s computer? An automatic fruit sorting machine’s software? Who are the users of a bank’s HUGE software base? The customers? The tellers? Maybe OTHER pieces of software are the users?
Much of the software in the world does not interact with people at all. And when it does, those people have almost no control over it, no more than they can control the airplane they are traveling on (and even the pilots only have SOME control over an aircraft’s software).
It is quite common for many programmers to be unable to easily explain what they are doing, since their job is the guts of software, and they work with abstract ideas. This is especially true if you work in the kind of software place where the software is extremely complicated, requiring dozens of programmers and many layers of abstraction.
It is also common in places where the person buying the product doesn’t really know or care there’s software inside (like a router).
“Customer: What are you working on?
Programmer: I’m building a lock-free linked list implementation”.
“Customer: Huh!? what does that even mean? I’m paying you to build me a request processing server”
…10 to 20 minutes of explanations later (assuming the programmer is REALLY REALLY good at explaining complex, abstract ideas to laypeople):
“Customer: So how will that even help me?”
“Programmer: Your server will be able to function well enough when the expected 1000 people will work on it”.
This is of course an imaginary conversation. Not one customer in 50 will agree to be subjected to such a complex explanation. Nor should they.
I don’t care WHY my auto mechanic needs to replace the flux capacitor coils. Tell me what was wrong with the car, and if it’s complicated, it doesn’t matter. Just make it work, and tell me how much it costs (this assumes I trust my auto mechanic, but in the world of software, we generally do trust the programmers).
This is also why customers and programmers are sometimes separated, and communicate through special channels (like analysts, requirements, a customer’s representative, etc…).
I do agree that it’s very important for developers to know WHAT they are working on, and why, and all that jazz. I just don’t think it’s that important for those reasons.
Finally, the BEST technologies are sometimes excellent communicators, but not all of us are Peter Norvig. Many amazingly excellent technologists and developers are in fact quite poor communicators (at least to non-technical people). However, since they make software and generally need to communicate to technical people, that’s not a real problem.