Subject: RE: >: job rant - response to Mike Thu Aug 13 15:21:38 1998 > And the way "modern" corp. have tried to engineeer production (put A > into B and create C) assumes that all you have to do is know the steps. > No heart. No aesthetics. No vision. > > WRONG. i have the skeleton of another whole rant on just that subject jotted down on my Pilot.. the working title is: corporate structure, George Eliot's _Middlemarch_, the putrefaction of the web, and why it's so f*cking hard to program a VCR. > But it's the contractors who are first laid off ... regardless of their > contribution to the company's bottom line. and this ties directly into the main theme. there's a major weakness built into the very fabric of corporate structure. coordinating the efforts of a large number of people is a difficult skill, and it takes a large investment of time and effort to learn to do it well. by the same token, learning how to produce a high quality product is also a skill, and it takes an equally large investment of time and effort to learn to do that. that means the better a person is at being an administrator, the more likely they are to be helpless when it comes to making a really good product. by itself, that's not an unsolvable problem. if you put the administrator and the product developer on the same team, and make each of them responsible for doing what they're good at, you'll have a powerful combination. each can play off the other's strengths, and as long as they respect each others' turf, life will be wonderful. the problem comes when you try to use the same people in a heirarchical power structure. at that point, everything goes to hell, because no matter who you put on top, there's something they're going to be bad at. but that person now has the authority to out-vote the one who actually knows what to do when push comes to shove. even with that bad situation, you can still make things work, if the person on top has the moral fibre not to let push come to shove. the problem with that, of course, is that you don't find a lot of saints choosing upper management as a career path. there's also an communications problem built into the very nature of being good at something: if you're willing to cut corners and take shortcuts, you'll never develop your skills. if you do develop your skills, you've also had to learn to resist the urge to cut corners and take shortcuts. a person who hasn't developed a certain skill usually doesn't have enough background to understand why taking the shortcuts is a bad idea in the long run. the only way they can learn to understand it is to sit down and do the work necessary to acquire that level of skill. the problem is that a person who's willing to take shortcuts isn't going to want to spend time and effort learning why they shouldn't. it's must easier to fall back on authority, schedule pressure, and all the other things that make a developer's life hell. that's not to say the developers have an uncontested claim to the moral high ground, though. we all know we keep getting put into ridiculous situations by nitwits with an MBA they got (apparently) out of a box of cracker-jacks, but we never stop to ask ourselves, "how did this walking empty space get power over me?" the answer, as far as i can tell, is rather unpleasant: the pinheads are there because we allow them to be. like i said, administration is a skill, and getting good at it takes a serious investment of time and effort. we've already spent time and effort getting good at being developers, and don't want to have to become administrators as well. we're just as guilty of trying to slide by without knowing how the other guy does his job. the thing that's really damning is that we're *so* uninformed and willing to fob that responsibility off on somebody else that we can be beaten by managers who are frankly clueless. developers as a whole are pretty bright, and if we took the time to get reasonably good at making PERT charts, GANNT charts, and writing schedules, we could walk all over these turkeys. after all: we're the ones who know the real numbers.