4 ms·

It was pretty obvious that some authors didn't really know what they were talking about. They knew enough to write something, but there were always a lot of mis

by tfp137 5y ago

It was pretty obvious that some authors didn't really know what they were talking about. They knew enough to write something, but there were always a lot of mistakes. This is why I'd be very hesitant to self-publish a technical book, even though for fiction I think self-publishing is the right decision 99% of the time. We all make errors, even those of us who do know what we're talking about, when you get to the scale of 100+ kilowords. For a novel, a decent copyeditor can fix up the production values well enough; for a technical work, you would hope the publisher assigned some people to check the work.

asicsp 5y ago
>you would hope the publisher assigned some people to check the work Depends upon the publisher too, whether they are interested in publishing quality books or have a quantity policy. >We all make errors, even those of us who do know what we're talking about I was hesitant to write a book for a long time because I thought I wasn't good enough. I still think I have a long way to go, but I've grown better as a writer with experience. Feedback from users have caught many issues and helped me improve the content.
onion2k 5y ago
for a technical work, you would hope the publisher assigned some people to check the work That's what technical reviewers do. I did it back in the early 2000s. You get sent a copy of a few chapters, and it's your job to review the code and explanations to find errors. It doesn't pay very well though - you get your name in the front, and a free copy of the book, but nothing much else.
- commandlinefan 5y ago
  > That's what technical reviewers do Well... in theory they should be. I published a book a while back through a publisher, and they assigned me a copy editor and a technical editor. The copy editor was amazing - it was clear she didn't understand any of the technical details, but she spotted flow errors and minor grammatical mistakes in dense technical prose. The technical editor, on the other hand, seemed to have (maybe) skimmed over the content and his only feedback was that he didn't like my writing style very much and left it up to me to verify all of the technical content. I did take it seriously, though, and I am proud to say that very few technical errors have been reported.
- jedberg 5y ago
  I did technical reviewing for a while. What frustrated me most was when I would say, "this isn't right, it's more nuanced than that" and they would come back and say, "this is a book for beginners so we'll just leave it the way it is". So now my name is attached to incorrect information, and occasionally someone will message me and tell me why I was wrong and I have to message them back and say, "well I told them to fix it but they ignored me".
  - astangl 5y ago
    I had this experience, too, after tech reviewing quite a few books. I quickly got to the point where I didn't want to even look at the final product, because of all the pointed-out flaws that would still remain, and I'd know the book could have been so much better, except that some editor was in a rush, or lazy.
- quickthrower2 5y ago
  I like the idea that all the code in the book goes through a CI so any edited get compiled and unit tested. Certain words and phrases could be given “type annotations” to check consistent use of language. Not to replace human review but should catch a lot of mistakes
cratermoon 5y ago
I once was contacted by a technical book publisher, known for producing a lot of so-so books on specific topics, to be a reviewer for a book on then-hot technology. The book was technically OK, but was put together in such a disorganized and sloppy way that it was a hard slog to look through it. As a reference text, it would have been ok had it been organized as such. This was before stackoverflow, but you could make the same book today by scraping all the stackoverflow questions and answers on a topic, throwing them together and calling it a day. And it was out of date very quickly.
- ghaff 5y ago
  >And it was out of date very quickly. This is a problem with "then-hot" technologies. A number of years back, I was approached by a technical publisher to do a book on OpenStack. I wasn't the right person anyway and passed. But even if I had been, by the time a book would have realistically gotten to market, say 12-18 months, it would have been 3 versions back of the current project.

by tfp137 5y ago

asicsp 5y ago

>you would hope the publisher assigned some people to check the work Depends upon the publisher too, whether they are interested in publishing quality books or have a quantity policy. >We all make errors, even those of us who do know what we're talking about I was hesitant to write a book for a long time because I thought I wasn't good enough. I still think I have a long way to go, but I've grown better as a writer with experience. Feedback from users have caught many issues and helped me improve the content.

onion2k 5y ago

for a technical work, you would hope the publisher assigned some people to check the work That's what technical reviewers do. I did it back in the early 2000s. You get sent a copy of a few chapters, and it's your job to review the code and explanations to find errors. It doesn't pay very well though - you get your name in the front, and a free copy of the book, but nothing much else.

commandlinefan 5y ago
> That's what technical reviewers do Well... in theory they should be. I published a book a while back through a publisher, and they assigned me a copy editor and a technical editor. The copy editor was amazing - it was clear she didn't understand any of the technical details, but she spotted flow errors and minor grammatical mistakes in dense technical prose. The technical editor, on the other hand, seemed to have (maybe) skimmed over the content and his only feedback was that he didn't like my writing style very much and left it up to me to verify all of the technical content. I did take it seriously, though, and I am proud to say that very few technical errors have been reported.
jedberg 5y ago
I did technical reviewing for a while. What frustrated me most was when I would say, "this isn't right, it's more nuanced than that" and they would come back and say, "this is a book for beginners so we'll just leave it the way it is". So now my name is attached to incorrect information, and occasionally someone will message me and tell me why I was wrong and I have to message them back and say, "well I told them to fix it but they ignored me".
- astangl 5y ago
  I had this experience, too, after tech reviewing quite a few books. I quickly got to the point where I didn't want to even look at the final product, because of all the pointed-out flaws that would still remain, and I'd know the book could have been so much better, except that some editor was in a rush, or lazy.
quickthrower2 5y ago
I like the idea that all the code in the book goes through a CI so any edited get compiled and unit tested. Certain words and phrases could be given “type annotations” to check consistent use of language. Not to replace human review but should catch a lot of mistakes

cratermoon 5y ago

I once was contacted by a technical book publisher, known for producing a lot of so-so books on specific topics, to be a reviewer for a book on then-hot technology. The book was technically OK, but was put together in such a disorganized and sloppy way that it was a hard slog to look through it. As a reference text, it would have been ok had it been organized as such. This was before stackoverflow, but you could make the same book today by scraping all the stackoverflow questions and answers on a topic, throwing them together and calling it a day. And it was out of date very quickly.

ghaff 5y ago
>And it was out of date very quickly. This is a problem with "then-hot" technologies. A number of years back, I was approached by a technical publisher to do a book on OpenStack. I wasn't the right person anyway and passed. But even if I had been, by the time a book would have realistically gotten to market, say 12-18 months, it would have been 3 versions back of the current project.