5 ms·

I wish there was a way to upvote something 10x once a month here. This would be the post I use that on. When I was writing my book my editor asked me to remove

by xrd 6y ago

I wish there was a way to upvote something 10x once a month here. This would be the post I use that on. When I was writing my book my editor asked me to remove any writing about mistakes and changes I made in the project for each chapter. I had a bug that appeared and I wanted to write about how I determined that and fixed it. They said the reader wants to see an expert talking, as if experts never make mistakes or need to shift from one tact to another. But, I find I learn the most from explanations that share how your mental model was wrong initially and how you figured it out and how you did it "more right" the next time. That's really how people build things.

fnord123 6y ago
>They said the reader wants to see an expert talking, as if experts never make mistakes or need to shift from one tact to another. Your editor was very fucking wrong.
- natefox 6y ago
  So, so wrong. How did (s)he think experts get so good? Isn't the phrase `the master has failed more times than the apprentice has even tried` well known for a reason?
  - emerongi 6y ago
    It obviously depends on the type of the book and the reader's expectations. It just might not have been the type of book where you write about things like that.
    - ohyeshedid 6y ago
      >It just might not have been the type of book where you write about things like that. I think that'd be more of the author's choice, instead of the editor.
  - a1369209993 6y ago
    > the master has failed more times than the apprentice has even tried I've never actually heard that one before, but it's so very, very true.
- gridlockd 6y ago
  > Your editor was very fucking wrong. The editor is completely right in what they were saying. You just want them to be wrong, because you'd prefer to live in the fantasy world where they are wrong. Let's say you go to get a surgery. You don't want the doctor to tell you about all the times they fucked up and what the awful consequences were. It doesn't matter that they're probably a better surgeon now, having learned from their mistakes. Psychologically, you need that person with the sharp tool poking around inside your body to be a superhuman. To a lesser degree, the same is true for any expert. Of course everybody makes mistakes. Notice the de-personalization in the word "everybody". You can talk about the mistakes everybody makes, or those ones that many people make. If you talk about your own mistakes however, you lose the superhuman status. There may be a few situations where that somehow helps you, but not when you want to sell books.
  - fnord123 6y ago
    I wonder if we're on the same page. Should a book on a programming language discuss compilation errors and how to interpret them? Should a book like Effective C++ (afaik the most popular series of books on C++) exist?
    - gridlockd 6y ago
      The answer (yes) is already in my reply, in the second paragraph.
  - sokoloff 6y ago
    I sure do want that surgeon to have been presented/instructed on the common ways that surgeons before them have made mistakes and how to avoid or overcome them. That they won’t tell me (the patient) is quite a different question from whether they got the material from someone more experienced in their primary or continuing medical education.
    - gridlockd 6y ago
      The situation is different, the psychological effect is not.
- xrd 6y ago
  Obviously, I agree with you! I also think this is the way the majority of tech books are written. Can you think of another where the author goes from mistake to mistake and then finally gets it right? I believe there is a space in tech writing for this kind of writing, but it is not something traditional book publishers believe. This was an O'Reilly book by the way, with really good editors and a really good editoral process. That editor was right most of the time, IMHO.
  - fnord123 6y ago
    >Can you think of another where the author goes from mistake to mistake and then finally gets it right? Not a book, but Raymond Hettinger often presents in this way and it's fantastic: https://www.youtube.com/watch?v=wf-BqAjZb8M https://www.youtube.com/watch?v=wf-BqAjZb8M
  - drvdevd 6y ago
    Most (in-depth, technical) security books follow this sort of thought process- I think. “A big hunters diary” comes to mind.
  - fnord123 6y ago
    Ignition! A history of liquid rocket propellants. Little Lisper, Little Scheme is a conversation style that discusses a lot of false starts. {Coders|Founders} at Work has a lot of frank talk about early mistakes people make and their pivots.
- drvdevd 6y ago
  Agreed. The entire expertise of programming is based on the willingness to find these sorts of issues and fix them. Over and over, for your entire career.
- Leonid99 6y ago
  Most books frame this as "one common mistake is ...". I always understood this phrase to mean that the author has personally made this mistake more than once.
mgkimsal 6y ago
personally... I'd like to see that sort of info, but typically not in the middle of a chapter/section. make a note or call out in the text pointing to a section on why/how you got to the 'correct' position. That info is often helpful info, but can disrupt the flow of the 'good' information.
barrkel 6y ago
s/tact/tack/ Tact means skill in dealing with other people, particularly in sensitive situations. Tack has to do with sailing boats into the wind, and crucially "changing tack" means changing direction.
- xrd 6y ago
  Thanks, I'm glad I had you as an editor this time! I never noticed that before.
namelosw 6y ago
I hate this so much. But it's so common. I was told not to mention the caveats, instead, render a confident image for the team many times in my career. It's like doctors suggest their patients to use some drugs without mentioning any side effects. It reminds me of the video[0] which asks the developer to draw red lines with blue ink, while the project manager keeps pushing the developer like "You're the expert, of course you can do draw red lines with blue ink!". [0] https://www.youtube.com/watch?v=BKorP55Aqvg https://www.youtube.com/watch?v=BKorP55Aqvg
m463 6y ago
years (and years) ago, if I wanted to learn a new computer technology or language, I would pick up a book and learn it. One language that didn't go how I expected it was applescript. The book on applescript (from o'reilly I believe) was necessarily different. Instead writing "normal" top-down programs, applescript hooks into the OS from the side. Many books can concentrate on what you can do, but the applescript had to do everything by example. This is because all of apple's applications expose interfaces that you have to figure out on the fly. I had to learn a different way from that book, because it necessarily concentrated on "how" instead of "what".
raverbashing 6y ago
> asked me to remove any writing about mistakes and changes I made in the project for each chapter. I had a bug that appeared and I wanted to write about how I determined that and fixed it. Your editor is right. Not because this information is not interesting. But it is distracting and off-topic to go off a tangent every now and then. Especially for someone just learning the stuff, it will confuse them more than anything else.

