Re: TW on the development team

[Gary Merrill <merrill -at- HYPERION -dot- PDIAL -dot- INTERPATH -dot- NET>]

>   George Allaman <gallama -at- lookout -dot- ecte -dot- uswc -dot- uswest -dot- com> writes:

>  I resemble this. I are a engineer.

   I remember that when I was quite young my mother frequently expressed
the desire that I become an engineer.  I could not at that time understand
why she should have such respect for that profession, and since I really
had no interest at all in driving trains, I could not imagine becoming an
engineer myself.  Later, when I became a philosopher and academic, the
shoe was on the other foot and my parents never understood even remotely
what I did (my father, to his dying day, believing that  I was some sort of
psychologist).  And then even later I evolved (devolved?) into a software
engineer -- thus satisfying, quite unintentionally, my mother's long perished
desire.  Odd how these things work out.  I have not noticed any significant
difference between the social skills of my academic colleagues (in a humanities
department) and the social skills of my fellow geeks in the software industry.
There certainly are two quite different intellectual/political cultures here,
and I think that this often accounts for what is expressed in terms of a
different set of social skills.

>  I would venture to say that engineers as a class (no reference to manners or
>  object oriented intended) don't have a huge problem with social skills.
>  Computer Science engineers and developers, however, are a different kettle of
>  fish. Call us names, but I think the same selfish behaviour is true of any
>  class that considers another class "support". Especially when management
>  doesn't discourage it. Ask any secretary.

   Okay, it's time to address this issue:  Just what is wrong with "support"?
Engineers are louts because they think of writers as "support"?  But in
a straightforward sense the writers *are* support.  In what sense?  Well, in
the rather obvious one in which you can develop a software product without
documentation, you can sell it with lousy or no documentation, but you can't
sell the documentation without the software.  The documentation is parasitic
on the software.  That's the way it is, folks.  If you don't like it, you belong
 in
another profession.  Now what follows from this?  Does it follow that the
documentation and the writers are *unimportant*?  No.  Does it follow that
you *should* develop the product without a thought about the documentation?
No.  Does it follow that the writers are somehow intellectually *inferior* to
 the
developers of the software?  No.

   But beyond that, there is nothing wrong with being in a role of "support",
and only someone in the grip of some weird elitist ideology would think that
there is.  Now, I grant you, that if the classification of "support" is used by
management to make inappropriate distinctions such as those above, this
needs to be dealt with.  There is something of a tendency to think of "support"
as meaning "not as important".  Strictly speaking, this is true.  I have
 frequently
worked in a role properly described as "support" to a more primary development
effort (I work in such a role now), and my position and my work have simply
not been as important as those of the primary developers.  It doesn't mean that
either I or my work are without value -- even great value, or even essential
 value
to the ultimate product.  But there is a hierarchy here.  It is just the nature
 of
things.  A great deal of friction and a great deal of unhappiness can be caused
if you are truly in a support role (as many of us are), but refuse to
 acknowledge
this.  If your feeling of self-worth depends upon your being the quarterback,
and if you either don't really want to be the quarterback or are not qualified
to be the quarterback, then you have a serious problem.  But trying to get other
people to go along with the idea that you really *are* the quarterback, is not
going to solve the problem.

----------
Gary Merrill