>I think you're right. But it's not the same job. Many years ago, a programmer would work on some mainframe project where a very rigid spec was handed down by systems analysts. There were few if any UI issues because very few end-users had terminals...most work was JCL. The user got a green-bar printout. The programmer didn't need to know the business issues and the end-user didn't need to know how to run the computer. In fact, IT departments would often have very rigid rules for interaction between the department and the business units.
>
>I was consulting to a Fortune 100 firm during the early to late 80's and watched the walls come tumbling down. Once microcomputers came into the corporation, end-users wanted them to "do things". At first, IT resisted supporting or even acknowledging microcomputers....or tried to apply the old mainframe rules to them. Business units would resist and a lot of stealth programming went on where power-users became novice programmers or outsiders were brought in (like yours truly) as consultants to write business specific software for these new machines.
>
>A small measure of the old mentality can be found where IT shops have rigid "standards" of what tools can be used on PCs to develop software. Often, these standards fly in the face of the "right tool for the right job".
>
>So, in essence, many modern developers come from that legacy: the lone gunmen brought in by business or financial divisions in a company to understand the business and write end-user applications. Folks from that legacy have had to be a lot more business savvy and a lot less rigid.
>
>Agree? Disagree?


Agree. That's just about how my department (and my job) came into being.