by xrd 6y ago

fnord123 6y ago

>They said the reader wants to see an expert talking, as if experts never make mistakes or need to shift from one tact to another. Your editor was very fucking wrong.

natefox 6y ago
So, so wrong. How did (s)he think experts get so good? Isn't the phrase `the master has failed more times than the apprentice has even tried` well known for a reason?
- emerongi 6y ago
  It obviously depends on the type of the book and the reader's expectations. It just might not have been the type of book where you write about things like that.
  - ohyeshedid 6y ago
    >It just might not have been the type of book where you write about things like that. I think that'd be more of the author's choice, instead of the editor.
- a1369209993 6y ago
  > the master has failed more times than the apprentice has even tried I've never actually heard that one before, but it's so very, very true.
gridlockd 6y ago
> Your editor was very fucking wrong. The editor is completely right in what they were saying. You just want them to be wrong, because you'd prefer to live in the fantasy world where they are wrong. Let's say you go to get a surgery. You don't want the doctor to tell you about all the times they fucked up and what the awful consequences were. It doesn't matter that they're probably a better surgeon now, having learned from their mistakes. Psychologically, you need that person with the sharp tool poking around inside your body to be a superhuman. To a lesser degree, the same is true for any expert. Of course everybody makes mistakes. Notice the de-personalization in the word "everybody". You can talk about the mistakes everybody makes, or those ones that many people make. If you talk about your own mistakes however, you lose the superhuman status. There may be a few situations where that somehow helps you, but not when you want to sell books.
- fnord123 6y ago
  I wonder if we're on the same page. Should a book on a programming language discuss compilation errors and how to interpret them? Should a book like Effective C++ (afaik the most popular series of books on C++) exist?
  - gridlockd 6y ago
    The answer (yes) is already in my reply, in the second paragraph.
- sokoloff 6y ago
  I sure do want that surgeon to have been presented/instructed on the common ways that surgeons before them have made mistakes and how to avoid or overcome them. That they won’t tell me (the patient) is quite a different question from whether they got the material from someone more experienced in their primary or continuing medical education.
  - gridlockd 6y ago
    The situation is different, the psychological effect is not.
xrd 6y ago
Obviously, I agree with you! I also think this is the way the majority of tech books are written. Can you think of another where the author goes from mistake to mistake and then finally gets it right? I believe there is a space in tech writing for this kind of writing, but it is not something traditional book publishers believe. This was an O'Reilly book by the way, with really good editors and a really good editoral process. That editor was right most of the time, IMHO.
- fnord123 6y ago
  >Can you think of another where the author goes from mistake to mistake and then finally gets it right? Not a book, but Raymond Hettinger often presents in this way and it's fantastic: https://www.youtube.com/watch?v=wf-BqAjZb8M https://www.youtube.com/watch?v=wf-BqAjZb8M
- drvdevd 6y ago
  Most (in-depth, technical) security books follow this sort of thought process- I think. “A big hunters diary” comes to mind.
- fnord123 6y ago
  Ignition! A history of liquid rocket propellants. Little Lisper, Little Scheme is a conversation style that discusses a lot of false starts. {Coders|Founders} at Work has a lot of frank talk about early mistakes people make and their pivots.
drvdevd 6y ago
Agreed. The entire expertise of programming is based on the willingness to find these sorts of issues and fix them. Over and over, for your entire career.
Leonid99 6y ago
Most books frame this as "one common mistake is ...". I always understood this phrase to mean that the author has personally made this mistake more than once.

mgkimsal 6y ago

personally... I'd like to see that sort of info, but typically not in the middle of a chapter/section. make a note or call out in the text pointing to a section on why/how you got to the 'correct' position. That info is often helpful info, but can disrupt the flow of the 'good' information.

barrkel 6y ago

s/tact/tack/ Tact means skill in dealing with other people, particularly in sensitive situations. Tack has to do with sailing boats into the wind, and crucially "changing tack" means changing direction.

xrd 6y ago
Thanks, I'm glad I had you as an editor this time! I never noticed that before.

namelosw 6y ago

I hate this so much. But it's so common. I was told not to mention the caveats, instead, render a confident image for the team many times in my career. It's like doctors suggest their patients to use some drugs without mentioning any side effects. It reminds me of the video[0] which asks the developer to draw red lines with blue ink, while the project manager keeps pushing the developer like "You're the expert, of course you can do draw red lines with blue ink!". [0] https://www.youtube.com/watch?v=BKorP55Aqvg https://www.youtube.com/watch?v=BKorP55Aqvg

m463 6y ago

years (and years) ago, if I wanted to learn a new computer technology or language, I would pick up a book and learn it. One language that didn't go how I expected it was applescript. The book on applescript (from o'reilly I believe) was necessarily different. Instead writing "normal" top-down programs, applescript hooks into the OS from the side. Many books can concentrate on what you can do, but the applescript had to do everything by example. This is because all of apple's applications expose interfaces that you have to figure out on the fly. I had to learn a different way from that book, because it necessarily concentrated on "how" instead of "what".

raverbashing 6y ago

> asked me to remove any writing about mistakes and changes I made in the project for each chapter. I had a bug that appeared and I wanted to write about how I determined that and fixed it. Your editor is right. Not because this information is not interesting. But it is distracting and off-topic to go off a tangent every now and then. Especially for someone just learning the stuff, it will confuse them more than anything else.