"In order to be an effective programmer, you need to possess a combination of traits that allow your skill, experience, and knowledge to produce working code. There are some technically skilled developers who will never be effective because they lack the other traits needed. Here are seven traits that are necessary to become a great programmer."

I am no great technical programmer, but one thing I do make a point of doing is to sit down with users and learn about them and their jobs: what they do, what they know, how they think, and what their duties, liabilities, concerns and desires are. While I could never do their work anywhere near as well or fast as they could, I consider it my basic responsibility to know enough about their work that I could muddle by at least at intern level and communicate with them in their own language. "Stepping into their shoes and walking around in them," as a wise, if fictional, commentator once put it.

Once I can think about users' problems as if they were my own, I can apply my own analytical and coding skills to creating solutions that they couldn't produce themselves. But just because that's my own area of expertize doesn't make theirs any less important or less deserving of attention or respect. If anything, it's the opposite: they are the ones who actually make things and do things; my job is merely to facilitate that.

So it shocks me how many professional developers seem content to sit at their desks all day every day, churning out code with no personal understanding of how that code will integrate into users' lives. I appreciate that management cultures obssessed with internal politicking and buck-passing tend to create isolationist silos that confound such communication and collaboration, but a lot of developers seem to embrace the arrangement. These professional "problem solvers" and "solution builders" would rather live their whole life in some self-imposed Skinner Box, never touching the world outside. Sitting with users ("lusers") is often seen as a menial, dirty task and quite beneath them: the responsibility of BAs, QAs, managers; anyone but themselves.

These same programmers get upset and angry when end-users complain that their provided 'solutions' fail to address the problems they actually have. Yet they are as much the architects of their own failure as anyone. A coder who only knows how to code is about as much use as a manager who only knows how to manage. The former [rightly] aren't shy about criticizing the failings of the latter when they are the ones on the receiving end, but perhaps they should perform the same analysis on themselves sometime.

The situations I've encountered most are either a vague, ambiguous description of what is needed, or a hacked-together requirements doc that is over-detailed in some areas but glosses over others.

If you sit down with the user to see what they are trying to do, you get a sense of their workflow, interruptions and frustrations. The details matter. (It is shocking how saving a mouse-click or two can turn "I hate it" into "I love it".)

This is also where thinking about the future comes in. Eventually you develop a "Spidey Sense" about how the program/process might evolve in the future, where you can save almost total rewrites (or a horrible mess) down the road if you put a little extra design/work in at the start.

What depresses me beyond belief is that your comment and mine are the only ones on either OSNews or TechRepublic that even acknowledge the existence of a world outside The Team, never mind advocate actually interacting directly with anyone in it.

There is something terribly wrong in a mainstream programmer culture that sees the program as Everything: The End In Itself. But the program itself is nothing; it is merely a means to an end. The only thing that gives a program any purpose or value whatsoever is the people who use it.