Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!purdue!decwrl!nsc!icldata!altos86!charly From: charly@Altos.COM (Charly Rhoades) Newsgroups: comp.text.desktop Subject: Re: Typography--Was Re: ventura Summary: In Which Technological Bigotry Is Explored Message-ID: <1178@altos86.UUCP> Date: 1 Jun 89 17:45:17 GMT References: <32118@sri-unix.SRI.COM> <7650004@hpwrce.HP.COM> Reply-To: charly@altos86.UUCP (Charly Rhoades) Organization: Altos Computer Systems, San Jose, CA Lines: 119 Valerie Maslak has written: >> I'm sorry if I sound testy. It's just that I'm a publications >> professional, an editor, and I'm awfully tired of engineers who >> think they know as much as I do about publication design. >> I don't try to design circuits or write programs; why do they think >> they can design publications? >> > In article <7650004@hpwrce.HP.COM> howeird@hpwrce.HP.COM (Howard Stateman) responds thus: >I have a degree and 6 years' experience in publication design and >layout, and most of a degree, and 10 years' experience in computer >hardware repair. And now I support desktop publishing software for >a major computer manufacturer. I'll guarantee you that it was a LOT >easier to learn how to design a book than it was to learn how to >design a circuit. Are we talking about which *you* thought was easier, document design or circuit design? I don't think so. I think the point that Ms. Maslek is making is that engineers should let pubs specialists do their jobs. Nobody doubts that engineers, whether experienced in pubs or not, think they can do as good if not better job than the people paid to do it. Since when is this news? And since when are documentors the only recipient of such arrogant egotism?? Firmware designers scoff at systems people; developers loathe testers; field servive engineers laugh at developers. The only rallying cry for these engineers is when they talk about marketeers or management. Then they finally agree that all these people are bozos too! My feeling after about ten years of dealing with the computer industry is that this common attitude of engineers is symptomatic of the growing technocratic society we live in. As people are valued for their increasingly narrow field of knowledge, they value less and less the common skills that "anybody" can do. Engineers are smugly confident that they know the correct use of "which" or "that" since they have been using these words in speech and writing nearly all their life. Documentors are just riding on the basic skills most of us have been using most of our lives. > And your either/or attitude is way out of line, >since most engineers see publications by the ton, which means they >have gone through half the educational process for book design right >there. Yep, just show it to me and I *know* it. I've been driving for over ten years but I don't know beans about how a universal joint *really* works. Nor could (or would) I attempt to fix one -- or design and build one from scratch. Moreover, I respect the person who can! I also know enough to know what I don't know. Is it perhaps conceivable that using a tool is not "half the educational process" for desgining that tool (notwithstanding our attempts to build in "user-friendliness")? Can you imagine the reaction if the tables were turned? "As a ComputerLand dealer for twenty years I've seen computers by the ton, which means I've gone through half the educational process for designing them right there." (Of course, it would be the same: scoffing disdain and ridicule.) > On the other hand, you probably have not seen nearly as many >circuit designs. That just means you haven't yet got the background >in their field that they have in yours. It doesn't mean you couldn't >learn. > Documentors I have worked with rarely treat an engineer's suggestion as shabbily as engineers treat a documentor's suggestion. Which is more likely to happen: A writer follows the suggestion of an engineer and makes the change in the book (e.g., a re-organization of chapters or a new table), or the engineer follows the writer's suggestion and makes the change in the program (e.g., a user prompt or a help screen)? >Of course, there is a lot more objectivity to circuit design than >there is to book design. I needed to learn all about components and >manufacturing processes and materials to learn how to design a circuit, >as well as how to lay out the drawings and present them for publication. >But all I needed to learn to design a book were a few minor details >about the limitations of the press and bindery, what fonts >were available in what sizes and on which typesetting devices. >The rest were subjective "I know what I like" kinds of art decisions. > >What I am saying, Valerie, is that your profession isn't a hard one >for an engineer to learn. Most of us who use DTP have already learned >it. Probably as well, or better, than most book designers. And I speak >from experience on that, not just idle speculation. These paragraphs say it all--the inherent superiority of objective fields of knowledge over subjective ones, "learn all about components and manufacturing processes" vs. "all I needed to learn ... were a few minor details," use equals knowledge (even mastery)... As a personal note to Ms. Maslek and other documentation professionals in the audience, I think Mr. Statemen's attitude is all too prevalent in the computer industry, and I suspect in other technology-based industries as well. This is our obstacle as documentors of technical information, our challenge. While I fear I might have indulged my penchant for argumentative dissection here, perhaps the best thing to do now is to turn our thoughts to how best to work in this environment. Mr. Statemen's worth is as an object-lesson of the current state of affairs. And while he has made it clear that his suggestion to Ms. Maslek is to "get off your hight horse; most engineers can design documents as well if not better than documentation professionals," perhaps he (and similar minded colleagues) could also provide some constructive comments. Pray tell, Mr. Statemen, what should we documentors do to improve our lot? Learn how to program? > > -------------------------------------------------------------------- >|Howard Stateman, Hewlett-Packard Response Center, Mountain View, CA | >|howeird@hpwrce.HP.COM or hplabs!hpwrce!howeird | >|Disclaimer: I couldn't possibly speak for HP. I know too much. | ^^^^^^^^^^^^^^^^ Only your arrogance exceeds your vast knowledge. Charly Rhoades {pyramid|sun|amdahl}!altos86!eddie!crhoades ------------------------------------------------------------------------ If you know you have an unpleasant nature and dislike people, this is no obstacle to work. J. G. Bennett ------------------------------------------------------------------------