>Some publishers (including Cisco Press) have authors work with a >development editor during the writing of the book. This is especially >important for new writers or engineers who don't have very good writing >skills. Cisco Press also has the writer work with technical reviewers as >the writing is progressing.
Macmillan Technical Publishing, sister organization of Cisco Press, also uses development editors. In my case, it was an awful experience. The development editor constantly tried to rephrase things in a manner that changed meaning, even when the reviewers told her I was correct. I believe Cisco Press now has the option of working with, or not working with, a development editor. If the relationship can develop over time, it can also work out that authors with similar writing styles can trade reviews. I've done this with Galina Pildush and Jeff Doyle, variously at the chapter and book level. For people interested in eventually writing books, contacting the publishers and getting on the list of reviewers can be an excellent introduction to the process. > >I realize I was critical of Cisco Press copy editing in my previous >message, but, in general, their books are much better than the competition >because they work in this mode (with development editors and technical >reviewers). > >Some publishers, such as Wiley, won't let an author in the door unless the >author has proven writing skills and technical expertise. That method works >also. Wiley uses fewer technical reviewers than Macmillan, but they aren't the same kind of configuration-oriented books. The reviewer (an "advisor" when a Networking Council member) is more of a sounding board. Scott Bradner did this for my first Wiley book. For my second, Lyman Chapin started out as advisor but changed jobs and was unable to continue. Annlee Hines took over and was a tremendous help. I hadn't realized the proved writing, but I've been extremely happy working with Wiley. Since I'm going through copy edit on the new book (to ship in early April), I have to share something that had me in hysterics. In the book, I have a number of "running case studies." One is about a law firm, which I named "Huffle, Puffle, and Cetera." The copy editor carefully changed every reference to "Huffle, Puffle, etc." The managing editor giggled and put it back. > >And then there are the publishers that just want to push content out there >and start collecting $$$$s as quickly as possible. Their stuff tends to >suck. ;-) > >Priscilla > >At 04:02 PM 1/17/02, Chuck Larrieu wrote: >>It may also be that copy editors think that because it is tech, that what >>they see, although it does not make sense grammatically, does make sense to >>other techies. For a tech review I am currently working on, I had to >>specifically call the editor and tell him that the chapters were very poorly >>written, had lots of poor sentence construction, not to mention bad grammar, >>and that he should specifically be aware that the text made no sense no >>matter who was reading it. Hmmm... come to think of it, I haven't heard from >>those people lately. I wonder if they fired me? ;-> >> >>I suspect that in this mad rush to get tech books out the door, many of the >>publishing houses are operating under the assumption that whatever a tech >>writer writes is correct. Kinda like the emperor's new clothes? Can't be >>understood by a fool? >> >>Chuck >> >> >>""Priscilla Oppenheimer"" wrote in message >>[EMAIL PROTECTED]">news:[EMAIL PROTECTED]... >> > At 12:21 PM 1/17/02, R. Benjamin Kessler wrote: >> > >I have a couple of "nit-picky" complaints about the book (as I do about >> > >almost every book I read). There are some typo's as a previous poster >> > >indicated. One of my biggest pet peeves is the use of the term >>"continuous" >> > >when the author (probably) means "contiguous" - one sees this most often >> > >when discussing OSPF. >> > >> > That says that the author didn't look at the copy-edited material. New > > > authors assume that publisher's copy editors have a clue. They don't. >They >> > apply rules for "fixing" words and sentences without any idea what they >>are >> > doing. >> > >> > This means that you will probably find other minor mistakes in the book >> > too. Don't blame the author, although the author should have been more >> > careful during the final phases of the book project. >> > >> > Cisco Press copy editors once changed every case of Mbps to MByte in a >> > book! In my book, in the index, they changed long fat network (LFN) to >>long >> > file names. See RFC 1323 for the true meaning of elephant (LFN). >> > >> > Thanks for your thorough review of the book. >> > >> > Priscilla >> > >> > > Note, this book isn't unique in this mis-use of the >> > >term; there are many CCO documents that also make this "error." I'm >> > >assuming that this is the product of a spell-checker that didn't know >the >> > >term contiguous, suggested continuous and someone hit "replace all." >>Before >> > >the flame-war starts, I know that these two words have *similar* >meanings >> > >but in this case I - my personal opinion - think that contiguous is >'more >> > >right' - besides, it's the term used in the RFC. >> > > >> > >Since I'm picking nits; the author indicates that the OSPF process ID on >>a >> > >router should be thought of "as an Autonomous System ID. This number >>should >> > >be the same on all routers within the autonomous system." Per CCO, this > >is >> > >a locally significant setting used only to distinguish between multiple >>OSPF >> > >routing process on a particular router. If we were to apply the RFC2119 >> > >definition of "should" to this statement one might think that certain >> > >problems may occur if this practice wasn't followed. I don't believe >>this >> > >to be the case but I'm sure someone on the list will correct me if I'm >> > >wrong. There's nothing wrong with using the same process ID on all of >>your >> > >OSPF routers; I would guess that networks are configured that way more >>often >> > >than not; but isn't a requirement. Given that the lab exam is all about >> > >splitting hairs to the most minute detail and knowing the various >>protocols >> > >in depth, it probably should have been noted (as in other texts) that >two >> > >adjacent routers can have different process IDs configured. >> > > >> > >There are some outright mistakes in the book - I just checked the >>CiscoPress >> > >site for an errata and didn't see one yet. Here one that I recall off >>the >> > >top of my head: >> > > >> > >EIGRP - (p.691) at the bottom of the page, the 'distance' command. >> > >- this is almost a direct copy/paste from the IGRP chapter; does not >>include >> > >the required information to change the admin distance of the EIGRP >>routing >> > >process (which requires both an internal and external distance); it only >> > >lists the syntax to change the distance of a specific neighbor's >updates. >>I >> > >find it funny that the EIGRP chapter says "For a specific example and >>more >> > >practice with the 'distance' command, see" the IGRP chapter. When you >>look >> > >at the IGRP chapter, it uses the same sentence to point you to the RIP >> > >chapter. >> > > >> > >Anyone who has walked into an EIGRP network with multiple, unfiltered >> > >redistribution points into a RIP domain will know first-hand the >>importance >> > >of knowing how a router handles internal vs. external EIGRP routes. >> > > >> > >Additionally, I thought the section on PPP authentication could have >used >> > >some more work on the one-way authentication options (both PAP and >CHAP). >> > > >> > >Bottom-line, this seems to be a well written book; it gives you some >good >> > >examples and labs to work on your own, etc. It won't replace any of the >> > >other "must haves" on the bookshelf (e.g. Doyle, Caslow, Thomas, etc.) >>and >> > >unfortunately, (as it seems with all of the books published these days) >>you >> > >have to play 'reporter' and verify the information in the book with some >> > >other source (CCO, RFCs, other texts) - this is a topic I could rant on >>for >> > >quite some time (considering the $thousands - literally - I've spent on > > > >training materials which contain errors). >> > > >> > >-----Original Message----- >> > >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] >> > >Sent: Wednesday, January 16, 2002 7:18 PM >> > >To: [EMAIL PROTECTED] >> > >Subject: OT: First Impressions - CCIE Practical Studies [7:32237] >> > > >> > > >> > >Just got my copy. >> > > >> > >Reading the "About the Authors" section alone is impressive. All those >> > >associated with the book are CCIE's. I look forward to discovering if >>there >> > >are any errors in the book. One would hope not, given the credentials of >>the >> > >writers and reviewers, one of whom was the Halifax Lab Proctor for >>several >> > >years. >> > > >> > >So far I have browsed all of the first chapter "The Key Components for >> > >Modeling an Internetwork" >> > > >> > >This chapter covers in good detail all those basic questions - the >config >> > >register, configuring a router as a frame switch, password recovery, >show >> > >and debug ( called "the big show" and "the big d" respectively, >>throughout >> > >the book. ) building a terminal server, and much much more. This alone >>tells >> > >me that this book might be a good investment for those just starting >out, >>as >> > >well as those prepping for the CCIE Lab. Sure, all of this information >is >> > >available elsewhere, but with this book, it is in one place, easily >>located, >> > >and clearly explained. >> > > >> > >There is even a section about configuring networking on windoze > >computers. >> > >Considering the number of raw beginners who are coming into the >> > >certification process, this is helpful. >> > > >> > >I'll have more comments after I have had a chance to look at the "good" >> > >stuff. >> > > >> > >Chuck >> > ________________________ >> > >> > Priscilla Oppenheimer >> > http://www.priscilla.com >________________________ > >Priscilla Oppenheimer >http://www.priscilla.com Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=32378&t=32237 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
