>>A very good example of why some very good programmers write very bad applications. I have seen the work of a number of people who dazzle me with their code. I get to see it when the client calls me in to determine why it doesn't solve their business problem.
>>
>>It is important in our business to be able to talk to computers. But talking (and listening) to humans is an equally important skill. As so many messages here on UT have often demonstrated, the two skills often do not co-exist in the same developer. <s>
>>
>When I was interviewed for my first programming job there was not one question about my programming skills (I had enough to be an entry-level programmer). None of the four people hired along with me had any programming background at all. The company was more concerned about our ability to understand what the user needed. They felt that if you could understand the business problem they could teach you to program. It is much harder to teach a programmer business skills.

I think this is especially true for those of us who still work as individual consultants. I don't mind hiring programmers who are very focused on accomplishing a particular task as defined for them. Often they may have a better idea as to how to accomplish something than I do, but I like to be in control of deciding just what we are trying to accomplish. It is much easier to debug code than it is to unscramble bad design.

I think a lot of the discussion here about the strengths and weaknesses of programming tools really loses sight of how much the one element that is truly the wildcard is the human who is looking at the big picture and analyzing the systems and processes that need assistance from software. I've seen brilliant programmers automate processes that should never have been done that way to begin with to a point where they could destroy a business overnight rather than over the course of years <s>